TCP persist：失われたウィンドウ更新を取り戻す

要約

受信アプリケーションが読まなくなり、バッファが満ちる。受信TCPはゼロを広告し、送信側は新しいデータを止める。後で空きが生じ、正のウィンドウを載せたACKが送られる。しかしそれが失われれば、送信側の最新知識はゼロのままである。

RFC 1122 は、データを持たないACKがTCPによって確実に再送されるわけではないと強調した。受信側は再開を正しく通知し、送信側は最後の通知を正しく守り、それでも永久待機が成立する。失われたのはデータではなく送信許可だった。

RFC 813 は、受信側のoffered windowと、送信済み未確認分を差し引いたusable windowを分けた。これは受信容量を伝える流量制御である。

ゼロは「いま新規バイトを受けられない」とだけいう。紙切れのプリンターが標準の例になったのは、停止に正当なアプリケーション理由がありうるからだ。数分後か数日後に人が紙を補うまで、ホストも経路も正常でありうる。

受信ウィンドウと輻輳ウィンドウも別物である。終点のバッファ不足と経路の混雑を一つの信号にすると、観測していない原因まで数値に語らせてしまう。

RFC 793 に始まる仕組みは、RFC 9293 でも必須である。送信側はウィンドウがゼロでも、可能なら少なくとも一バイトの新規データ、または再送を定期的に送り、受信側は次に期待する番号と現在のウィンドウをACKで返す。

探査はゼロを無視する通常送信ではない。限られた質問である。応答がゼロなら停止を再確認し、正なら失われた再開許可を運び直す。

最初の探査は一つの再送タイムアウト後が推奨され、その後は指数バックオフする。単発の更新損失には早く反応し、長い正当な停止への負荷は下げる。すべての用途に同じ最大待機時間を規格は定めない。

RFC 1122は、受信側がゼロを無期限に保つことを許す。探査にACKが返る間、送信TCPは接続を開いたままにしなければならない。

ACKが示すのは、遠端TCPと戻り経路が現在の報告を返したことだけである。プロセスの健全性や再開時刻、ローカル資源を保持する価値までは証明しない。それでも無応答とは異なる。無応答は経路や相手の不確実性であり、確認済みゼロは相手が容量を留保しているという積極的な証拠である。

無期限という表現は、資源回収を禁じると誤読された。RFC 6429 は境界を明確にした。TCPがpersistだけを理由に勝手に失敗を宣告してはならないが、アプリケーションやOSが切断を要求すれば従う。

文書は反対側の危険も示す。多数のクライアントが大きな応答を要求し、読むのを止め、ゼロを広告しながら探査だけを確認すれば、サーバーは送信キューと接続状態を保持し続ける。やがて正規利用者のバッファまで奪われる。

一律の内部タイムアウトには、紙切れと攻撃を区別する材料がない。契約、テナント、キュー費用、期限を知る層が回収を決めるべきである。TCPは共有状態を守り、ローカル方針がローカル損失を引き受ける。

RFC 813は、小さなウィンドウ増分が小さなセグメントを繰り返し生むSilly Window Syndromeを記録した。ACK、CPU負荷、損失、再送が増える。そこで受信側は小さな空きをすぐ広告せず、実用的な量になるまで待てる。

送信側も右端の微小な移動ごとに送らない。RFC 9293は両側のSWS回避を要求し、小さなアプリケーション書込みをまとめるNagleとは補完関係にあるとする。

persistは意味のある再開通知を失わせない。SWS回避は、空いた一片ごとを低効率な許可にしない。許可の確実性と粒度は同じ設計の両面だった。

RFC 793、RFC 813、RFC 1122、RFC 6429を経てRFC 9293に統合された歴史は、三者の責任を残した。受信側は現在容量を決める。送信TCPは変更を疎に再確認する。アプリケーションとOSは、待機に使う時間とメモリを決める。

ゼロでpersistすることは、回復可能性を残すことである。費用を無限に他者へ請求する権利ではない。

閉じた出典集合は RFC 793、RFC 813、RFC 1122、RFC 6429、RFC 9293 である。現在の各OSの値、攻撃頻度、特定アプリケーションの健全性は証明しない。