5. 接続のクローズ (Connection Closure)
確立されると、HTTP/3接続は、接続が閉じられるまで、時間の経過とともに多くのリクエストとレスポンスに使用できます。接続のクローズは、いくつかの異なる方法で発生する可能性があります。
5.1. アイドル接続 (Idle Connections)
各QUICエンドポイントは、ハンドシェイク中にアイドルタイムアウト (Idle Timeout) を宣言します。QUIC接続がこの期間より長くアイドル状態(パケットが受信されない)のままである場合、ピアは接続が閉じられたと仮定します。既存の接続がQUICハンドシェイク中にネゴシエートされたアイドルタイムアウトより長くアイドル状態である場合、HTTP/3実装は新しいリクエストのために新しいHTTP/3接続を開く必要があり、アイドルタイムアウトに近づいている場合はそうすべきです (SHOULD)。[QUIC-TRANSPORT]のセクション10.1を参照してください。
HTTPクライアントは、[QUIC-TRANSPORT]のセクション10.1.2で説明されているように、リクエストまたはサーバープッシュの未処理のレスポンスがある間、トランスポートが接続を開いたままにすることを要求することが期待されます。クライアントがサーバーからのレスポンスを期待していない場合、必要ないかもしれない接続を維持するために労力を費やすよりも、アイドル接続をタイムアウトさせることが望ましいです。ゲートウェイは、サーバーへの接続確立の遅延コストを負担するのではなく、必要性を見越して接続を維持してもかまいません (MAY)。サーバーは積極的に接続を開いたままにすべきではありません (SHOULD NOT)。
5.2. 接続のシャットダウン (Connection Shutdown)
接続がアイドル状態でない場合でも、いずれかのエンドポイントは接続の使用を停止し、グレースフルな接続クローズ (Graceful Connection Close) を開始することを決定できます。エンドポイントは、GOAWAYフレームを送信することにより、HTTP/3接続のグレースフルシャットダウンを開始します。GOAWAYフレームには、この接続で処理されたまたは処理される可能性のあるリクエストまたはプッシュの範囲を受信者に示す識別子が含まれています。サーバーはクライアントが開始した双方向ストリームIDを送信します。クライアントはプッシュIDを送信します。指定された識別子以上の識別子を持つリクエストまたはプッシュは、GOAWAYの送信者によって拒否されます (Rejected)(セクション4.1.1)。リクエストまたはプッシュが処理されなかった場合、この識別子はゼロであってもかまいません (MAY)。
GOAWAYフレームの情報により、クライアントとサーバーは、HTTP/3接続のシャットダウン前にどのリクエストまたはプッシュが受け入れられたかについて合意できます。GOAWAYフレームを送信すると、エンドポイントは、影響を受けるストリームのトランスポート状態をクリーンアップするために、指示された識別子以上の識別子を持つリクエストまたはプッシュを明示的にキャンセルすべきです (SHOULD)(セクション4.1.1および7.2.3を参照)。より多くのリクエストまたはプッシュが到着するにつれて、エンドポイントはそうし続けるべきです (SHOULD)。
エンドポイントは、ピアからGOAWAYフレームを受信した後、接続で新しいリクエストを開始したり新しいプッシュを約束したりしてはなりません (MUST NOT)。クライアントは、追加のリクエストを送信するために新しい接続を確立してもかまいません (MAY)。
一部のリクエストまたはプッシュはすでに転送中である可能性があります:
-
GOAWAYフレームを受信すると、クライアントがGOAWAYフレームに含まれる識別子以上のストリームIDを持つリクエストをすでに送信している場合、それらのリクエストは処理されません。クライアントは、処理されなかったリクエストを別のHTTP接続で安全に再試行できます。リクエストを再試行できないクライアントは、サーバーが接続を閉じたときに転送中のすべてのリクエストを失います。
サーバーからのGOAWAYフレームのストリームIDより小さいストリームID上のリクエストは処理された可能性があります。レスポンスが受信されるか、ストリームが個別にリセットされるか、問題のリクエストのストリームIDより低いストリームIDを持つ別のGOAWAYが受信されるか、接続が終了するまで、それらのステータスを知ることはできません。
これらのリクエストが処理されなかった場合、サーバーは指定されたID以下のストリーム上の個々のリクエストを拒否してもかまいません (MAY)。
-
サーバーが、GOAWAYフレームに含まれる識別子以上のプッシュIDを持つプッシュを約束した後にGOAWAYフレームを受信した場合、それらのプッシュは受け入れられません。
接続のクローズが事前にわかっている場合、サーバーはGOAWAYフレームを送信すべきです (SHOULD)。事前通知が少ない場合でも、リモートピアはリクエストが部分的に処理されたかどうかを知ることができます。たとえば、HTTPクライアントがPOSTを送信すると同時にサーバーがQUIC接続を閉じた場合、サーバーが動作した可能性のあるストリームを示すGOAWAYフレームを送信しない場合、クライアントはサーバーがそのPOSTリクエストの処理を開始したかどうかを知ることができません。
エンドポイントは、異なる識別子を示す複数のGOAWAYフレームを送信してもかまいません (MAY) が、各フレームの識別子は以前のフレームの識別子より大きくてはなりません (MUST NOT)。クライアントはすでに別のHTTP接続で処理されなかったリクエストを再試行している可能性があるためです。以前に受信したものより大きい識別子を含むGOAWAYを受信することは、H3_ID_ERRORタイプの接続エラー (Connection Error) として扱わなければなりません (MUST)。
グレースフルに接続をシャットダウンしようとしているエンドポイントは、最大可能値(サーバーの場合は2^62-4、クライアントの場合は2^62-1)に設定された値を持つGOAWAYフレームを送信できます。これにより、ピアが新しいリクエストまたはプッシュの作成を停止することが保証されます。転送中のリクエストまたはプッシュが到着する時間を許可した後、エンドポイントは、接続の終了前に受け入れる可能性のあるリクエストまたはプッシュを示す別のGOAWAYフレームを送信できます。これにより、リクエストを失うことなく接続をクリーンにシャットダウンできることが保証されます。
クライアントは、送信するGOAWAYのプッシュIDフィールドに選択する値においてより柔軟性があります。2^62-1の値は、サーバーがすでに約束されたプッシュの履行を続けることができることを示します。より小さい値は、クライアントがこの値以上のプッシュIDを持つプッシュを拒否することを示します。サーバーと同様に、クライアントは、指定されたプッシュIDが以前に送信された値より大きくない限り、後続のGOAWAYフレームを送信してもかまいません (MAY)。
GOAWAYが、受信時に特定のリクエストまたはプッシュが処理または受け入れられないことを示している場合でも、基礎となるトランスポートリソースは依然として存在します。これらのリクエストを開始したエンドポイントは、トランスポート状態をクリーンアップするためにそれらをキャンセルできます。
すべての受け入れられたリクエストとプッシュが処理されると、エンドポイントは接続がアイドル状態になることを許可するか、接続の即時クローズを開始してもかまいません (MAY)。グレースフルシャットダウンを完了するエンドポイントは、接続を閉じるときにH3_NO_ERRORエラーコードを使用すべきです (SHOULD)。
クライアントがリクエストで使用可能なすべての双方向ストリームIDを消費した場合、サーバーはGOAWAYフレームを送信する必要はありません。クライアントはさらにリクエストを行うことができないためです。
5.3. 即時アプリケーションクローズ (Immediate Application Closure)
HTTP/3実装は、いつでもQUIC接続を即座に閉じることができます。これにより、アプリケーション層が接続を終了したことを示すQUIC CONNECTION_CLOSEフレームがピアに送信されます。このフレームのアプリケーションエラーコードは、接続が閉じられている理由をピアに示します。HTTP/3で接続を閉じるときに使用できるエラーコードについては、セクション8を参照してください。
接続を閉じる前に、クライアントが一部のリクエストを再試行できるようにするために、GOAWAYフレームを送信してもかまいません (MAY)。QUIC CONNECTION_CLOSEフレームと同じパケットにGOAWAYフレームを含めることで、クライアントがフレームを受信する可能性が向上します。
明示的に閉じられていない開いているストリームがある場合、接続が閉じられるときに暗黙的に閉じられます。[QUIC-TRANSPORT]のセクション10.2を参照してください。
5.4. トランスポートクローズ (Transport Closure)
さまざまな理由により、QUICトランスポートは、接続が終了したことをアプリケーション層に示す可能性があります。これは、ピアによる明示的なクローズ、トランスポートレベルのエラー、または接続を中断するネットワークトポロジの変更が原因である可能性があります。
GOAWAYフレームなしで接続が終了した場合、クライアントは、送信されたリクエスト(完全または部分的)が処理された可能性があると想定しなければなりません。