「回線は太いのに転送が遅い」。原因の多くはTCPの挙動にあります。再送とウィンドウ制御の基本を押さえると、遅延の正体が見えてきます。
TCPは「届いたか」を確認しながら送る
TCPは信頼性のため、送ったデータに対する確認応答（ACK）を受け取りながら進みます。ACKが返らなければ、一定時間後に再送します。この「確実さ」が、裏返すと遅延の原因にもなります。
ウィンドウ制御：まとめて送る工夫
1つ送ってACKを待って、また1つ…では遅すぎます。そこでTCPは「ウィンドウサイズ」の分だけ、ACKを待たずにまとめて送れます。ウィンドウが大きいほど、一度に送れる量が増え、スループットが上がります。
帯域遅延積という壁
ここが肝心です。遅延（RTT）が大きい回線では、ウィンドウが小さいと帯域を使い切れません。
最大スループット ≒ ウィンドウサイズ ÷ RTT
例えば東京〜海外のような高遅延回線では、ウィンドウが足りず「回線は太いのに遅い」が起きます。長距離・高遅延ほど、ウィンドウサイズ（とその拡張機能）が効いてきます。
再送が起きると急減速する
TCPは、パケットロスを「輻輳（混雑）」のサインと解釈し、ウィンドウを一気に絞ります（輻輳制御）。つまり、わずかなパケットロスでもスループットが大きく落ちます。「たまに遅い」の裏で、ロスと再送が起きていることは珍しくありません。
遅い時に見る所
- RTT（遅延）:
pingの値。距離や経路が想定通りか。 - パケットロス: 継続pingやキャプチャでロス率を確認。わずかでも効く。
- 再送の有無: Wiresharkで
tcp.analysis.retransmissionを見ると再送が可視化できる。 - ウィンドウサイズ: ゼロウィンドウ（受信側が処理しきれず0通知）が出ていないか。
まとめ
「太い回線＝速い」ではありません。スループットは、ウィンドウサイズ・RTT・ロス率の掛け算で決まります。遅延調査では、帯域だけでなくこの3つを見る——これがネスペでも実務でも効く視点です。