「T1回線（1.544 Mbps）からT3回線（44.736 Mbps）にアップグレードしたばかりなのに、なぜそのファイルのコピーにまだ90分もかかるんだ？」
単純な答えは、容量の増加が転送速度の向上とは同義ではないということです。容量を約29倍（44.736 ÷ 1.544）に増やしても、90分で29個のファイルをコピーできる可能性はありますが、その1つのファイルのコピー速度が速くなることはおそらくありません。 この点については昨年「アプリケーション性能問題とレイテンシ」と題したブログで触れたが、ファイル転送とcopy_fileについてはより焦点を絞ったブログが必要だと考える。
鍵となるのはウィンドウサイズ、すなわち送信側ホスト/アプリケーションが受信側ホスト/アプリケーションからの確認応答を待たずに送信できるバイト数である。FTPのような一部のアプリケーションはアプリケーション層での確認応答を持たず、TCPに依存する。この場合、ウィンドウサイズはリモートホストのTCP層が広告する値に基づき、STCPがサポートする最大値である64Kバイトまでとなる。 アプリケーション層ウィンドウを持つアプリケーションの場合、制限となるウィンドウはTCPウィンドウとアプリケーションウィンドウのうち小さい方となります。
最大スループットは次のように計算される
W / RTT = T
どこ
W はウィンドウサイズ（バイト単位）
RTTは往復時間（秒単位）です
T は秒あたりのバイト単位のスループットである
往復時間とは、データを送信してから応答を受信するまでの時間を指します。 長距離、すなわち国境を越える通信の場合、この時間は主に、バイトが移動しなければならない距離と、両端点間のすべてのネットワーク機器の処理速度に基づきます。受信ホストの処理速度、パケットサイズ（TCP MSS値、「サブネット間スループットを改善する簡単な方法」参照）、そしてもちろん最も遅いリンクの帯域幅は、より小さな役割を果たします。
例えば、RTTが0.050秒でウィンドウが64Kの場合、最大スループットは1,310,720バイト/秒（64 × 1024 ÷ 0.050）となる。リンクの未使用容量がスループットを上回っている限り、容量を増やしても転送時間は短縮されない。
Tは最大スループットである。ウィンドウを拡大するかRTTを短縮する以外、いかなる操作も速度を向上させられない。ただし、悪意のあるネットワーク環境では速度が大幅に低下する可能性がある。
転送時間の推定は、ファイルサイズをスループットで割るだけです
F/ W * RTT = Ti
どこ
F はファイルサイズ（バイト単位）です
W はウィンドウサイズ（バイト単位）
RTTは往復時間（秒単位）です
Ti はファイル転送にかかる時間（秒単位）
OSLのアプリケーションウィンドウサイズは4Kです。OpenVOSファイルシステムはファイルサイズを4Kバイト単位で報告するため、copy_fileコマンドを使用して2つのOpenVOSシステム間でファイルをコピーする時間を推定するには、単純に
F * RTT = Ti
どこ
F はブロック単位でのファイルサイズである
RTTは往復時間（秒単位）です
Ti はファイル転送にかかる時間（秒単位）
RTTが0.050秒のリンクでは、OSLが50,000ブロックのファイルをコピーするのに41分強（50,000 × 0.05）かかります。 最大スループットは81,920バイト/秒（4096 / 0.050）となります。リンクの未使用ネットワーク容量が81,920バイト/秒を超える限り、容量を追加してもファイルコピー時間は短縮されません。
往復時間を測定する最も簡単な方法はpingです。残念ながら、pingはRTTを単一の数値で示すのではなく複数の数値を返し、それらの数値は大きく変動する可能性があります。例えば：
ping 172.16.1.80 Pinging host 172.16.1.80 : 172.16.1.80ICMP Echo Reply:TTL 53 time = 418 msICMP Echo Reply:TTL 53 time = 107 msICMP Echo Reply:TTL 53 time = 91 msICMP Echo Reply:TTL 53 time = 100 msHost 172.16.1.80 replied to all 4 of the 4 pingsready 12:03:15 |
最高のスループットを計算したい場合は最小値を使用してください。期待値の妥当な見積もりを得たい場合は、pingカウントを10回行い、最大値2つと最小値2つを除外し、残りの値を平均してください。
ping 172.16.1.80 -count 10Pinging host 172.16.1.80 : 172.16.1.80ICMP Echo Reply:TTL 53 time = 89 msICMP Echo Reply:TTL 53 time = 96 msICMP Echo Reply:TTL 53 time = 95 msICMP Echo Reply:TTL 53 time = 105 msICMP Echo Reply:TTL 53 time = 186 msICMP Echo Reply:TTL 53 time = 87 msICMP Echo Reply:TTL 53 time = 90 msICMP Echo Reply:TTL 53 time = 90 msICMP Echo Reply:TTL 53 time = 89 msICMP Echo Reply:TTL 53 time = 96 msHost 172.16.1.80 replied to all 10 of the 10 pingsready 12:12:39 calc 96 + 95 + 90 + 90 + 89 + 96 556ready 12:12:49 calc 556 / 692.6666666666667ready 12:12:57 |
前述の通り、敵対的なネットワークは処理を大幅に遅延させ得る。Pingタイムアウトはその兆候である。従って、いかなるタイムアウトも、これらの計算がかなり楽観的である可能性を示唆している。 ディスクやCPUの負荷が高まると転送速度が低下する。送信側がデータを読み取り送信する速度が制限されたり、受信側がデータ到着速度に追いつけず読み取りが遅延したりすると、アプリケーションの応答が遅延（往復時間増加）し、TCP受信バッファが満杯になる可能性がある。この場合、送信ホストは送信を停止する。これらの状態を特定するにはパケットトレースが唯一の方法である。