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

9. HTTP/2 Connections (HTTP/2接続)

HTTP/2接続は、信頼性の高いトランスポート[TCP]の上で実行されるアプリケーション層プロトコルであり、トランスポート層セキュリティ (TLS) [TLS13]を使用してネットワークを介して交換されるデータを保護します。

HTTP/2は、HTTP/1.1と同じ"http"および"https" URIスキームを使用します。HTTP/2は同じデフォルトポート番号を共有します:"http" URIには80ポート、"https" URIには443ポートです。その結果、実装はhttp://example.org/fooやhttps://example.com/barなどのターゲットリソースURIへのリクエストを処理する必要がありますが、まず上流サーバー（クライアントが接続を確立したい直接のピア）がHTTP/2をサポートしているかどうかを発見する必要があります。

9.1. Connection Management (接続管理)​

HTTP/2接続は永続的です。最高のパフォーマンスを得るために、クライアントはサーバーとのさらなる通信が不要であることが判明するまで（たとえば、ユーザーが特定のWebページから移動したとき）、またはサーバーが接続を閉じるまで、接続を閉じないことが期待されます。

クライアントは、特定のホストとポートのペアに対して複数のHTTP/2接続を開くべきではありません (SHOULD NOT)。ここで、ホストはURI、選択された代替サービス[ALT-SVC]、または構成されたプロキシから派生します。

クライアントは、使用可能なストリーム識別子スペースを使い果たしかけている接続を置き換えるため (セクション5.1.1)、TLS接続のキーイングマテリアルを更新するため、またはエラーが発生した接続を置き換えるため (セクション5.4.1) に、代替として追加の接続を作成できます。

クライアントは、以下の目的で同じターゲットへの複数の接続を開くことができます (MAY): アトミックなリクエストを試みるために新しい接続を作成する (セクション9.1.2を参照)、またはGOAWAYフレームで受信された0より大きいストリーム識別子で"アクティブ"または"アイドル"状態にあるものを置き換える (セクション6.8を参照)。

サーバーは、可能な限り長時間接続を開いたままにすることが推奨されますが、必要に応じてアイドル接続を終了することが許可されています。いずれかのエンドポイントがトランスポート層TCP接続を閉じることを選択した場合、終了するエンドポイントは最初にGOAWAYフレーム (セクション6.8) を送信すべきです (SHOULD)。これにより、両方のエンドポイントが以前に送信されたフレームが処理されたかどうかを確実に判断し、必要な残りのタスクを正常に完了または終了できます。

9.1.1. Connection Reuse (接続の再利用)​

オリジンサーバーへの接続は、直接またはCONNECTメソッドを使用して作成されたトンネル経由で行われ (セクション8.5)、複数の異なるURI権限コンポーネントを持つリクエストに再利用できます (MAY)。オリジンサーバーが権威的である限り、接続は再利用できます (セクション10.1)。TLSなしのTCP接続の場合、これは同じIPアドレスに解決されたホストに依存します。

"https"リソースの場合、接続の再利用は、URIのホストに対して有効な証明書を持つことにも依存します。サーバーが提示する証明書は、クライアントがオリジン用に新しいTLS接続を形成する際に実行するチェックを満たさなければなりません (MUST)。

オリジンサーバーは、複数のオリジンを持つ証明書を提供する場合があり、それぞれが接続の使用に対して権威的です。たとえば、証明書はsubjectAltNameフィールドに複数のホスト名を含む場合があります。あるいは、ワイルドカードを含むホスト名も他のオリジンに適用できます。

場合によっては、URI権限が証明書で識別されるオリジンのセットと異なる場合があります（たとえば、一部のデプロイメントでは、URIを使用して他の場所で確立されたアイデンティティのアサーションを運ぶ）、権限の他の属性も一致しません。クライアントは既存の接続を使用しようとすることができますが (MAY)、クライアントが権威的であると考えるURIでリクエストを送信しなければなりません (MUST)。サーバーがリクエストを受け入れたくない場合、421 (Misdirected Request) ステータスコードを生成すべきです (SHOULD)。これにより、クライアントはリクエストを再試行します。

クライアントが再利用しようとしている接続が利用できなくなったことを発見した場合、新しい接続で安全でないリクエストを再試行できます (MAY)。

プロキシは同じオリジンサーバーへの接続を再利用できます (MAY)。

9.1.2. The 421 (Misdirected Request) Status Code (421（誤った方向のリクエスト）ステータスコード)​

421 (Misdirected Request) ステータスコードは、リクエストがレスポンスを生成できないサーバーに向けられたことを示します。これは、リクエストURIに含まれるスキームと権限の組み合わせに対してレスポンスを生成するように構成されていないサーバーによって送信される可能性があります。

421 (Misdirected Request) レスポンスを受信したクライアントは、リクエストメソッドが冪等であるかどうかにかかわらず、別の接続でリクエストを再試行できます (MAY)。これは、サーバーが権威的なレスポンスを提供しないことを選択する前にのみ421レスポンスコードを生成することが許可されているためです。

このステータスコードはプロキシによって生成されてはなりません (MUST NOT)。421レスポンスはキャッシュ可能です。レスポンスで特に指示されない限り、デフォルトでヒューリスティックにキャッシュ可能です（[HTTP-CACHING]のセクション4.2.2を参照）。

9.2. Use of TLS Features (TLS機能の使用)​

HTTP/2の実装は、"https" URIにTLSバージョン1.2 [TLS12]以降を使用しなければなりません (MUST)。TLS実装の使用に関する一般的なガイダンスは [TLSBCP] に記載されています。

TLSの実装は、Server Name Indication (SNI) [TLS-EXT]拡張をサポートしなければなりません (MUST)。HTTP/2クライアントは、ターゲットホストを示す代替メカニズムが提供されない限り、TLSハンドシェイク中にターゲットドメイン名を示さなければなりません (MUST)。

TLS 1.3 [TLS13]以降に依存するHTTP/2のデプロイメントは、クライアントとサーバーの両方でTLSアプリケーション層プロトコルネゴシエーション (ALPN) 拡張 [TLS-ALPN]をサポートし、使用すべきです (SHOULD)。これにより、ラウンドトリップを消費することなく、TLSハンドシェイク中にHTTP/2の使用が識別されます。

接続レベルのオプションはHTTPの使用に固有ではありませんが、HTTP/2を使用するサーバーは接続の好みを伝えることができます。TLSは暗号化を提供し、クライアントとサーバー間で交換される情報について盗聴者が学習する能力を最小化できます。TLSはまた、整合性保護を提供し、意図しないネットワーク破損や積極的な攻撃者による情報の変更を防ぎます。

HTTP/2の使用が交渉された後、[TLS12]のセクション7.4.1.4の規則に従わなければなりません (MUST)。これらの規則はサーバー証明書を使用してアイデンティティを確立します。クライアント証明書はこの目的には使用できません。証明書チェーンと証明機関 (CA) のチェックも必要です。

HTTP/2がTLS 1.2上で交渉された場合、TLS 1.2暗号スイートブラックリスト (セクション9.2.2) を提供しなければなりません (MUST)。

圧縮されたTLS証明書の使用は推奨されません。HTTP/2でクライアントとサーバーが使用する証明書は、クライアントによって明示的に要求されない限り、圧縮すべきではありません (SHOULD NOT)。

9.2.1. TLS 1.2 Features (TLS 1.2機能)​

このセクションでは、HTTP/2に固有のTLS 1.2の使用に関する制限について説明します。これらの制限は主にTLS 1.3で対処されているため、実装はTLS 1.3以降を使用することが推奨されます。TLS 1.2のみを使用する実装は、このセクションの要件に準拠しなければなりません (MUST)。

9.2.1.1. TLS 1.2 Features for HTTP/2 Clients (HTTP/2クライアントのTLS 1.2機能)​

HTTP/2クライアント実装は、ハンドシェイクの拡張フィールドを介してTLS Server Name Indication (SNI) [TLS-EXT]を送信することをサポートしなければなりません (MUST)。

HTTP/2クライアントは、TLS Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN]をサポートしなければなりません (MUST)。

9.2.1.2. TLS 1.2 Features for HTTP/2 Servers (HTTP/2サーバーのTLS 1.2機能)​

サーバーがALPNまたはNPN以外の方法でHTTP/2を交渉する場合、サーバーはクライアントにHTTP/2を使用する意思があるかどうかを示す機会を提供しなければなりません (MUST)。

HTTP/2サーバーは、extended master secret拡張 [RFC7627]を送信すべきです (SHOULD)。クライアントがこの拡張をサポートしていない場合、サーバーは以前に確立されたセッションを再開してはなりません (MUST NOT)。extended master secretが交渉された場合、サーバーは以前に確立されたセッションを再開できます (MAY)。

9.2.2. TLS 1.2 Cipher Suites (TLS 1.2暗号スイート)​

TLS 1.2上のHTTP/2のデプロイメントは、secp256r1 [RFC8422]楕円曲線を使用したTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]をサポートしなければなりません (MUST)。クライアントは、TLS ClientHelloメッセージのsupported_groups拡張 [TLS13]を介してサポートする曲線のサポートを示し、サーバーは拡張が提供するリストされた曲線のいずれかを選択することで曲線のサポートを示すことに注意してください。

クライアントは、HTTP/2で使用されるTLS 1.2上の任意の暗号スイートのサポートをアドバタイズできます (MAY)。ただし、以下にリストされている暗号スイートには、品質が低いことが知られている特性があるため、TLS 1.2上のHTTP/2での使用が禁止されています。これらのスイートには、以下の1つ以上の特性があります:

  • NULL暗号スイート。暗号化を提供しません。
  • ストリーム暗号ベースのスイート。TLSでの使用は攻撃に対して脆弱です。
  • RC4ベースのスイート。深刻なセキュリティ問題があります。
  • 3DESベースのスイート。実際のセキュリティが112ビット未満です。
  • CBCモードブロック暗号スイート。TLSでの攻撃に敏感で、特にTLS 1.2以前で顕著です。
  • RSA鍵交換ベースのスイート。前方秘匿性を提供しません。
  • TLSでの使用が推奨されないDiffie-Hellmanパラメータを使用するスイート。
  • AEADアルゴリズムのサポートが不十分なSHA-1ダイジェストを使用するスイート。

禁止された暗号スイートの完全なリストは、付録Aに記載されています。

9.3. Connection Preface (接続前言)​

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

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

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

つまり、接続前言は文字列 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n で始まります。このシーケンスの後には、SETTINGSフレーム (セクション6.5) が続かなければなりません (MUST)。これは空である場合があります (MAY)。クライアントは、サーバー接続前言を受信した直後にクライアント接続前言を送信します。

| 注意: クライアント接続前言は、他のHTTPプロトコルを処理するサーバーによってHTTP/2接続が | 有効なHTTP/1.1リクエストとして見なされる可能性を最小限に抑えるように選択されています。 | HTTP/1.1リクエストがメソッドトークンとして"PRI"を含むことは合理的ではありません。

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

HTTP/1.1（またはそれ以前）を必要とする101 (Switching Protocols) レスポンスを受信してアップグレードしているクライアントは、クライアント接続前言を直ちに送信しなければなりません (MUST)。

サーバーはクライアント接続前言を受信し、クライアントはサーバー接続前言を受信します。接続前言のSETTINGSフレームは、さらなる接続確立の一部として確認されなければなりません (MUST) (セクション6.5.3を参照)（セクション3.4を参照）。

不必要な遅延を避けるために、クライアントは、サーバー接続前言を受信するのを待たずに、クライアント接続前言を送信した直後にサーバーに追加のフレームを送信することが許可されています。ただし、サーバー接続前言のSETTINGSフレームには、サーバーと通信するために遵守する必要があるパラメータが含まれている場合があることに注意することが重要です。SETTINGSフレームを受信すると、クライアントは確立されたパラメータを遵守すべきです (SHOULD)。一部の構成では、クライアントが追加のフレームを送信する前にサーバーがSETTINGSを送信することが可能で、この問題を回避する機会を提供します。

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

第9章完了！

References​

  • [TCP] RFC 793
  • [TLS13] RFC 8446
  • [TLS12] RFC 5246
  • [TLS-EXT] RFC 6066
  • [TLS-ALPN] RFC 7301
  • [TLSBCP] RFC 9325
  • [TLS-ECDHE] RFC 5289
  • [RFC8422] RFC 8422
  • [RFC7627] RFC 7627
  • [ALT-SVC] RFC 7838
  • [HTTP-CACHING] RFC 9111
に最終更新