TCP再送・ウィンドウサイズ異常から読み解く通信遅延の原因

「回線は空いているはずなのに通信が遅い」
「特定アプリだけレスポンスが悪い」

このような事象の多くは、TCP再送や ウィンドウサイズ異常によって発生しています。

本記事では、TCPの挙動をパケットレベルで読み解き、 通信遅延の原因を論理的に特定するための実務的な確認手順を解説します。

TCP通信遅延を理解するための前提知識

TCPは「速さ」よりも「確実性」を優先するプロトコルです。 そのため、以下の状況が発生すると意図的に通信速度を落とします。

• パケットロスが発生
• 受信側の処理が追いつかない
• ネットワーク遅延が増大

これらは再送・ウィンドウ制御として可視化されます。

TCP再送（Retransmission）とは

概要

TCP再送とは、送信したデータに対してACKが返らなかった場合に、 同じデータを再送する仕組みです。

再送が発生する主な理由

• パケットロス
• 輻輳（混雑）
• FW・回線品質問題

Wiresharkでの表示例

TCP Retransmission
Dup ACK

TCP再送が引き起こす影響

• スループット低下
• レスポンス遅延
• アプリケーションのタイムアウト

再送が増えるほど、TCPは自動的に送信速度を下げます。

ウィンドウサイズ（Window Size）の基本

役割

ウィンドウサイズは「一度に送ってよいデータ量」を表します。

• 大きい → 高速通信可能
• 小さい → 通信速度低下

重要な関連要素

• 受信バッファ
• RTT（往復遅延）
• Window Scaling

ケース① TCP再送が多発している場合

症状

• 通信速度が安定しない
• 短時間でスループットが上下する

パケット例

Seq=1000 Len=1460
Seq=1000 Len=1460 (Retransmission)

考えられる原因

• 回線品質劣化
• 帯域不足
• FW処理遅延

対処例

• 回線エラーカウンタ確認
• FWのCPU使用率確認

ケース② ウィンドウサイズが極端に小さい

症状

• パケットは流れるが非常に遅い

Wireshark確認ポイント

Window size: 1024

原因

• 受信側サーバの高負荷
• OSチューニング不足

結果

送信側は「これ以上送らない」判断をします。

ケース③ Zero Window が発生している

症状

• 通信が断続的に停止

パケット例

Window size: 0
Zero Window

主な原因

• サーバリソース枯渇
• アプリケーション停止

対処

ネットワークではなくサーバ側の問題である可能性が高いです。

遅延切り分けの実践手順

1. RTTの確認
2. 再送率の確認
3. Window Sizeの変動確認
4. Zero Windowの有無確認
5. FW・サーバ負荷確認

ネットワーク側でできる改善策

• 帯域増強
• QoSによる優先制御
• FW性能見直し

再送は結果であり原因ではありません。 根本原因を探すことが重要です。

まとめ

• TCP再送は通信品質劣化のサイン
• ウィンドウサイズは受信側の状態を示す
• ネットワークとサーバ両面で確認が必要

TCP挙動を理解できると、「遅い理由」を定量的に説明できるようになります。