HTTP メッセージ
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 リクエストにおいて、開始行は『リクエスト行』と呼ばれます。
HTTP リクエストは、アクションを始めるためにクラアントからサーバーへ送られます。そのリクエスト行には、3 つの要素が含まれています。
-
HTTP メソッド。実行するアクションを表わす動詞 (
GET
、PUT
、POST
など) または名詞 (HEAD
、OPTIONS
)。例えばGET
はリソースを取り込むこと、POST
はデータをサーバーへ送信すること (リソースを作成または変更する、あるいは返送する一時的なドキュメントを生成する) ことを示します。 -
リクエスト対象。通常は URL ですが、プロトコル、ポート番号、ドメインの絶対パスは通常、リクエストの状況から明らかにされます。リクエスト対象の形式は、HTTP メソッドにより異なります。以下のような形式があります。
- 最後に
'?'
とクエリー文字列がある絶対パス。これはオリジン形式とも呼ばれているもっとも一般的な形式であり、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
- 完全な URL は絶対形式とも呼ばれ、主にプロキシーへ接続する際に
GET
で使用します。GET https://developer.mozilla.org/ja/docs/Web/HTTP/Messages HTTP/1.1
- ドメイン名とポート(省略可能。
':'
を前につける)で構成される、URL の authority の部分は認証形式と呼ばれます。これはCONNECT
で HTTP トンネルを設定するときに限り使用されます。CONNECT developer.mozilla.org:80 HTTP/1.1
- 単純なアスタリスク (
'*'
) であるアスタリスク形式はOPTIONS
で使用され、サーバー全体を表します。OPTIONS * HTTP/1.1
- 最後に
-
HTTP バージョン。これはメッセージの残りの部分の構造を定義しており、レスポンスで使用することを想定しているバージョンを示す役割もあります。
ヘッダー
リクエストの HTTP ヘッダー は、HTTP ヘッダーの一定の基本構造に従います。大文字・小文字を区別しない文字列の後にコロン (':'
) と、ヘッダーに応じた構造の値が続きます。値を含むヘッダー全体は 1 行で構成されており、とても長くなる場合もあります。
様々なヘッダーがリクエストに現れることがあります。これらはいくつかのグループに分類されます。
- 一般ヘッダーは、
Via
など、メッセージ全体に適用されるものです。 - リクエストヘッダーは、
User-Agent
,Accept
などで、指定するとリクエストを変更するもの(Accept-Language
など)、状況を示すもの(Referer
など)、条件を制約するもの(If-None
など)があります。 - 表現ヘッダーは
Content-Type
など、メッセージデータの下の形式や適用されているエンコーディングを説明します(メッセージの本体がある場合のみ存在します)。
本体
リクエストの最後の部分が本体 (body) です。本体が存在しないリクエストもあります。リソースを取り込むリクエストである GET
, HEAD
, DELETE
, OPTIONS
は通常、本体は不要です。サーバー内のデータを更新するためにデータを送信するリクエストもあり、 POST
リクエストでよくあります(HTML フォームのデータを持つ)。
本体は、大きく 2 種類に分類されます。
- 単一リソースの本体。1 個のファイルで構成され、
Content-Type
とContent-Length
の 2 つのヘッダーで定義されます。 - 複数リソースの本体。マルチパートの本体で構成され、それぞれが異なる情報を持ちます。これは主に、 HTML フォームと関連付けられます。
HTTP レスポンス
ステータス行
ヘッダー
レスポンスの HTTP ヘッダーは、他のヘッダーと同様に一定の基本構造に従います。大文字・小文字を区別しない文字列の後にコロン (':'
) と、ヘッダーの種類に応じた構造の値が続きます。値を含むヘッダー全体は 1 行で構成されます。
使用できるレスポンスヘッダーは多数あります。これらはいくつかのグループに分類されます。
- 一般ヘッダーは
Via
など、メッセージ全体に適用されるものです。 - レスポンスヘッダーは
Vary
やAccept-Ranges
など、ステータス行で伝えられないサーバーの追加情報を与えます。 - 表現ヘッダーは
Content-Type
など、レスポンスの本体に適用されます。通常、レスポンス内に本体がない場合はこのようなヘッダーは送信されません。
本体
レスポンスの最後の部分が本体です。本体を持たないレスポンスもあります。 201
Created
や 204
No Content
といったステータスコードのレスポンスは通常、本体がありません。
本体は、大きく 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 の構文と基盤となるトランスポートプロトコルの間の新たな中間層であり、根底は変わりません。実証された仕組みの上に構築されました。