グラフィカルな HTTP 研究ノート
1.2 HTTP の誕生
CERN (欧州原子力研究機関) の Tim Berners-Lee 博士 (Tim BernersLee) は、2 つの場所にいる研究者が知識を共有できるようにするビジョンを提案しました。最初に考えられた基本的なアイデアは、複数の文書間の相互関係によって形成されるハイパーテキスト (HyperText) を利用して、相互に参照できる WWW (World Wide Web、World Wide Web) に接続できるというものです。
1990 年 11 月、CERN は世界初の Web サーバーと Web ブラウザの開発に成功しました。2年後の1992年9月、日本初のウェブサイトのホームページが開設されました。
1993 年 1 月、NCSA (National Center for Supercomputer Applications) によって開発された、現代のブラウザの祖である Mosaic が登場しました。HTML画像をインライン（インライン）形式などで表示するもので、その優れた画像パフォーマンスにより世界中で普及しています。
1994 年 12 月に、Netscape Communications は Netscape Navigator 1.0 をリリースし、1995 年に Microsoft は Internet Explorer 1.0 および 2.0 をリリースしました。
2004 年に Mozilla Foundation は Firefox ブラウザをリリースしましたが、
Internet Explorer ブラウザのバージョンが 6 から 7 にアップグレードされるまでに 5 年かかりました。その後、バージョン8、9、10と次々にリリースされました。さらに、Chrome、Opera、Safariなどのブラウザも次々とシェアを奪ってきました。
1.3 ネットワークの基本 TCP/IP
TCP/IP プロトコル スイートの重要な点は階層化です。TCP/IP プロトコル ファミリは、レベルに応じて、アプリケーション層、トランスポート層、ネットワーク層、データリンク層の 4 つの層に分かれています。
TCP/IP を階層化することには利点があります。たとえば、インターネットが 1 つのプロトコルのみで管理されている場合、どこかの設計を変更する必要がある場合、すべての部品を丸ごと交換する必要があります。レイヤー化後は、変更したレイヤーを置き換えるだけで済みます。各層間のインターフェースを計画した後、各層の内部設計を自由に変更できます。
レイヤー化後のデザインは比較的シンプルになることに注意してください。アプリケーション層のアプリケーションは、自分に割り当てられたタスクのみを考慮することができ、相手が地球上のどこにいるのか、相手の通信経路はどうなっているのか、通信が保証できるのかなどを知る必要がない。
リンク層 (別名データ リンク層、ネットワーク インターフェイス層) は、
ネットワークへの接続のハードウェア部分を処理します。制御オペレーティング システム、ハードウェア デバイス ドライバー、NIC (Network Interface Card、ネットワーク アダプター、つまりネットワーク カード)、光ファイバーなどの物理的に目に見える部品 (コネクタなどのすべての伝送媒体も含む) が含まれます。ハードウェアの範囲はリンク層の範囲内にあります
ネットワーク層は、ネットワーク上を流れるデータ パケットを処理するために使用されます。パケットは、ネットワーク上で送信されるデータの最小単位です。この層では、相手のコンピュータに到達し、データパケットを相手に送信するまでの経路（いわゆる伝送経路）を指定します。複数のコンピュータやネットワーク機器を介して他のコンピュータと通信する場合、多くの選択肢の中から通信経路を選択するのがネットワーク層の役割です。
トランスポート層は、上位アプリケーション層へのネットワーク接続内の 2 台のコンピュータ間のデータ送信を提供します。トランスポート層には、TCP (伝送制御プロトコル、伝送制御プロトコル) と UDP (ユーザー データ プロトコル、ユーザー データグラム プロトコル) の 2 つの異なるプロトコルがあります。
アプリケーション層は、アプリケーション サービスをユーザーに提供する際の通信アクティビティを決定します。
さまざまな一般的なアプリケーション サービスが、TCP/IP プロトコル スイートに事前に保存されています。たとえば、FTP (ファイル転送プロトコル、ファイル転送プロトコル) サービスと DNS (ドメイン ネーム システム、ドメイン ネーム システム) サービスがその 2 つです。
IP プロトコルの役割は、さまざまなデータ パケットを相互に送信することです。確実に相手に送信するには、さまざまな条件を満たす必要があります。重要な条件のうち 2 つは、IP アドレスと MAC アドレス (メディア アクセス コントロール アドレス) です。
IP アドレスはノードに割り当てられたアドレスを示し、MAC アドレスはネットワーク カードが属する固定アドレスを示します。IP アドレスは MAC アドレスと組み合わせることができます。IPアドレスは変更できますが、MACアドレスは基本的に変更されません。
IP 間の通信は MAC アドレスに依存します。ネットワーク上では、双方が同じローカル エリア ネットワーク (LAN) 内で通信することはまれで、通常は複数のコンピュータとネットワーク デバイスを転送することによってのみ相互に接続できます。転送中は、次の転送先デバイスの MAC アドレスを使用して次の転送先が検索されます。このとき、ARPプロトコル（AddressResolution Protocol）が使用されます。ARPとはアドレス解決に使用されるプロトコルで、通信相手のIPアドレスから対応するMACアドレスが分かります。
パソコンやルーターなどのネットワーク機器は、通信対象に到達するまでの通過過程において、非常に大まかな伝送経路しか学習できません。このメカニズムはルーティングと呼ばれ、宅配会社の配達プロセスに似ています。速達を希望する人は、配送センターに商品を送れば、運送会社が荷物を引き取って配達してくれるかどうかを知ることができ、運送会社の配送センターは、商品の配送先住所を確認して、どの住所に配送するかを特定します。次の停留所の地域では配送センターに送る必要があります。その後、その地域の配送センターが相手宅まで配送可能かどうかを判断します。
信頼性を確保する TCP プロトコル
データをエラーなく宛先に届けるために、TCP プロトコルは 3 ウェイ ハンドシェイク戦略を採用しています。TCPプロトコルでデータパケットを送り出すと、TCPは送信後の状況を無視することなく、相手に正しく届けられたかどうかを必ず確認します。
ハンドシェイク プロセスでは、TCP フラグ (フラグ) - SYN (同期) およびACK (確認応答) が使用されます。送信者はまず、SYN フラグを付けたデータ パケットを相手に送信します。受信側はそれを受信すると、確認情報を示すSYN/ACKフラグを付けたデータパケットを返送します。最後に、送信者は ACK フラグを付けたデータ パケットを送り返します。これは、「ハンドシェイク」の終了を意味します。
ドメイン名解決を担当する DNS サービス
DNS プロトコルは、ドメイン名から IP アドレスを検索したり、IP アドレスからドメイン名を逆検索したりするサービスを提供します。www.baidu.com は、最寄りのドメイン ネーム サーバーに IP アドレスを解決するよう要求します。http は、ターゲット サーバーへの http リクエスト メッセージの生成とリクエスト URL の解析を担当します。特定のホストの特定のディレクトリにあるリソースが必要であることがわかります。tcp は、バイト ストリーム サービス、複数のメッセージ セグメントの分割、および再構成を担当します。到着したセグメントから相手のアドレスを検索し、中継経路で転送するのがipの役割です。
永続的接続は、1 つの TCP 接続後に複数の要求と応答を確立するように設計されており、TCP 接続の繰り返しの確立と切断によって生じる追加のオーバーヘッドを削減し、サーバー側の負荷を軽減することが利点です。また、オーバーヘッド時間の一部が削減されるため、ＨＴＴＰリクエストとレスポンスがより早く完了することができ、その分Ｗｅｂページの表示速度が向上する。HTTP/1.1 では、デフォルトですべての接続が永続的になります。
永続的な接続により、ほとんどのリクエストをパイプライン方式で送信できます。以前にリクエストを送信した後、次のリクエストを送信する前に応答を受信するまで待機する必要があります。パイプライン技術の登場により、応答を待たずに次のリクエストを直接送信できるようになりました。
ログイン認証が必要な Web ページが状態自体を管理できない (ログイン状態を記録しない) と仮定すると、新しいページにジャンプするたびに、再度ログインするか、各リクエスト メッセージにパラメータを追加する必要があります。ログイン状態を管理します。
Cookie テクノロジは、リクエストおよび応答メッセージに Cookie 情報を書き込むことによってクライアントの状態を制御します。
Cookie は、サーバーから送信される応答メッセージ内の Set-Cookie と呼ばれるヘッダー フィールドの情報に従って、クライアントに Cookie を保存するように通知します。次回クライアントがサーバーにリクエストを送信するとき、クライアントはリクエスト メッセージに Cookie 値を自動的に追加して送信します。
サーバーはクライアントから送信された Cookie を検出すると、どのクライアントが接続リクエストを送信したかを確認し、サーバー上のレコードを比較して、最終的に以前のステータス情報を取得します。
3.2 リクエストメッセージとレスポンスメッセージの構造
リクエストメッセージの構造：
リクエストURL： https://www.mydrivers.com/zhuanti/tianti/cpu/index.html
リクエストメソッド： GET
ステータスコード： 304 Not Modified
リモートアドレス： 101.28.132.13 :443
リファラーポリシー: クロスオリジンの場合は厳密なオリジン
を受け入れる:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng, / ;q= 0.8,application/ signed-exchange;v=b3;q=0.7
Accept-Encoding:gzip,deflate,br
Accept-Language:zh-CN,zh;q=0.9,en;q=0.8,en-GB;q= 0.7,en- US;q=0.6
キャッシュ制御:max-age=0
接続:キープアライブ
クッキー:Hm_lvt_5c6ea7c88034ab979d4a14f9d840e0d0=1690280205,1690532327,1690771670,1690859915; Hm_lpvt_5c6ea7c88034ab979d4a14f9d840e0d0=1690859915; Hm_lvt_fa993fdd33f32c39cbb6e7d66096c422=1690280205,1690532327,1690771670,1690859915; Hm_lpvt_fa993fdd33f32c39cbb6e7d66096c422=1690859915
ホスト:www.mydrivers.com
If-Modified-Since:Sun, 09 Jul 2023 14:59:48 GMT
If-None-Match:“c4d451176b2d91:0”
Sec-Ch-Ua:“非/A)ブランド”;v=”99”, “Microsoft Edge”;v=”115”, “Chromium”;v=”115”
秒-Ch-Ua-モバイル:?0
秒-Ch-Ua-プラットフォーム:”Windows”
秒-Fetch-Dest:document
Sec-Fetch-Mode:navigate
Sec-Fetch-Site:none
Sec-Fetch-User:?1
Upgrade-Insecure-Requests:1
ユーザーエージェント:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.188
响应报文结构：
Connection:keep-alive
Content-Type:text/html
Date:Tue, 01 Aug 2023 03:18:38 GMT
Etag:“c4d451176b2d91:0”
Last-Modified:Sun, 09 Jul 2023 14:59: 48 GMT
Vary:Accept-Encoding
X-Cache:HIT from BC13_lt-hebei-handan-6-cache-1(baishan)
X-Ser:BC13_lt-hebei-handan-6-cache-1
HTTP通信では、クライアントとサーバーに加えて、プロキシ、ゲートウェイ、トンネルなど、通信データを転送するためのアプリケーションがいくつかあります。サーバーと連携して動作することができます。これらのアプリケーションとサーバーは、通信回線上の次のサーバーに要求を転送したり、そのサーバーから応答を受信してクライアントに転送したりできます。
プロキシ
proxy は、サーバーとクライアントの間の「仲介者」として機能し、クライアントから送信されたリクエストを受信してサーバーに転送したり、サーバーから返されたレスポンスを受信してサーバーに転送したりする転送機能を備えたアプリケーションです。クライアント。
ゲートウェイ
ゲートウェイは、他のサーバーからの通信データを転送するサーバーであり、クライアントからのリクエストを受信すると、あたかも専用の送信元サーバーがあるかのように処理します。場合によっては、クライアントは通信の宛先がゲートウェイであることさえ認識していない場合があります。
トンネル
トンネルは、遠く離れたクライアントとサーバー間の通信接続を転送および維持するアプリケーション プログラムです。
プロキシサーバーを使用する理由としては、後述するキャッシュ技術を利用してネットワーク帯域のトラフィックを削減するため、組織内の特定のWebサイトへのアクセスを制御するため、アクセスログを取得することが主な目的などがあります。
プロキシはさまざまな方法で使用でき、2 つの基準に分類されます。1 つはキャッシュを使用するかどうか、もう 1 つはメッセージを変更するかどうかです。
プロキシが
応答を転送するとき、キャッシング プロキシ (Caching Proxy) は事前にプロキシ サーバー上にリソースのコピー (キャッシュ) を保存します。プロキシが同じリソースに対するリクエストを再度受信すると、オリジン サーバーからリソースを取得せず、以前にキャッシュされたリソースを応答として返します。
透過プロキシ リクエスト
や応答を転送する際にパケットの処理を行わないプロキシを透過プロキシ(Transparent Proxy)と呼びます。逆に、メッセージの内容を処理するエージェントは非透過エージェントと呼ばれます。
ゲートウェイを使用すると、クライアントとゲートウェイ間の通信回線で暗号化を行って接続を保護できるため、通信のセキュリティが向上します。たとえば、ゲートウェイはデータベースに接続し、SQL ステートメントを使用してデータをクエリできます。また、Webショッピングサイトでクレジットカード決済を行う場合、ゲートウェイとクレジットカード決済システムとの連携が可能です。
トンネルは、必要に応じて他のサーバーと通信回線を確立し、SSL などの暗号化方式を使用して通信できます。トンネルの目的は、クライアントがサーバーと安全に通信できるようにすることです。トンネル自体は HTTP リクエストを解析しません。つまり、リクエストは変更されずに後続のサーバーに転送されます。トンネルは、通信当事者が切断されると終了します。
リクエスト ヘッダー フィールド名 説明
Cache-Control キャッシュ動作の制御
Connection ホップバイホップ ヘッダー、接続管理
Date メッセージ作成日時
プラグマ メッセージ命令
Trailer メッセージ末尾のヘッダーのリスト
Transfer-Encoding 転送エンコード方式を指定しますメッセージ本文の
アップグレード 他のプロトコルへのアップグレードに関する情報
プロキシ サーバー
経由 警告エラー通知
応答ヘッダーのフィールド名は、
Accept-Ranges がバイト範囲リクエストを受け入れるかどうかを示します
。 Age は、リソース作成経過時間を計算します。
ETag リソースの一致情報
Location は、クライアントを指定された URI にリダイレクトします。
Proxy-Authenticate プロキシ サーバーは、クライアントの認証情報を認証します。
Retry-After再度開始 リクエストのタイミング要件
サーバー HTTP サーバーのインストール情報
さまざま プロキシ サーバーのキャッシュされた管理情報
WWW-Authenticate サーバーからクライアントへの認証情報
エンティティヘッダフィールド名説明
リソースがサポートするHTTPメソッドを許可
Content-Encoding エンティティボディに適用できるエンコード方式
Content-Language エンティティボディの自然言語
Content-Length エンティティボディのサイズ（単位：バイト）
Content-Location URIを置き換えるContent-MD5 エンティティボディの
メッセージダイジェスト
Content-Range エンティティボディの位置範囲
Content-Type エンティティボディのメディアタイプ
Expires エンティティボディの有効期限が切れる日時
Last-Modified 最終変更リソースの日時