要約

  • 各端点は、自分が後で通知する受信窓に適用する指数をSYNで示す。1本の接続には方向別の2つの尺度がある。
  • シフト値7なら、確立後の65,535は8,388,480バイトを表せる。一方、SYN内のWindowは常に非スケールである。
  • 拡張されるのは受信クレジットの表現範囲であり、メモリーや輻輳ウィンドウ、SACK、タイムスタンプ、PAWSの機能ではない。

Windowフィールドは「経路がどれだけ速いか」を伝えない。受信側が、確認済み境界の先にあと何バイト受け取れるかを示す。元の16ビットでは上限が65,535だった。帯域遅延積がそれを超えると、十分なメモリーがあっても、その余力を書き表せない。

RFC 1072は1988年、この問題を長距離・高帯域経路の障害として扱った。提案はヘッダーを長くするものではない。SYNに3バイトのオプションを置き、2の累乗を表す指数を渡す。以後の16ビット値は、接続状態に保存された指数で左シフトして読む。

SYNに置く理由は信頼性にある。通常のACKに載せた変更は、そのACKとともに失われ得る。片側だけが新しい単位を使えば、同じWindow値が両端で別の意味になる。接続開始のSYNは再送されるため、利用前に読み方を揃えられる。

方向ごとに別の物差し

Aが送る指数は、A自身の受信窓を表すためのものだ。Bはその値を保存し、後にAから届くWindowフィールドを読む。Bの指数は逆方向でAが使う。端点ごとにバッファ方針が違う以上、2つの値も同じとは限らない。

オプションは一方的な命令ではなく提案である。双方のSYNにWindow Scaleがある場合だけ有効になる。指数0も倍率1の有効な提案だ。どちらかが送らなければ、保存されるシフト値は0のままで従来の意味を使う。

SYNとSYN-ACKのWindowは例外で、スケールされない。確立後なら65,535 << 7は8,388,480バイトだが、SYNの65,535はそのまま65,535である。同じビット列に別の意味を与えるのは、直前に合意された接続文脈である。

RFC 1323は1992年に実験的なRFC 1072を置き換えた。RFC 7323は2014年にRFC 1323を更新し、概念上の窓を30ビット、指数の上限を14と定めた。表現できる最大値は1 GiB弱である。14を超える値は14として扱い、32ビットのシーケンス空間で新旧を比較する安全性を守る。

範囲が広がるほど粒度は粗くなる。シフト7ならフィールドの1刻みが128バイトになる。内部のバッファ管理は正確でも、報告する右端は符号化時に量子化される。

受信余力と送信権限は違う

大きな受信窓は、大きな輻輳ウィンドウではない。前者は受信側のメモリーと消費速度、後者は送信側が経路から得た情報に支配される。送信側は小さい方に従う。Window Scaleは経路容量を測定せず、損失への免許も与えない。

また、欠落の先に届いた区間を示すSACKでもない。古いシーケンス周期のセグメントを時刻値で退けるPAWSでもない。RTT測定でもない。高性能TCPという同じ歴史に並んでも、各機構が作る証拠は別物だ。

RFC 9293はWindow Scaleを高性能のために実装が推奨される一般的なオプションとするが、基本相互運用の必須条件とはしない。したがって、接続は成功しながら旧上限のために経路を使い切れないことがある。

観測者に欠けるSYN

ハンドシェイク後から始めたパケットキャプチャでは、Window=32,768の真の大きさは分からない。同じ方向のSYNにあった指数が必要だ。有状態ファイアウォールが窓の内外を判定する場合も、同じ状態を保持しなければならない。

RFC 7323は、中間装置がSYNやSYN-ACKのオプションを削除・変更すると端点のパラメーターを壊すと警告する。尺度を決定できない装置は、生の16ビット値を根拠に窓検査をしてはならない。

Window Scaleの歴史的な工夫は、古いフィールドを捨てず、信頼できる開始手続きに意味の割り当てを任せた点にある。ヘッダーは同じ長さのまま、接続は2方向の読み方を覚えた。

参照資料