TCP ウィンドウのスケーリングとスループット PCAP 分析: 受信ウィンドウ、ゼロ ウィンドウ、ウィンドウ フル、および低速転送のデバッグ

TCP スループットの低下は、必ずしもパケット損失であるとは限りません。これには、受信ウィンドウのプレッシャー、ウィンドウ スケーリングの不足、小さなソケット バッファー、アプリケーションの読み取り遅延、プロキシ バッファリング、VPN 制約、または帯域幅遅延積の不一致などが考えられます。速度テストが悪いが、再送信では速度低下の説明がつかない場合、ユーザーは「TCP ウィンドウ スケーリング pcap」、「TCP ゼロ ウィンドウ」、「TCP ウィンドウ フル」、「低速ダウンロード パケット キャプチャ」、「スループットを制限する受信ウィンドウ」、および「帯域幅遅延積 TCP 分析」を検索します。

スループットの問題では、正確なハンドシェイク オプション、アドバタイズされたウィンドウ、ACK タイミング、ペイロード バースト、一時停止、およびウィンドウの更新を保持する必要があるため、PCAP 手術が役立ちます。

TCP ウィンドウ スケーリングの機能

TCP ウィンドウ フィールドのサイズは制限されています。ウィンドウ スケーリングにより、SYN 交換中にスケール係数をネゴシエートすることで、より大きな受信ウィンドウが可能になります。ウィンドウ スケーリングが欠落しているか、無効になっているか、デバイスによって取り除かれているか、または誤って解釈されている場合、高遅延リンクではスループットが制限される可能性があります。

これは、遅延が大きい場合に最も重要です。

• WAN 転送。
• VPN リンク。
• 衛星ネットワークまたは携帯電話ネットワーク。
• クロスリージョンのクラウド トラフィック。
• 長距離バックアップ レプリケーション。
• リモートファイルコピー。
• 大規模な HTTP ダウンロード。

ローカル LAN では、受信ウィンドウが小さくても高速に見える場合があります。高遅延パスを通過すると、それがボトルネックになる可能性があります。

帯域幅遅延積

帯域幅遅延積は、パスを満た​​すためにどれだけのデータが送信されなければならないかを表します。高帯域幅で往復時間が長い接続には、より大きなウィンドウが必要です。

受信ウィンドウが小さすぎる場合、送信者はパイプをいっぱいにしておくのではなく、停止して ACK を待つ必要があります。

パケットキャプチャの証拠:

• 送信者は、アドバタイズされたウィンドウ制限まで送信します。
• 受信側の ACK が遅いか、小さなウィンドウをアドバタイズします。
• スループットはバーストと一時停止を形成します。
• 再送信は少ないですが、速度はまだ劣ります。
• ウィンドウ更新パケットは、アプリケーションがデータを読み取った後に表示されます。

これは受信側またはフロー制御のボトルネックであり、典型的な損失ではありません。

ゼロウィンドウ

TCP ゼロ ウィンドウとは、受信側が利用可能な受信バッファがないことを通知したことを意味します。送信者は、ウィンドウ更新が到着するまでアプリケーション データの送信を続けることはできません。

一般的な原因:

• 受信アプリケーションの読み取り速度が十分ではありません。
• サーバーが過負荷になっています。
• クライアントはディスク上で一時停止またはブロックされています。
• プロキシ バッファがいっぱいです。
• TLS スタックにはバックプレッシャがかかっています。
• データベース クライアントまたはファイル レシーバーが遅い。
• パケット キャプチャは受信機の近くで取得され、局所的な圧力を示します。

ゼロ ウィンドウは自動的にネットワーク障害になるわけではありません。多くの場合、これはアプリケーションまたはホストのリソースの負荷を指します。

ウィンドウがいっぱいです

「ウィンドウがいっぱい」は通常、送信者が受信者のアドバタイズされたウィンドウを埋めたことを意味します。それはゼロウィンドウの前に起こるかもしれません。送信者はさらに送信する準備ができていますが、フロー制御によって阻止されます。

探す：

• ウィンドウの端までの長いデータ。
• ストール周辺でのパケット損失はありません。
• ウィンドウを十分に進めない ACK。
• 送信者は待機中に一時停止します。
• ウィンドウの更新に続いて別のバーストが発生します。

このパターンは、「アップロードが遅い」および「ダウンロードが遅い」サポート ケースの場合に特に重要です。

スケールオプションがありません

ウィンドウのスケーリングはハンドシェイク中にネゴシエートする必要があります。一方の側で SYN または SYN-ACK にウィンドウ スケール オプションが含まれていない場合、接続では後でスケーリングを使用できません。

証拠：

• SYN オプション。
• SYN-ACK オプション。
• ウィンドウスケール値。
• 初期受信ウィンドウ。
• 効果的なスケールウィンドウ。
• オプションを削除するミドルボックスの動作。

ハンドシェイク後にキャプチャが開始される場合、スケール係数が不明になる可能性があります。そのため、サポート トレースには完全な TCP ハンドシェイクが含まれる必要があります。

撮影場所が重要

ウィンドウ分析は、キャプチャが行われた場所によって異なります。送信側近くのキャプチャは、受信側近くのキャプチャとは異なるタイミングを示す場合があります。 NAT、VPN、プロキシ、ロード バランサーでも接続を分割できます。

質問:

• pcap はクライアント、サーバー、ファイアウォール、またはプロキシでキャプチャされましたか?
• これは 1 つのエンドツーエンド TCP 接続ですか、それとも 2 つのプロキシ側接続ですか?
• シーケンス番号は翻訳されますか?
• ACK は受信側またはネットワークによって遅延されますか?
• プロキシは最終エンドポイントとは異なるウィンドウをアドバタイズしますか?

PCAP 手術は、ハンドシェイクのオプションを失うことなく会話をトリミングして比較するのに役立ちます。

誤ったパケット損失の結論を回避する

スループット ダッシュボードは多くの場合、パケット損失の原因となります。しかし、再送信がまれで、送信者が受信ウィンドウで繰り返し一時停止する場合、本当のボトルネックはフロー制御です。

喪失が主な原因ではないことを示す兆候:

• 再送信はほとんどありません。
• 重複した ACK ストームはありません。
• 定期的なウィンドウ更新サイクル。
• 送信者は、アドバタイズされたウィンドウで正確に一時停止します。
• アプリケーション層の応答が遅く、データを消費します。

これらのユーザーは別の診断パスを必要とするため、この記事では「低速 TCP、パケット損失なし」などの検索を対象にする必要があります。

デバッグチェックリスト

このワークフローを使用します。

1. SYN パケットと SYN-ACK パケットを保持します。
2. ウィンドウスケールオプションを記録します。
3. 有効な受信ウィンドウを計算します。
4. ゼロウィンドウおよびウィンドウ更新パケットを識別します。
5. ウィンドウがいっぱいの期間を特定します。
6. RTTを測定します。
7. 飛行中のバイトを帯域幅遅延積と比較します。
8. 再送信率は別途ご確認ください。
9. キャプチャ場所をメモします。
10. ゆっくりとした間隔を保ち、握手を交わします。

最終診断

TCP ウィンドウ スケーリングと受信ウィンドウの問題により、明らかなパケット損失が発生せずに転送が遅くなります。その証拠は、ハンドシェイク オプション、アドバタイズされた受信ウィンドウ、ゼロウィンドウ イベント、ウィンドウ更新、RTT、および送信者の一時停止動作にあります。

PCAP 手術は、ボトルネックがネットワーク損失、受信バッファ圧力、ウィンドウ スケーリングの不足、プロキシの動作、またはアプリケーションの読み取り速度が十分でないのかどうかを証明するパケットを保持するのに役立ちます。