[注意事項] [HTTP] 「グラフィックHTTP」第2章 シンプルHTTPプロトコル

序文

• このノートは、「グラフィック HTTP」を読んだ後に各章に含まれる知識をまとめたものです。
• ブログでは本の各章を記事として公開します。次のブログは不確実な時期に公開されます。
• 注意事項は個人的に理解した上で整理したものもありますので、ズレがあるかもしれませんが、読者の皆様もぜひご指摘くださいますよう、よろしくお願いいたします。

免責事項

• このブログは「Graphic HTTP」を勉強した後のメモであり、復習と復習を容易にすることを目的としており、営利目的ではありません。
• 便宜上、ブログ内の一部の写真は書籍の写真と一致しているため、自分でスクリーンショットを撮るのではなく、他の人のブログの写真アドレスを引用し、写真ベッドを提供してくれたブロガーに感謝の意を表しました。
• このメモは、この知識の要約を記録するために使用されます。今後の仕事や勉強をスムーズにするため。
• 内容は原作本では完結しておりませんので、原作本と併せてお読みください。
• 侵害がある場合は、すぐに通知し、削除してください。

第 2 章 簡易 HTTP プロトコル

2.1 クライアントとサーバー間の通信には HTTP が使用されます

1. HTTPプロトコルの詳しい説明

• クライアントとサーバー間の通信用

  • クライアント:テキストや画像などのリソースへのアクセスを要求する側。
  • サーバー:リソースへのアクセスを提供する側

• HTTP プロトコルを使用して 2 台のコンピュータ間で通信する場合、通信回線の一方の端はクライアント、もう一方の端はサーバーである必要があります。

• リクエストはクライアントが行う必要があり、サーバーは応答を返します。

  

• ステートレスプロトコルです

  • ステタスはありません：
    • 状態を保存しない
      • HTTP プロトコル自体は、リクエストと応答の間の通信状態を保存しません (つまり、プロトコルは、送信されたリクエストまたは応答を永続化しません)。
      • 新しいリクエストが送信されるたびに、対応する新しい応答が生成されます。
      • 以前のすべての要求または応答のメッセージ情報は保持されません。
    • 目的: 大量のトランザクションをより高速に処理します。
    • 利点: サーバーの CPU およびメモリ リソースの消費を削減できます。

• ステートレスプロトコルではありますが、目的の状態保持機能を実現するためにCookie技術が導入されています。

2.リクエストメッセージ

• リクエストメッセージ作成

  

  分野	説明を示します
  [メソッド](#5.サーバーに意図を通知するHTTPメソッド)	アクセスを要求するサーバーの種類
  [URI](# 4. リソースを見つけるための URI の要求)	アクセスを要求するリソース オブジェクトを示します
  プロトコルのバージョン	クライアントにHTTPプロトコル機能を使用するよう求める
  リクエストヘッダーフィールド
  コンテンツエンティティ

3. 応答メッセージ

• 応答メッセージの構成

  

  分野	説明を示します
  プロトコルのバージョン	サーバーに対応するHTTPバージョン
  ステータスコード	リクエストの処理結果のステータスコード
  ステータスコードの理由フレーズ
  応答ヘッダーフィールド	ヘッダーフィールドの各属性（応答日時）
  本体	リソースエンティティ

4. リソースを見つけるための URI を要求します

• HTTP プロトコルは、URI を使用してインターネット上のリソースを見つけます。
  • 【理由】 URI機能の一つで、インターネット上のどこにあるリソースにもアクセスできます。
• リクエストURIメソッド
  1. 完全なリクエスト URI
  2. 最初のフィールド「ホスト」にネットワーク ドメイン名または IP アドレスを書き込みます。
  3. 特定のリソースにアクセスしているのではなく、サーバー自体にリクエストを行っている場合は、*リクエスト URI を次の URL に置き換えることができます。

5. サーバーに意図を通知する HTTP メソッド

メソッド名	効果
得る	URI で識別されるリソースをリクエストするために使用されます
役職	エンティティの譲渡に使用されるプリンシパル
置く	ファイルの転送に使用される
頭	URI の有効性と自然更新の日時を確認する (つまり、メッセージのヘッダーを取得する)ために使用されます。
消去	ファイルを削除するために使用されます(通常、この方法は使用しません)
オプション	リクエスト URI に指定されたリソースサポートをクエリするために使用されるメソッド
痕跡	Web サーバーが以前のリクエスト通信をクライアントにループバックさせます (一般的には使用されませんが、XST クロスサイト追跡攻撃に対処しやすい)
接続する	トンネルプロトコルによるTCP通信を実現するには、プロキシサーバー通信でトンネルを確立する必要があります。

2.7 永続的な接続によりトラフィックが節約される

• 【通信の問題】 ・HTTP通信を行うたびにTCPコネクションを切断する必要がある

  • 多数のリソースにリクエストが読み込まれると、各リクエストによってわずかな TCP 接続の確立と切断が発生し、通信トラフィックのオーバーヘッドが増加します。

    

• 【の解き方】

1. 永続的な接続

• 特徴: どちらかの側が明示的に切断を提案しない限り、TCP 接続状態は維持されます。

  • 実装: TCP 接続を確立した後、複数の要求と応答の対話を実行します。

    

• 利点：

  1. TCP接続の確立と切断の繰り返しによって生じるオーバーヘッドを削減します。
  2. サーバー側の負荷が軽減される
  3. それに伴いWebページの表示速度も向上しました。

2. パイプライン化

• 次々に応答を待たずに、複数のリクエストを同時に並行して送信します。

• 永続的な接続テクノロジーよりも高速です。

  

2.8 Cookieによる状態管理

• 技術的な実装:リクエストおよびレスポンス メッセージに Cookie 情報を書き込むことで、クライアントのステータスを制御します。

• Cookie を使用して状態プロセスを保存します。

  

  1. Cookie は、サーバーから送信される応答メッセージ内の Set-Cookie と呼ばれるヘッダー フィールドの情報に従って、クライアントに Cookie を保存するように通知します。
  2. 次回クライアントがサーバーにリクエストを送信するとき、クライアントはリクエスト メッセージに Cookie 値を自動的に追加して送信します。
  3. サーバーはクライアントから送信された Cookie を検出すると、どのクライアントが接続リクエストを送信したかを確認し、サーバー上のレコードを比較して、最終的に以前のステータス情報を取得します。