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

3. Starting HTTP/2 (HTTP/2の開始)

HTTPリクエストを生成する実装は、サーバーがHTTP/2をサポートしているかどうかを発見する必要があります。

HTTP/2は、[HTTP] のセクション4.2で定義されている "http" および "https" URIスキームを使用し、HTTP/1.1 [HTTP/1.1] と同じデフォルトポート番号を使用します。これらのURIには、アップストリームサーバー (Upstream Server、クライアントが接続を確立したい直接のピア) がどのHTTPバージョンをサポートしているかについての指示は含まれていません。

HTTP/2のサポートを判断する方法は、"http" URIと "https" URIで異なります。"https" URIの発見はセクション3.2で説明されています。"http" URIのHTTP/2サポートは、帯域外の手段 (Out-of-Band Means) によってのみ発見でき、セクション3.3で説明されているように事前知識 (Prior Knowledge) が必要です。

3.1. HTTP/2 Version Identification (HTTP/2バージョン識別)​

本文書で定義されているプロトコルには2つの識別子があります。いずれかに基づいて接続を作成することは、本文書で説明されているトランスポート、フレーミング、およびメッセージセマンティクスの使用を意味します。

  • 文字列 "h2" は、HTTP/2がトランスポート層セキュリティ (Transport Layer Security, TLS) を使用するプロトコルを識別します。セクション9.2を参照してください。この識別子は、TLSアプリケーション層プロトコルネゴシエーション (Application-Layer Protocol Negotiation, ALPN) 拡張 [TLS-ALPN] フィールド、およびTLS上のHTTP/2を識別する任意の場所で使用されます。

    "h2" 文字列は、2オクテットシーケンス: 0x68, 0x32としてALPNプロトコル識別子にシリアライズされます。

  • "h2c" 文字列は、以前はHTTPアップグレードメカニズムのUpgradeヘッダーフィールド ([HTTP] のセクション7.8) で使用されるトークンとして使用されていました。この使用法は広く展開されることはなく、本文書によって非推奨となっています。これは、"h2c" へのアップグレードで使用されたHTTP2-Settingsヘッダーフィールドにも適用されます。

3.2. Starting HTTP/2 for "https" URIs ("https" URIのためのHTTP/2開始)​

"https" URIにリクエストを行うクライアントは、TLS [TLS13] とALPN拡張 [TLS-ALPN] を使用します。

TLS上のHTTP/2は "h2" プロトコル識別子を使用します。クライアントは "h2c" プロトコル識別子を送信してはならず (MUST NOT)、サーバーもそれを選択してはなりません (MUST NOT)。"h2c" プロトコル識別子は、TLSを使用しないプロトコルを記述します。

TLSネゴシエーションが完了すると、クライアントとサーバーの両方が接続プリフェイス (Connection Preface, セクション3.4) を送信しなければなりません (MUST)。

3.3. Starting HTTP/2 with Prior Knowledge (事前知識によるHTTP/2開始)​

クライアントは、他の手段によって特定のサーバーがHTTP/2をサポートしていることを知ることができます。例えば、クライアントはサーバーがHTTP/2をサポートしているという知識で構成されている可能性があります。

サーバーがHTTP/2をサポートしていることを知っているクライアントは、TCP接続を確立し、接続プリフェイス (セクション3.4) を送信し、その後HTTP/2フレームを送信できます。サーバーは、接続プリフェイスの存在によってこれらの接続を識別できます。これは、クリアテキストTCP上でのHTTP/2接続の確立にのみ影響します。TLS上のHTTP/2接続は、TLSでプロトコルネゴシエーション [TLS-ALPN] を使用しなければなりません (MUST)。

同様に、サーバーは接続プリフェイスを送信しなければなりません (MUST) (セクション3.4)。

追加情報がない場合、HTTP/2の以前のサポートは、特定のサーバーが将来の接続でHTTP/2をサポートするという強いシグナルではありません。例えば、サーバー構成が変更される可能性があり、クラスター化されたサーバーのインスタンス間で構成が異なる可能性があり、またはネットワーク条件が変更される可能性があります。

3.4. HTTP/2 Connection Preface (HTTP/2接続プリフェイス)​

HTTP/2では、各エンドポイントは、使用中のプロトコルの最終確認として、およびHTTP/2接続の初期設定を確立するために、接続プリフェイス (Connection Preface) を送信する必要があります。クライアントとサーバーはそれぞれ異なる接続プリフェイスを送信します。

クライアント接続プリフェイスは、24オクテットのシーケンスで始まり、16進表記では次のようになります:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

つまり、接続プリフェイスは文字列 "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n" で始まります。このシーケンスの後には、SETTINGSフレーム (セクション6.5) が続かなければならず (MUST)、このフレームは空である可能性があります (MAY)。クライアントは、接続の最初のアプリケーションデータオクテットとしてクライアント接続プリフェイスを送信します。

注意: クライアント接続プリフェイスは、HTTP/1.1またはHTTP/1.0サーバーおよび仲介者の大部分がさらなるフレームを処理しようとしないように選択されています。これは [TALKING] で提起された懸念には対処していないことに注意してください。

サーバー接続プリフェイスは、空である可能性のあるSETTINGSフレーム (セクション6.5) で構成され、このフレームはサーバーがHTTP/2接続で送信する最初のフレームでなければなりません (MUST)。

接続プリフェイスの一部としてピアから受信したSETTINGSフレームは、接続プリフェイスを送信した後に確認応答されなければなりません (MUST) (セクション6.5.3を参照)。

不必要な遅延を避けるために、クライアントは、サーバー接続プリフェイスの受信を待たずに、クライアント接続プリフェイスを送信した直後にサーバーに追加のフレームを送信することが許可されています。ただし、サーバー接続プリフェイスのSETTINGSフレームには、クライアントがサーバーとどのように通信することが期待されるかを必然的に変更する設定が含まれている可能性があることに注意することが重要です。SETTINGSフレームを受信すると、クライアントは確立された設定を尊重することが期待されます。一部の構成では、クライアントが追加のフレームを送信する前にサーバーがSETTINGSを送信できるため、この問題を回避する機会が提供されます。

クライアントとサーバーは、無効な接続プリフェイスをPROTOCOL_ERRORタイプの接続エラー (Connection Error, セクション5.4.1) として扱わなければなりません (MUST)。この場合、GOAWAYフレーム (セクション6.8) は省略される可能性があります (MAY)。無効なプリフェイスは、ピアがHTTP/2を使用していないことを示すためです。

に最終更新