要約

  • 有効な CONNECTION_CLOSE は QUIC 接続を直ちに終了し、開いているストリームも暗黙に閉じる。
  • 送信側は closing、受信側は draining に入り、それぞれ応答の規則が異なる。
  • クローズのコードと理由文は通信の証拠であり、業務完了や永続化、原因の証明ではない。

保護された CONNECTION_CLOSE は、対向端点からの認証済みの通信シグナルである。受信側が有効なフレームを確認し、接続終了の状態遷移に入ったことは示せる。しかし、それを業務の受領通知に読み替えることはできない。NO_ERROR を見た運用台帳が、接続上のすべての処理を成功として確定する設計は、この境界を失っている。

QUIC は通信を即時に終了する。開いているストリームは直ちに閉じられ、暗黙のリセットとして扱える。クローズを送った端点は closing に、受け取った端点は draining に入る。これは接続の状態については強い証拠だが、アプリケーションが正常終了を合意したこと、全メッセージを受信・処理したこと、永続状態をコミットしたこと、未完了作業を補償したこと、業務が完了したことを示さない。

フレームの種類は記録に残す必要がある。0x1c は NO_ERROR を含む QUIC 層のエラーを運び、「原因となったフレーム種別」フィールドを含む。このフィールドは未知ならゼロになる。0x1d はアプリケーションプロトコルのエラーコードを運ぶが、このフィールドを持たない。トランスポートのコードはアプリケーションの受領証ではない。NO_ERROR が示すのは、通信層の無エラーコードが使われたことだけである。理由文は対向側が提供する任意の診断テキストで、空でもよく、言語タグもない。それだけで根本原因の説明にはならない。

closing と draining は遅延または順序入れ替わりのパケットを安全に破棄するために存在する。通常は現在の PTO の少なくとも三倍維持する。遅延パケットが応答を引き起こさない別の制御を文書化していれば、より早く状態を捨てられる場合もある。どちらの状態が終わっても接続状態は破棄され、後続パケットには Stateless Reset で応答できる。状態破棄時刻は業務完了時刻とは別に記録すべきだ。

closing 側は接続パケットの識別と CONNECTION_CLOSE 応答に必要な情報だけを保持し、受信フレームを処理する必要はない。検証できない受信パケットには増幅制限を保ち、応答もレート制限する。draining 側はパケットを送ってはならず、draining に入る前に送れるクローズは最大一つで、その後は沈黙する。この沈黙は業務成功を意味しない。

保護レベルも重要だ。ハンドシェイク確認後の CONNECTION_CLOSE は 1-RTT パケットで送る必要がある。確認前は、相手が少なくとも一つを処理できるよう、複数の利用可能な保護レベルで送ることがある。クライアントは 0-RTT だけで送ったクローズをサーバーが受け入れたと推定できない。見えるクローズがないことも、直ちに無視された証拠にはならない。

アプリケーション側では、正常終了の合意、操作ごとの受領、永続コミット、補償、完了を独立して記録する必要がある。原因分析もクローズフレームとは別の証拠で行う。理由文は調査の手掛かりにはなるが、これらの記録を代替しない。