帯域と往復待ちを分ける

100Mbit/sの回線なのに、ファイル転送がその速さにならないのはなぜでしょうか。回線速度だけでなく、確認応答が返る時間と、一度に未確認で送れる量にも制限されます。まず計測した値を分けて考えます。

事例：離れた拠点へ20MiBを送る

C社は拠点間で20MiBのデータを転送します。回線帯域は100Mbit/s、RTTは40msです。定常状態で未確認のまま送れる有効な量を128KiBとします。送受信アプリの処理時間、損失、ヘッダ等の負荷は、この最初の計算では無視します。

RTTはRound-Trip Time、往復時間です。KiBは1024バイト、MiBは1024²バイト、Mbit/sのMはここでは10⁶です。帯域、バイト量、時間の単位をそろえてから計算します。

帯域と往復待ちを分ける

同時に未確認で送れる量が小さいと、速い回線でも確認応答待ちが生じます。これは定常状態の単純化した比較です。

接続は、どの組合せで区別する？

TCPはデータを順序付きのバイト列として届けるプロトコルです。IPアドレスは通信するホスト、ポートはそのホストの通信端点を区別します。通常、送信元IP・送信元ポート・宛先IP・宛先ポートの組で接続を識別します。

サーバの待受ポートに対し、クライアントは一時ポートを使うことがあります。NATが途中でIPやポートを変える場合は、変換前後の記録を対応付けます。同じ宛先443番だけで、すべての接続を一つとみなせません。

TCPの接続開始

SYN、SYNとACK、ACKの三段階で接続条件を確認します。この図は接続後のTLSや業務処理を含みません。

SYNだけを何度も送る記録なら、相手への到達、相手の待受、規則、戻り経路などを確認します。接続成立はアプリ認証や処理成功まで証明しません。拒否応答、タイムアウト、アプリのエラーを同じ失敗として扱わないようにします。

ACKの番号は、何を確認した番号？

シーケンス番号はバイト列の位置、ACKは受信側が次に期待する位置を示します。接続成立後の最初のデータを番号1000とし、500バイトが順に届けば、次に期待する位置は1500です。TCPの基本のACKは、そこより前を累積的に確認します。

text

接続成立後のデータ例
送信：SEQ=1000 LEN=500
応答：ACK=1500
次送信：SEQ=1500 LEN=500
応答：ACK=2000

ACKが届かない場合は、データが失われた場合と、届いたデータへのACKが失われた場合があります。再送が記録されたことだけで、どこで損失が起きたかを断定しません。両端や中継の記録を比べます。

TCPが再送した同じバイトを、受信アプリへ二重の新規データとして渡すわけではありません。ただし、アプリが別の要求として再実行した処理まで一回にする保証は別です。注文などの業務処理では要求の識別と重複対策も必要です。

受信ウィンドウと輻輳ウィンドウは、何を守る？

rwnd
受信側が通知する受信ウィンドウ。受信バッファなどの余裕を超えないための制限です。
cwnd
送信側が管理する輻輳ウィンドウ。経路の混雑を考慮して送信量を調整する制限です。
有効量
未確認で送れる量は、両方の制限や送信済み量などの条件で決まります。ここでは定常状態の上限Wとしてまとめます。

この例では大きな受信ウィンドウを扱う拡張を有効にします。TCPの受信ウィンドウの通知欄だけでは65535バイトまでなので、接続開始時にWindow Scaleを合意して、大きい値を表せるようにします。通信記録では拡張後の有効値を確認します。

受信側の処理が遅い場合と、経路が混雑している場合は別です。rwndが0なら受信側が新しいデータを受け入れる余裕を示していません。回線を増速するだけで受信アプリの遅さが直るとは限りません。

送信側はACKや損失等の条件に応じて送信量を変えます。輻輳制御の算法や開始時の動作は実装で違い、転送の開始直後から常に大きなウィンドウで送れるわけではありません。確認応答の有無と、値の変化を同じ時間帯で見ます。

W÷RTTで、事例の上限を計算する

事例では定常的に128KiBを40msごとに送れるモデルです。Wをバイト、RTTを秒へ直すと、131072÷0.04＝3276800バイト/秒です。

8倍してbitへ直すと約26.2Mbit/sになり、回線の100Mbit/sより小さくなります。

計算	式	結果
量による速度	128×1024÷0.04	3276800B/s
bitへの変換	3276800×8	26.2144Mbit/s
転送時間	20×1024²÷3276800	6.4秒
回線だけの下限	20×1024²×8÷100000000	約1.68秒

この条件では、帯域だけを増やしても量÷RTTの制限が残ります。100Mbit/sを使い切るための帯域遅延積は100000000×0.04÷8＝500000バイトです。

これは必要な未確認量の目安で、設定値を増やせば必ず達成できるという意味ではありません。

6.4秒は、指定したモデルでの値です。接続開始、TLS、損失、再送、ヘッダ、送受信の処理があれば実時間は変わります。計測値と比べるときには同じデータ量・区間・時間範囲を使います。

小さい要求は通るのに、大きい転送が止まる？

MTUはリンクで運べるIPパケットの大きさの上限、経路MTUは通る経路での上限です。MSSはTCPが扱うデータ部の最大量で、IPパケット全体の大きさではありません。

例えばIPv4のMTU 1500バイトで、IPヘッダ20バイト、TCPヘッダ20バイト、追加のオプションなしなら、データ部は1460バイトです。実際はIPの版、オプション、トンネルによる追加ヘッダ等の条件を確認します。

経路の途中で小さいMTUを通る場合、送信側へ必要な通知が届かないと、大きいパケットで通信が進まなくなることがあります。IPv6のPacket Too Bigなどの通知を無条件に遮断せず、経路MTUの処理とセキュリティ規則を確認します。

大きい転送の停止だけでMTUが原因と決めず、サイズ、再送、通知の有無、経路変更と対応付けます。TCP接続が成立することと、その後の大きいデータが配送されることは別の確認です。

答案では、制約と改善の効果をつなぐ

『ネットワークが遅い』という答えを、観測された制約へ置き換えます。RTTが大きく有効量が小さいなら、送信量の条件や経路を確認する。受信側が処理できないなら、受信アプリの処理とバッファを確認する、と説明します。

原因に対応する変更を一つずつ試し、転送量・所要時間・RTT・再送・ウィンドウを再計測します。複数の設定を同時に変えると、どの変更が効いたかを確かめにくくなります。

演習1：ACKの位置

条件：接続成立後、SEQ=1000から500バイトが欠落なく届いた。

問い：次に期待する位置を示すACKは何か。

解答例：ACK=1500。

根拠：1000から500バイト分進むため、次の位置は1500である。

誤答の理由：『1499』は最後のバイト位置と次に期待する位置を混同している。

演習2：速度の単位

条件：有効量128KiB、RTT40ms。定常状態で他の制約を無視する。

問い：W÷RTTによる速度をMbit/sで求める。

解答例：128×1024÷0.04×8÷10⁶＝26.2144Mbit/s。

根拠：KiBをバイト、msを秒へ変え、8bit/Bを掛ける。

誤答の理由：『3.2768Mbit/s』はバイトとbitの変換を落としている。

演習3：転送時間

条件：20MiBを演習2の速度で定常的に送る。接続開始やヘッダ等は無視。

問い：所要時間を求める。

解答例：20×1024²÷3276800＝6.4秒。

根拠：データ量と速度を同じバイト単位で割る。

誤答の理由：『回線100Mbit/sだから約1.68秒』は未確認量の制約を使っていない。

演習4：受信側の制限

条件：サーバアプリの読出しが遅れ、受信側がrwnd=0を通知する。

問い：まず確認する対象はどこか。

解答例：受信側の処理速度と受信バッファの状態。

根拠：受信側の余裕を表す制限が観測されている。

誤答の理由：『回線を必ず増速する』は受信側の制約と対応しない。

演習5：MSSの計算

条件：IPv4 MTU1500バイト。IP20、TCP20バイトでオプションなし。

問い：TCPデータ部の上限を求める。

解答例：1500−20−20＝1460バイト。

根拠：MTUにはIPとTCPのヘッダも含まれる。

誤答の理由：『1500バイト』はパケット全体とTCPデータ部を同じにしている。

演習6：接続と転送

条件：SYNからの接続は成立するが、大きいデータで停止し、経路のMTUが小さい。

問い：追加で確かめる観測を挙げる。

解答例：大きいパケットの再送と、経路MTUに関する通知が送信側へ届くかを確認する。

根拠：小さい接続開始が成功しても、サイズ制約を超える配送の成功を証明しない。

誤答の理由：『接続したので経路に問題はない』はデータサイズによる差を無視している。

出典と仕様を確認する

回線は速いのに転送が遅い？｜TCP・RTT・ウィンドウ・MTU