プロキシ経由の TCP ゼロウィンドウ：受信側を特定する

パケットトレースは TCP ZeroWindow と表示します。カーネル設定を変える前に、ゼロを通知している端点を特定してください。

その端点は、その TCP 接続上での自身の受信能力を述べているだけです。プロキシ全体にどれだけの帯域があるかを通知しているわけではありません。ゼロウィンドウプローブは、通知された能力が変化したかどうかを送信側が知るためのものです。プローブだけでは、パケット損失やプロキシの故障を証明できません。

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

これらは別々の TCP の会話です。ブラウザが大きな応答の読み取りを止め、A 側でゼロを通知したとします。プロキシは自身のバッファが埋まるにつれ、やがて B 側の排出を止めることがあります。後から B 側で見えるゼロウィンドウは、元の問題ではなく低速なクライアントの結果かもしれません。

アップロード中には逆の状況も起こりえます。宛先アプリケーションがデータの消費を止めると、B 側のウィンドウが閉じることがあります。その圧力は プロキシのバッファを通じてクライアント側へ戻っていくことがあります。

観測を順序立てる

1. 接続の端点と、影響を受けたデータ転送の向きを記録します。
2. どの端点が最初に縮小またはゼロの受信ウィンドウを通知したかを特定します。
3. そのアプリケーションが読み取り中だったのか、別の処理で止まっていたのか、資源に制約されていたのかを確認します。
4. 元の原因を割り当てる前に、プロキシのもう一方の接続でのタイミングと比べます。

Wireshark のウィンドウ分析ラベルはキャプチャの有用な解釈であり、すべての受信バッファを増やせという指示ではありません。ウィンドウスケーリングも、接続のネゴシエーションを踏まえて解釈する必要があります。

プロキシ一覧から別の端点を試して転送が回復するのを見るのは、経路が変わったという有用な証拠です。ただしそれ自体は、ある OS の TCP 実装が欠陥だったことを証明しません。説明は受信プロセスと、待ちが始まった接続に結び付けたままにしてください。