3. Connection Setup and Management (接続のセットアップと管理)

3.1. Discovering an HTTP/3 Endpoint (HTTP/3エンドポイントの発見)

HTTPは、権威的な応答 (Authoritative Response) の概念に依存しています。これは、応答メッセージの発信時に、ターゲットURIで識別されるオリジンサーバー（またはその指示の下で）によって決定されたターゲットリソースの状態に対して、そのリクエストに最も適切な応答であると判断された応答です。HTTP URIの権威サーバーの特定については、[HTTP] のセクション4.3で説明されています。

"https"スキームは、URIの権威コンポーネント (Authority Component) で識別されるホストに対してクライアントが信頼できると見なす証明書の所有と権威を関連付けます。TLSハンドシェイクでサーバー証明書を受信すると、クライアントは、[HTTP] のセクション4.3.4で説明されているプロセスを使用して、証明書がURIのオリジンサーバー (Origin Server) に対して許容可能な一致であることを検証しなければなりません (MUST)。URIのオリジンサーバーに対して証明書を検証できない場合、クライアントはそのオリジンに対してサーバーを権威あるものと見なしてはなりません (MUST NOT)。

クライアントは、"https" URIを持つリソースへのアクセスを次の方法で試みてもよいです (MAY)：ホスト識別子をIPアドレスに解決し、指定されたポートでそのアドレスへのQUIC接続を確立し（上記のようにサーバー証明書の検証を含む）、その安全な接続を介してURIをターゲットとするHTTP/3リクエストメッセージをサーバーに送信します。HTTP/3を選択するために他のメカニズムが使用されない限り、TLSハンドシェイク中のアプリケーション層プロトコルネゴシエーション (Application-Layer Protocol Negotiation, ALPN; [RFC7301] を参照) 拡張でトークン"h3"が使用されます。

接続の問題（例：UDPのブロック）により、QUIC接続の確立に失敗する可能性があります。この場合、クライアントはTCPベースのバージョンのHTTPを使用することを試みるべきです (SHOULD)。

サーバーは任意のUDPポートでHTTP/3を提供してもよいです (MAY)。代替サービスアドバタイズメント (Alternative Service Advertisement) には常に明示的なポートが含まれ、URIには明示的なポートまたはスキームに関連付けられたデフォルトポートが含まれます。

3.1.1. HTTP Alternative Services (HTTP代替サービス)

HTTPオリジン (Origin) は、Alt-Svc HTTPレスポンスヘッダーフィールドまたはHTTP/2 ALTSVCフレーム ([ALTSVC]) を使用して、"h3" ALPNトークンを使用することで、同等のHTTP/3エンドポイントの可用性をアドバタイズできます。

たとえば、オリジンは、同じホスト名のUDPポート50781でHTTP/3が利用可能であることを、次のヘッダーフィールドを含めることでHTTPレスポンスで示すことができます：

Alt-Svc: h3=":50781"

HTTP/3サポートを示すAlt-Svcレコードを受信すると、クライアントは指定されたホストとポートへのQUIC接続の確立を試みてもよいです (MAY)。この接続が成功した場合、クライアントは本文書で説明されているマッピングを使用してHTTPリクエストを送信できます。

3.1.2. Other Schemes (その他のスキーム)

HTTPはトランスポートプロトコルから独立していますが、"http"スキームは、権威コンポーネント内で識別される任意のホストの指定されたポートでTCP接続を受信する能力と権威を関連付けます。HTTP/3はTCPを使用しないため、HTTP/3は"http" URIで識別されるリソースの権威サーバーへの直接アクセスには使用できません。ただし、[ALTSVC] などのプロトコル拡張により、権威サーバーは、同様に権威があり、HTTP/3経由で到達可能な他のサービスを識別できます。

スキームが"https"でないオリジンに対してリクエストを行う前に、クライアントはサーバーがそのスキームを提供する意思があることを確認しなければなりません (MUST)。スキームが"http"のオリジンについては、これを達成する実験的な方法が [RFC8164] で説明されています。将来、さまざまなスキームに対して他のメカニズムが定義される可能性があります。

3.2. Connection Establishment (接続の確立)

HTTP/3は、基盤となるトランスポートとしてQUICバージョン1に依存しています。他のQUICトランスポートバージョンをHTTP/3で使用することは、将来の仕様で定義されてもよいです (MAY)。

QUICバージョン1は、ハンドシェイクプロトコル (Handshake Protocol) としてTLSバージョン1.3以上を使用します。HTTP/3クライアントは、TLSハンドシェイク中にターゲットホストをサーバーに示すメカニズムをサポートしなければなりません (MUST)。サーバーがドメイン名 ([DNS-TERMS]) によって識別される場合、クライアントは、ターゲットホストを示す代替メカニズムが使用されない限り、サーバー名表示 (Server Name Indication, SNI; [RFC6066]) TLS拡張を送信しなければなりません (MUST)。

QUIC接続は、[QUIC-TRANSPORT] で説明されているように確立されます。接続確立中に、TLSハンドシェイクでALPNトークン"h3"を選択することにより、HTTP/3サポートが示されます。同じハンドシェイクで他のアプリケーション層プロトコルのサポートが提供されてもよいです (MAY)。

コアQUICプロトコルに関連する接続レベルのオプションは初期暗号ハンドシェイクで設定されますが、HTTP/3固有の設定はSETTINGSフレームで伝達されます。QUIC接続が確立された後、各エンドポイントは、それぞれのHTTP制御ストリーム (HTTP Control Stream) の初期フレームとしてSETTINGSフレームを送信しなければなりません (MUST)。

3.3. Connection Reuse (接続の再利用)

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

サーバーエンドポイントへの接続が存在すると、この接続は、複数の異なるURI権威コンポーネントを持つリクエストに再利用されてもよいです (MAY)。新しいオリジンに既存の接続を使用するには、クライアントは、[HTTP] のセクション4.3.4で説明されているプロセスを使用して、新しいオリジンサーバーに対してサーバーが提示した証明書を検証しなければなりません (MUST)。これは、クライアントがサーバー証明書とその証明書を検証するために必要な追加情報を保持する必要があることを意味します。そうしないクライアントは、追加のオリジンに対して接続を再利用できません。

何らかの理由で証明書が新しいオリジンに対して許容できない場合、接続を再利用してはならず (MUST NOT)、新しいオリジンに対して新しい接続を確立すべきです (SHOULD)。証明書を検証できない理由が、すでに接続に関連付けられている他のオリジンに適用される可能性がある場合、クライアントはそれらのオリジンに対してサーバー証明書を再検証すべきです (SHOULD)。たとえば、証明書が期限切れまたは失効しているために証明書の検証が失敗した場合、これは、その証明書が権威を確立するために使用された他のすべてのオリジンを無効にするために使用される可能性があります。

クライアントは、特定のIPアドレスとUDPポートに対して複数のHTTP/3接続を開くべきではありません (SHOULD NOT)。IPアドレスとポートは、URI、選択された代替サービス ([ALTSVC])、設定されたプロキシ、またはこれらのいずれかの名前解決から派生する可能性があります。クライアントは、異なるトランスポートまたはTLS構成を使用して、同じIPアドレスとUDPポートへの複数のHTTP/3接続を開いてもよいです (MAY) が、同じ構成で複数の接続を作成することは避けるべきです (SHOULD)。

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

特定のオリジンに対してクライアントにHTTP/3接続を再利用してほしくないサーバーは、リクエストに対する応答として421（Misdirected Request、誤った方向のリクエスト）ステータスコードを送信することで、そのリクエストに対して権威がないことを示すことができます。[HTTP] のセクション7.4を参照してください。

---