要約

  • 再送タイムアウトは次に送る時点を決め、USER TIMEOUT は接続を打ち切る時点を決める。
  • RFC 5482 の値は相手への提案であり、ローカルの上限・下限と CHANGEABLE が最終判断を守る。

二つの時計が別の問いに答える

送信中のデータに有効な確認応答が戻らないと、再送タイマーが満了してキュー先頭のセグメントをもう一度送ることがある。その後、再送タイマーは再初期化される。しかし、それだけでアプリケーションが接続をどれだけ維持するかは決まらない。

USER TIMEOUT は、送信データを成功裏に届けられないまま、どこまで待つかを表す。RFC 793 はこの値を TCP に与えられるローカルな期限として記述した。RFC 9293 は二つのイベントを明確に分けている。再送タイムアウトは先頭セグメントを再送してタイマーを再開する。一方、USER TIMEOUT の満了はキューをフラッシュし、接続が中止されたことを通知し、TCB を削除して CLOSED に入る。

したがって、もう一度再送できる状態と、接続を維持する予算が尽きた状態は同時に存在しうる。RTO は往復時間や損失の観測に応じて試行間隔を調整する。USER TIMEOUT は、状態、メモリ、そしてアプリケーションの不確実性をいつまで許容するかを示す。

これはアプリケーションのリクエストタイムアウトとも異なる。アプリケーションは一つの処理だけを諦めて接続を残せるし、未配信データがあるとき接続そのものの終了を求めることもできる。

秒または分で伝える提案

もともとのユーザータイムアウトはローカルな値だった。相手が障害中の接続をどれほど保持したいかを、もう一方の端点は知ることができなかった。RFC 5482 は TCP User Timeout オプションによって、その希望を伝えられるようにした。

このオプションは Kind 28、Length 4 である。粒度ビットが秒または分を選び、残りの 15 ビットが提案値を運ぶ。秒単位なら 1 秒から 9 時間超、分単位なら 1 分から 22 日超を表現できる。

ただし、これは相手への助言であって、リモートからの中止命令ではない。RFC 5482 の状態には USER_TIMEOUT、ADV_UTO、ENABLED、CHANGEABLE がある。ENABLED は既定で無効で、オプションの送受信を制御する。CHANGEABLE は、受信した提案でローカル値を変更できるかを決める。

アプリケーションが値を固定し CHANGEABLE が偽なら、相手の値はそれを上書きできない。TCP は提案をアプリケーションへ通知できる。情報は届いても、権限までは移らない。

上限と下限が資源を守る

実装はローカルの上下限を設けなければならない。短すぎる値は、高遅延や一時的な障害のある経路で接続を早く切りすぎる。長すぎる値はバッファや状態を保持し続け、資源枯渇の危険を高める。認証や相手ごとの資源制限は対策になりうる。

UTO が見えないことも、USER TIMEOUT がない証拠にはならない。未対応実装は通常のオプション規則に従って無視でき、TCP の限られたオプション領域が別のオプションで埋まっている場合もある。ファイアウォールは端点より先に状態を破棄できる。パケットキャプチャが示すのは観測地点で提案が現れたことだけで、採用や中間機器の保持時間までは示さない。

keepalive と併用するなら、そのタイマーは採用された USER_TIMEOUT より長くなければならない。keepalive はアイドル接続の活性を調べ、USER TIMEOUT は未配信データの持続を制限する。

RFC 5482 が行ったのは、ローカル方針を境界付きの提案として公開することだった。最終的な中止の権限を相手に渡したわけではない。

出典