要約

  • TCP の User Timeout は接続ごとのローカルな上限である。送信済みデータが一定時間確認されなければ、その端点は接続を中止できる。再送の時期を決めるタイマーとは別物だ。
  • RFC 5482は現在値を伝える4バイトの User Timeout Option を定義した。値は助言であり拘束力のある交渉ではない。受信側は無視でき、ローカルな上下限を適用でき、アプリケーションが明示した値を上書きさせなくてもよい。
  • 長い値は一時的な切断を越えて接続を残せる一方、キューと状態を長く保持する。短い値は早く資源を解放するが、遅延や一時的な損失を回復不能と誤認する危険がある。

一つの未確認バイトを測る二つの時計

接続は確立済みで、送った一つのバイトに ACK が来ていない。再送タイマーが満了すれば、TCP はセグメントを送り直し、次の機会を測り始める。User Timeout が問うのは別のことだ。アプリケーションにとって、未確認の仕事を抱えたまま接続全体を残す価値はいつまであるのか。

RFC 793では、User Timeout が満了すると再送をもう一度行うのではない。キューを空にし、中止を利用者に通知し、TCB を削除して CLOSED へ移る。現行の RFC 9293も、RETRANSMISSION TIMEOUTは再送、USER TIMEOUTは状態の終了と分けている。

この判断権は UTO より古い。1981年の抽象 API では、アプリケーションが OPEN 時に時間を指定し、SEND 時に変更できた。RFC 1122は過剰な再送を R1 と R2 に分け、R1 で問題を知らせ、より大きい R2 で接続を閉じるよう整理した。アプリケーションは接続ごとに R2 を設定できなければならない。データについて少なくとも100秒という推奨は、すべての用途を縛る一つの正解ではない。

足りなかったのは相手への伝達だった。移動端末がハンドオーバーを越えるため自分の待ち時間を延ばしても、相手は先に状態を捨てるかもしれない。負荷の高いサーバーが沈黙した接続を短く保ちたい場合も、その資源事情を TCP で知らせる方法がなかった。

取引を成立させない4バイト

2009年の RFC 5482は、UTO を TCP オプション Kind 28、Length 4とした。Gの1ビットが秒と分を選び、残り15ビットが提案値を運ぶ。ゼロは予約値である。これは時間であって、再送回数でも RTT の見積もりでもない。

接続を開く前に有効化すれば、UTO は SYN と SYN-ACK に入れられる。最初の非 SYN パケットにも付けることが推奨される。未対応の TCP は黙って無視する。UTO を含むセグメントが失われれば、相手はローカル値を更新する機会を失うだけだ。専用の信頼性ハンドシェイクはなく、届いたと仮定してはならない。

権限の分担は明示されている。ADV_UTOは自分が広告する値、REMOTE_UTOは最後に受けた助言、USER_TIMEOUTはローカルで採用する値である。ENABLEDが拡張を有効にし、CHANGEABLEが遠隔の助言による変更を許すかどうかを決める。

アプリケーションがUSER_TIMEOUTを明示した場合、CHANGEABLEは false にならなければならない。相手のパケットがアプリケーションの指示を密かに覆すことはできない。変更を許す場合、RFC は双方の広告値の大きい方を選び、ローカルな下限と上限で挟む方法を推奨する。それでも両端が同じ値になる保証はなく、どちらも独自に閉じられる。

接続の寿命と状態の費用

長い値は、モビリティの切り替え、経路の揺れ、一時的な到達不能を乗り越える助けになる。その間、ホストはキューと接続状態を保持し続ける。多数のハンドシェイクを完了して長い値を提案する相手は、使い捨て接続の維持費をサーバーに負わせ得る。

そのため RFC 5482は上下限を必須とする。下限は現在の RTO より大きくなければならない。さもなければ、損失や高遅延だけで、再送が回復する前に接続を中止しかねない。上限は認証、相手ごとの接続数、資源使用量、攻撃状況に応じて変えられる。長い助言を採用しても、ローカル側が状態を解放する権利は失われない。

Keep-alive は別の仕組みである。両方を使うなら、keep-alive のタイマーは採用した User Timeout より長くなければならない。別の中止方針が先に接続を終わらせるのを避けるためだ。途中のステートフルファイアウォールは独自のアイドル時間で状態を消せる。UTO は経路を検査せず、相手の生存も、広告時間まで接続が残ることも証明しない。

TCP オプション領域が40バイトしかないことも限界になる。他の拡張で埋まれば UTO を載せられない。見えないこと自体は拒否の証拠ではない。

RFC 5482が変えたもの

RFC 5482は、アプリケーションが待ち時間を選ぶ権能を新設したのではない。ローカルな方針を相手に聞こえるようにしながら、最終判断を各端点に残した。Window Scale がハンドシェイク後のフィールド解釈を定め、PAWS が古いシーケンス空間の意味を退け、SACK がギャップの先に届いた範囲を報告するのに対し、User Timeout は ACK が来ないときローカル状態をいつまで残すかを扱う。

この RFC 群から、現在の普及率、各 OS の API、個別アプリケーションの初期値までは分からない。分かるのは、TCP が「待てる時間」を伝える方法を得ても、それを互いの義務とは呼ばなかったという設計史である。

出典