要約

  • Silly Window Syndromeは、小さな受信ウィンドウの前進を小さな送信が直ちに消費する安定した循環だった。
  • 解決は受信側と送信側に分けられ、前者はわずかな容量の通知を待ち、後者は有用な送信機会まで待てるようになった。
  • Nagleアルゴリズムは、アプリケーションの小刻みな書き込みという別の原因を扱うため、ウィンドウ側の抑制を補完する。

保護機構がパケット工場になった

TCPの受信ウィンドウは、送信側がさらに使えるシーケンス空間の上限を示す。正の値が現れるたび、即座に使い切れと命じるものではない。

満杯の受信バッファからアプリケーションが1バイトを読むとする。受信側は新たな1バイトを正しく通知でき、送信側も待機データの1バイトで合法的に埋められる。バッファは再び満杯になり、次の1バイトが読まれると同じ交換が始まる。両端はフロー制御を守りながら、わずかなペイロードのためにヘッダー、確認応答、割り込み、スケジューリングの費用を払い続ける。

RFC 813は、この安定パターンをSilly Window Syndromeと名付けた。重要なのは名称ではない。局所的に正しい判断が、全体として使いものにならない結果を生み得るという診断だった。バイトの帳簿は正確でも、交換単位は壊れていた。

受信側は小さな真実をすべて公表しなくなった

受信側は自分のバッファを直接把握している。アプリケーションが少量だけ解放したとき、通知済みウィンドウの右端を動かさず、実在する未通知容量を蓄積できる。十分な仕事を運べる空間になってから、まとまった開口として通知する。

この待機は状態を偽らず、既に与えた許可も取り消さない。正確な測定と、実行に適した招待を分けるだけである。RFC 1122と現行TCP仕様は、受信側のSWS回避と、バッファ容量および有効最大セグメントサイズに基づく実用的なしきい値を記述している。

送信側は上限を命令と見なさなくなった

すべての受信側が小さな更新を控えるとは限らない。そこで送信側にも独立した判断がある。ウィンドウは超過を禁じる上限だが、正の余地を即時に使う義務ではない。

送信側のSWS回避は、完全なセグメントを送れるとき、適切なPUSHデータを完了できるとき、観測した最大ウィンドウの意味ある割合を使えるとき、または退避用タイマーが進行を要求するときまで待つ。相手の総バッファは見えないので観測から推定し、タイマーで誤推定が永久停止になるのを防ぐ。

RFC 9293は送信側と受信側の回避を別々の節で扱う。この分離が設計の核心である。受信側は容量をいつ提案にするかを決め、送信側は提案が1回の送信に値するかを決める。どちらも相手の内部メモリを支配しない。

Nagleは別の細流を扱った

ウィンドウが広くても、アプリケーションが1文字ずつTCPへ渡せば小さなセグメントは生じる。RFC 896は、当時1バイトのペイロードが約40バイトのTCP/IPヘッダーとともに運ばれる負担を示した。

Nagleの適応的な規則は、小さな未確認セグメントがある間、新しい小さな書き込みを蓄積する。確認応答または十分な量のデータが次の送信を解放する。固定待ち時間ではなく、接続自身のフィードバックを利用する方式である。

入力が異なる。Nagleはアプリケーションから小刻みに来るデータに応答し、送信側SWS回避は相手から小刻みに来るウィンドウ機会に応答する。低遅延を必要とするアプリケーションがNagleを無効にしても、狭いウィンドウの問題は消えない。

抑制には出口が必要だった

待機は効率を上げるが、無期限の待機は別の障害である。退避用タイマーは進行への道を残す。受信側はバッファの公開、送信側は送信機会の使用、アプリケーションは遅延の選択を担う。狭い権限と出口条件が、中央スケジューラーなしの協調を可能にした。

情報源と限界

設計史はRFC 793、RFC 813、RFC 896、RFC 1122、RFC 9293に基づく。これらは現在の各OSでの発生頻度を測定していない。SWSは輻輳ウィンドウ制御やパケット損失とは別の問題である。