メインコンテンツまでスキップ

2. HTTP/2 Protocol Overview (HTTP/2プロトコル概要)

HTTP/2は、HTTPセマンティクスのための最適化されたトランスポートを提供します。HTTP/2は、HTTPのすべてのコア機能をサポートしますが、HTTP/1.1よりも効率的であることを目指しています。

HTTP/2は、TCP接続 ([TCP]) 上で実行される接続指向のアプリケーション層プロトコル (Connection-Oriented Application-Layer Protocol) です。クライアントはTCP接続の開始者です。

HTTP/2における基本プロトコル単位はフレーム (Frame, Section 4.1) です。各フレームタイプは異なる目的に対応します。例えば、HEADERSおよびDATAフレームはHTTPリクエストとレスポンスの基礎を形成します (Section 8.1)。SETTINGS、WINDOW_UPDATE、PUSH_PROMISEなどの他のフレームタイプは、他のHTTP/2機能をサポートするために使用されます。

リクエストの多重化 (Multiplexing) は、各HTTPリクエスト/レスポンス交換をそれ自身のストリーム (Stream, Section 5) に関連付けることで実現されます。ストリームは大部分が互いに独立しているため、ブロックまたは停止したリクエストまたはレスポンスが他のストリームの進行を妨げることはありません。

多重化の効果的な使用は、フロー制御 (Flow Control) と優先順位付け (Prioritization) に依存します。フロー制御 (Section 5.2) は、送信されるデータを受信者が処理できる内容に制限することで、多重化されたストリームを効率的に使用できることを保証します。優先順位付け (Section 5.3) は、限られたリソースが最も効果的に使用されることを保証します。このHTTP/2の改訂版は、[RFC7540] の優先順位シグナリングスキームを非推奨としています。

接続で使用されるHTTPフィールドには大量の冗長データが含まれる可能性があるため、それらを含むフレームは圧縮されます (Section 4.3)。これは、一般的なケースでリクエストサイズに特に有利な影響を与え、多くのリクエストを1つのパケットに圧縮できます。

最後に、HTTP/2は、サーバーがクライアントにレスポンスをプッシュできる新しいオプションの相互作用モード (Interaction Mode) を追加します (Section 8.4)。これは、サーバーがクライアントが必要とすることを予測するデータを投機的にクライアントに送信できるようにすることを目的としており、潜在的なレイテンシの向上と引き換えにいくらかのネットワーク使用量をトレードオフします。サーバーは、リクエストを合成することでこれを実現し、それをPUSH_PROMISEフレームとして送信します。その後、サーバーは別のストリーム上で合成リクエストに対するレスポンスを送信できます。

2.1. Document Organization (文書構成)

HTTP/2仕様は4つの部分に分かれています:

  • HTTP/2の開始 (Starting HTTP/2, Section 3) は、HTTP/2接続がどのように開始されるかをカバーします。

  • フレーム層 (Frame Layer, Section 4) とストリーム層 (Stream Layer, Section 5) は、HTTP/2フレームがどのように構造化され、多重化されたストリームに形成されるかを説明します。

  • フレーム定義 (Frame Definitions, Section 6) とエラー定義 (Error Definitions, Section 7) には、HTTP/2で使用されるフレームとエラータイプの詳細が含まれます。

  • HTTPマッピング (HTTP Mappings, Section 8) と追加要件 (Additional Requirements, Section 9) は、フレームとストリームを使用してHTTPセマンティクスがどのように表現されるかを説明します。

フレーム層とストリーム層の概念の一部はHTTPから分離されていますが、本仕様は完全に汎用的なフレーム層を定義していません。フレーム層とストリーム層は、HTTPのニーズに合わせて調整されています。

2.2. Conventions and Terminology (規約と用語)

本文書のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] に記載されているように解釈されるものとします (MAY)。ただし、ここに示すようにすべて大文字で表示される場合に限ります。

すべての数値はネットワークバイトオーダー (Network Byte Order) です。特に指定がない限り、値は符号なしです。リテラル値は、必要に応じて10進数または16進数で提供されます。16進数リテラルには、10進数リテラルと区別するために "0x" が前置されます。

本仕様は、RFC 9000 [QUIC] のセクション1.3で説明されている規約を使用してバイナリ形式を記述します。この形式はネットワークバイトオーダーを使用し、高位ビットが低位ビットの前にリストされることに注意してください。

以下の用語が使用されます:

クライアント (Client): HTTP/2接続を開始するエンドポイント。クライアントはHTTPリクエストを送信し、HTTPレスポンスを受信します。

接続 (Connection): 2つのエンドポイント間のトランスポート層接続。

接続エラー (Connection Error): HTTP/2接続全体に影響を与えるエラー。

エンドポイント (Endpoint): 接続のクライアントまたはサーバー。

フレーム (Frame): HTTP/2接続内の最小通信単位。ヘッダーとフレームタイプに従って構造化された可変長オクテットシーケンスで構成されます。

ピア (Peer): エンドポイント。特定のエンドポイントについて議論する際、"ピア" は議論の主題に対してリモートなエンドポイントを指します。

受信者 (Receiver): フレームを受信しているエンドポイント。

送信者 (Sender): フレームを送信しているエンドポイント。

サーバー (Server): HTTP/2接続を受け入れるエンドポイント。サーバーはHTTPリクエストを受信し、HTTPレスポンスを送信します。

ストリーム (Stream): HTTP/2接続内の双方向フレームフロー。

ストリームエラー (Stream Error): 個々のHTTP/2ストリーム上のエラー。

最後に、用語 "ゲートウェイ (Gateway)"、"インターミディアリ (Intermediary)"、"プロキシ (Proxy)"、および "トンネル (Tunnel)" は、[HTTP] のセクション3.7で定義されています。インターミディアリは、異なる時点でクライアントとサーバーの両方として機能します。

メッセージボディに適用される用語 "コンテンツ (Content)" は、[HTTP] のセクション6.4で定義されています。