1はじめに
HTTPプロトコルの原理を理解するには、HTTPメッセージについて話す必要があります。HTTPメッセージはテキスト指向であり、メッセージの各フィールドはASCII文字列であり、各フィールドの長さは不確定です。HTTPメッセージには、要求メッセージと応答メッセージの2種類があります。HTTPメッセージを理解する前に、パケットキャプチャツールを使用して、要求元ネットワークの要求メッセージと応答メッセージを表示できます。パケットキャプチャツールは、FiddleまたはCharleを推奨します。たとえば、ブラウザーでhttp://msdn.itellyou.cn/にアクセスし、Fiddlerを介してパケットをキャプチャすると、次のように要求メッセージと応答メッセージが表示されます。
2 HTTPリクエストメッセージ
HTTP要求メッセージは、要求行、要求ヘッダー、空白行、および要求データの4つの部分で構成されます。一般的な形式を以下に示します。
リクエストライン
要求行は、スペースで区切られた要求メソッドフィールド、URIフィールド、およびHTTPプロトコルバージョンフィールドで構成されます。形式は次のとおりです。メソッドRequest-URI HTTP-Version CRLF。上の図に示すように、GET http://msdn.itellyou.cn/ HTTP / 1.1です。
メソッド はリクエストメソッドを示し、以下に示すように様々なリクエストメソッドがあります。
GET：Request-URIで識別されるリソースを取得するための要求。
POST：Request-URIで識別されるリソースの後に新しいデータを追加します。
HEAD：Request-URIで識別されるリソースの応答メッセージヘッダーを取得するための要求。
PUT：サーバーにリソースを格納するように要求し、その識別子としてRequest-URIを使用します。
DELETE：Request-URIで識別されるリソースを削除するようサーバーに要求します。
TRACE：要求サーバーは、主にテストまたは診断に使用される、受信した要求情報を送り返します。
CONNECT：HTTP 1.1プロトコルは、パイプラインへの接続を変更できるプロキシサーバー用に予約されています。
オプション：サーバーのパフォーマンスのクエリ、またはリソースに関連するオプションと要件のクエリを要求します。
PATCH：エンティティには、URIで表される元のコンテンツとの違いを説明するテーブルが含まれています。
MOVE：指定したページを別のネットワークアドレスに移動するようサーバーに要求します。
COPY：指定したページを別のネットワークアドレスにコピーするようサーバーに要求します。
LINK：リンク関係を確立するようサーバーに要求します。
リンク解除：リンクを切断します。
WRAPPED：クライアントがカプセル化されたリクエストを送信できるようにします。
Extension-mothed：プロトコルを変更せずにメソッドを追加できます。
Request-URIはユニフォームリソース識別子です。
HTTP-Versionは、要求されたHTTPプロトコルのバージョンを示します
CRLFは、キャリッジリターンとラインフィードを表します（末尾のCRLFを除き、個別のCRまたはLF文字は許可されていません）。
リクエストヘッダー
リクエスト行の後に0個以上のリクエストヘッダーがあり、各リクエストヘッダーには名前と値が含まれており、英語のコロン「：」で区切られています。詳細については、以下のヘッダーの紹介をご覧ください。
空行
最後のリクエストヘッダーが空白行になったら、キャリッジリターンとラインフィードで、リクエストヘッダーがなくなったことをサーバーに通知します。
データをリクエストする
リクエストデータは通常、POSTメソッドのリクエストに使用されます。POSTメソッドは、ユーザーがフォームに入力する必要がある場合に適しています。最も一般的に使用されるリクエストヘッダーは、Content-TypeとContent-Lengthです。
3 HTTP応答メッセージ
要求メッセージを受信して解釈した後、サーバーはHTTP応答メッセージを返します。HTTP応答メッセージは、ステータス行、メッセージヘッダー、空白行、応答本文の4つの部分で構成されます。一般的な形式を以下に示します。
ステータスライン
ステータス行は、スペースで区切られた、HTTPプロトコルバージョン、応答ステータスコード、およびステータスコードのテキスト説明フィールドで構成されます。形式は次のとおりです。HTTPバージョンステータスコード理由フレーズCRLF。上の図に示すように：HTTP / 1.1 200 OK。
Status-Codeは応答ステータスコードを表します。これは3桁で構成されます。最初の桁は応答のカテゴリを定義し、次の5つの可能な値があります。
100〜199：表示メッセージ、リクエストを受信、リクエスタは操作を続行する必要があります。
200〜299：リクエストは成功し、リクエストは正常に受信され、処理されました。
300〜399：リダイレクトリクエストを完了するには、さらに操作を行う必要があります。
400〜499：クライアントエラー、リクエストに構文エラーがあるか、リクエストを処理できません。
500〜599：サーバーエラー、サーバーが正当なリクエストを処理できません。
最も一般的なステータスコードとステータスの説明：
200 OK：クライアント要求は成功しました。
400 Bad Request：クライアント要求に、サーバーが理解できない構文エラーがあります。
401 Unauthorized：リクエストは不正です。このステータスコードは、WWW-Authenticateヘッダーフィールドで使用する必要があります。
403 Forbidden：サーバーはリクエストを受信しましたが、サービスの提供を拒否しています。
500内部サーバーエラー：内部サーバーエラー、要求を完了できません。
503サーバーを使用できません：サーバーは現在クライアント要求を処理できません。しばらくすると通常に戻ることがあります。
その他のステータスコードについては、HTTPステータスコード比較表をご覧ください。
応答ヘッダー
リクエストヘッダーと同様に、各レスポンスヘッダーには、英語のコロン「：」で区切られた名前と値が含まれています。詳細については、以下のヘッダーの紹介をご覧ください。
空行
最後の応答ヘッダーの後には空白行、キャリッジリターン、ラインフィードがあります。
レスポンスボディ
応答本文は、サーバーによって返されるリソースのコンテンツです。
4ヘッダー
HTTPメッセージヘッダーは、一般ヘッダー、要求ヘッダー、応答ヘッダー、エンティティヘッダーに分かれています。これらはキーと値のペアで構成され、1行に1つのペアがあり、ヘッダーフィールドの名前と値は英語のコロン「：」で区切られています。ヘッダーフィールド名では大文字と小文字が区別されません。ヘッダーには、クライアントまたはサーバーのプロパティ、送信されるリソース、および確立する必要のある接続が記述されています。
共通ヘッダー
汎用ヘッダーは、要求の登録ヘッダーと応答ヘッダーの両方で使用できます。たとえば、次のとおりです。
日付：メッセージが生成された日時を示します。
接続：接続を継続するかどうかの指定や、応答の完了後にサーバーに接続を閉じるよう通知する閉じるオプションの指定など、接続を指定するためのオプションを送信できます。
キャッシュ制御：キャッシュ命令を指定するために使用されます。キャッシュ命令は一方向であり（応答に現れるキャッシュ命令は要求に現れない場合があります）、独立しています（1つのメッセージのキャッシュ命令は別のメッセージ処理のキャッシュに影響しません）メカニズム）。
リクエストヘッダー
リクエストヘッダーは、クライアントが自分自身と必要な応答フォームに関する情報を渡せるようにするためのもので、クライアントのリクエストについてサーバーに通知します。一般的なリクエストヘッダーを以下に示します。
ホスト：要求されたホスト名。複数のドメイン名を同じIPアドレス、つまり仮想ホストに含めることができます。
User-Agent：リクエストを送信したブラウザのタイプやオペレーティングシステムなどの情報。
Accept：クライアントが認識できるコンテンツタイプのリストで、クライアントが受信する情報のタイプを指定します。
Accept-Encoding：クライアントによって認識されるデータエンコーディング。
Accept-Language：ブラウザがサポートする言語タイプを示します。
接続：クライアントとサーバーは、リクエスト/レスポンス接続に関連するオプションを指定できます。たとえば、現時点でのキープアライブは、接続を維持することを意味します。
Transfer-Encoding：メッセージの信頼できる送信を保証するために使用されたエンコーディング方法を受信者に通知します。
応答ヘッダー
サーバーは応答ヘッダーを使用して、独自の応答情報を渡します。典型的な応答ヘッダーを以下に示します。
場所：受信者を新しい場所にリダイレクトするために使用され、ドメイン名を変更するときによく使用されます。
サーバー：サーバーが要求を処理するために使用するシステム情報が含まれ、User-Agent要求ヘッダーに対応します。
エンティティヘッダー
エンティティヘッダーは、送信されるリソースの情報を定義するために使用され、要求と応答の両方に使用できます。要求メッセージと応答メッセージの両方でエンティティを送信できます。一般的なエンティティヘッダーを以下に示します。
Content-Type：受信者に送信されるエンティティボディのメディアタイプ。
Content-Lenght：エンティティ本体の長さを示すために使用され、バイトで格納される10進数として表されます。
Content-Language：リソースで使用される自然言語について説明します。このオプションが設定されていない場合、エンティティコンテンツはすべての言語の読み取りに対して提供されます。
Content-Encoding：メディアタイプの修飾子として使用されます。その値は、エンティティの本文に適用されている追加コンテンツのエンコードを示します。したがって、Content-Typeヘッダーフィールドで参照されているメディアタイプを取得するには、対応するデコードメカニズムを使用する必要があります。
Last-Modified：リソースの最終変更日時を示すために使用されます。
有効期限：応答の有効期限が切れる日時を示すために使用されます。
ヘッダーの導入の詳細については、HTTP応答ヘッダーと要求ヘッダー情報の比較表を参照してください。
