HTTP メッセージは、サーバーとクライアントがデータを交換する手段です。クライアントが送信してサーバーにアクションを起こさせるリクエストと、サーバーの回答であるレスポンスの、2 種類のメッセージがあります。
HTTP メッセージは ASCII でエンコードされたテキスト情報で構成されており、複数の行にまたがります。HTTP/1.1 およびそれより前のバージョンのプロトコルでは、メッセージがコネクション内でそのまま送信されます。HTTP/2 では、人間が読める形式のメッセージを HTTP フレームに分割して、最適化やパフォーマンスの向上を実現します。
ウェブ開発者やウェブ管理者がこれらテキスト形式の HTTP メッセージを作成することはめったにありません。ウェブブラウザー、プロキシ、ウェブサーバーといったソフトウェアが行います。それらは HTTP メッセージを設定ファイル (プロキシやサーバー)、API (ブラウザー)、あるいは他のインターフェイスによって提供します。
HTTP/2 のバイナリフレーム化方式は、適用される API や設定ファイルの変更を必要としないように設計されています。これはユーザーに対して透過的です。
HTTP のリクエストやレスポンスは似た構造を共用しており、以下の要素で構成されます:
- 実行するリクエスト、または成功か失敗かの状態を表す開始行。開始行は常に 1 行です。
- リクエストの詳細を示す、またはメッセージに含まれるボディを説明する、省略可能な HTTP ヘッダー一式。
- リクエストのメタ情報がすべて送信されたことを示す空行。
- リクエストに関連付けられたデータ (HTML フォームの内容など)、あるいはレスポンスに関連付けられたドキュメントを含む、省略可能なボディ。ボディが存在することやそのサイズは、開始行や HTTP ヘッダーで指定します。
HTTP メッセージの開始行と HTTP ヘッダーは、まとめてリクエストのヘッドとして知られています。一方、ペイロードはボディとして知られています。
HTTP リクエスト
開始行
HTTP リクエストは、アクションを始めるためにクラアントからサーバーへ送られます。その開始行には、3 つの要素が含まれています:
- HTTP メソッド。実行するアクションを表わす動詞 (
GET、PUT、POSTなど) または名詞 (HEAD、OPTIONS)。例えばGETはリソースを取り込むこと、POSTはデータをサーバーへ送信すること (リソースを作成または変更する、あるいは返送する一時的なドキュメントを生成する) ことを示します。 - リクエスト対象。通常は URL ですが、プロトコル、ポート、ドメインの絶対パスは通常、リクエストの状況から明らかにされます。リクエスト対象の形式は、HTTP メソッドにより異なります。以下のような形式があります。
- 最後に
'?'とクエリー文字列がある絶対パス。これは origin form として知られているもっとも一般的な形式であり、GET、POST、HEAD、OPTIONSメソッドで使用します。
POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0 - absolute form として知られている完全な URL は、主にプロキシへ接続する際に
GETで使用します。
GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1 - ドメイン名とポート (省略可能。
':'を前につける) で構成される、URL の authority の部分は authority form と呼ばれます。これはCONNECTで HTTP トンネルを設定するときに限り使用されます。
CONNECT developer.mozilla.org:80 HTTP/1.1 - 単なるアスタリスク (
'*') である asterisk form はOPTIONSで使用されており、サーバー全体を表します。
OPTIONS * HTTP/1.1
- 最後に
- HTTP バージョン。これはメッセージの残りの部分の構造を定義しており、レスポンスで使用することを想定しているバージョンを示す役割もあります。
ヘッダー
リクエストの HTTP ヘッダー は、HTTP ヘッダーの一定の基本構造に従います。大文字・小文字を区別しない文字列の後にコロン (':') と、ヘッダーに応じた構造の値が続きます。値を含むヘッダー全体は 1 行で構成されており、とても長くなる場合もあります。
使用できるリクエストヘッダーは多数あります。これらはいくつかのグループに分類されます:
- 一般ヘッダーは
Viaなど、メッセージ全体に適用されるものです。 - リクエストヘッダーは
User-Agent、Accept-Type、指定するとリクエストを変更するもの (Accept-Languageなど)、状況を示すもの (Refererなど)、条件を与えるもの (If-None) があります。 - エンティティヘッダーは
Content-Lengthなど、リクエストのボディに適用されます。当然ながら、リクエスト内にボディがない場合はこれらのヘッダーが送信されません。
ボディ
リクエストの最後の部分がボディです。ボディが存在しないリクエストもあります。リソースを取り込むリクエストである GET や HEAD、DELETE、OPTIONS は通常、ボディが不要です。サーバー内のデータを更新するためにデータを送信するリクエストもあり、POST リクエストでよくあります (HTML フォームのデータを持つ)。
ボディは、大きく 2 種類に分類されます:
- 単一リソースのボディ。1 個のファイルで構成され、
Content-TypeとContent-Lengthの 2 つのヘッダーで定義されます。 - 複数リソースのボディ。マルチパートのボディで構成され、それぞれが異なる情報を持ちます。これは主に、HTML フォーム と関連付けられます。
HTTP レスポンス
ステータス行
HTTP レスポンスの開始行はステータス行と呼ばれ、以下の情報を持ちます:
- プロトコルバージョン。通常
HTTP/1.1です。 - ステータスコード。リクエストが成功したか失敗したかを示します。一般的なステータスコードは
200、404、302です。 - ステータス文字列. 手短な単なる情報ですが、人間が HTTP メッセージを理解するのを助けるために、ステータスコードをテキストで説明します。
一般的に、ステータス行は以下のようになります: HTTP/1.1 404 Not Found
ヘッダー
レスポンスの HTTP ヘッダー は、他のヘッダーと同様に一定の基本構造に従います。大文字・小文字を区別しない文字列の後にコロン (':') と、ヘッダーの種類に応じた構造の値が続きます。値を含むヘッダー全体は 1 行で構成されます。
使用できるリクエストヘッダーは多数あります。これらはいくつかのグループに分類されます:
- 一般ヘッダーは
Viaなど、メッセージ全体に適用されるものです。 - レスポンスヘッダーは
VaryやAccept-Rangesなど、ステータス行で伝えられないサーバーの追加情報を与えます。 - エンティティヘッダーは
Content-Lengthなど、リクエストのボディに適用されます。当然ながら、リクエスト内にボディがない場合はこれらのヘッダーが送信されません。
ボディ
レスポンスの最後の部分がボディです。ボディを持たないレスポンスもあります。201 や 204 といったステータスコードのレスポンスは通常、ボディがありません。
ボディは、大きく 3 種類に分類されます:
- サイズが判明している 1 個のファイルで構成される、単一リソースのボディ。
Content-TypeとContent-Lengthの 2 つのヘッダーで定義されます。 - サイズが不明な 1 個のファイルで構成される、単一リソースのボディ。
Transfer-Encodingをchunkedに設定して、chunked 形式でエンコードされます。 - 複数リソースのボディ。マルチパートのボディで構成され、それぞれが異なる情報のセクションを持ちます。これは比較的まれです。
HTTP/2 フレーム
HTTP/1.x のメッセージには、パフォーマンスの欠点があります:
- ヘッダーはボディと異なり、圧縮されません。
- あるメッセージと次のメッセージでヘッダーが酷似していることがよくありますが、それでも複数のコネクションにわたって繰り返されます。
- 多重化することができません。同じサーバーに対して複数のコネクションを開かなければなりません。また、ウォーム状態の TCP コネクションはコールド状態のコネクションより効率的です。
HTTP/2 は次の段階に進みました。HTTP/1.x のメッセージを、ストリーム内に埋め込まれるフレームに分割します。データのフレームとヘッダーのフレームは区別され、ヘッダーの圧縮が可能になります。多重化と呼ばれる処理によって複数のストリームがまとめられ、下層の TCP コネクションの効率を向上させることができます。
HTTP フレームは、ウェブ開発者によって透過的になります。これは HTTP/2 において、HTTP/1.1 メッセージと基盤となるトランスポート層との間のさらなるステップです。HTTP フレームを利用するためにウェブ開発者が使用する API を変更する必要はありません。ブラウザーとサーバーの両方で利用可能になれば、HTTP/2 が有効になり使用されます。
まとめ
HTTP メッセージは、HTTP を使用する際に重要なものです。その構造はシンプルであり、拡張性が高くなっています。HTTP/2 のフレーム化機能は、HTTP/1.x の構文と基盤となるトランスポートプロトコルの間の新たな中間層であり、根底は変わりません。実証された仕組みの上に構築されました。