遅延からのボトルネック - 2

2つ目の遅延からのボトルネックは、TCPのスロースタートと輻輳制御になります。1つ目の遅延からのボトルネックはウィンドウサイズの最大値によるものでしたが、この2つ目のボトルネックは、TCPは継続的に決められたウィンドウサイズで通信をしないという特性です。 TCPでは、通信が成功していると判断すると、徐々にウィンドウサイズを拡大します。　また逆に通信が失敗していると判断すると、極端にウィンドウサイズを縮小してしまいます。

遅延からのボトルネック - 3

3つ目の遅延からのボトルネックは、TCPの上で動作するアプリケーションプロトコルです。1つ目のボトルネックで紹介したように、TCPのウィンドウサイズが決まっていると帯域幅は関係無く、毎回の通信でアクノレッジをしなければ次のデータを送信できません。同様に、アプリケーションの通信においてアプリケーションプロトコルに規定されたメッセージサイズがあり、またアプリケーションレイヤーにてアクノレッジや応答が無い限り次の処理へ移らないとすると、帯域幅や1つ目と2つ目の遅延問題を解決したとしても遅延からのボトルネックを回避した事にはなりません。

HTTPやFTPのように、WAN環境で利用する事を想定したプロトコルでは、比較的この問題に直面するケースは少ないですが、もともとLAN内で利用する事を想定して開発されたアプリケーションプロトコル（例：Microsoft WindowsのCIFSファイル共有）は遅延からの影響を受けやすいと言えます。図2では、1.544Mbps（T1）の回線でCIFSとTCPを比較していますが、同じようなカーブでそれぞれスループットが低下していくのが分かります。TCP（図3の青線）は、40msecからスループットが低下していくのを再度確認できます。しかしながら、CIFS（図3の赤線）は、遅延が少しでも大きくなるとスループットが大幅に低下していくのが分かります。TCPだけを最適化しても、CIFSはそれほど速くならないのです。WANでの通信を想定したアプリケーションでは、TCPを最適化するだけでそれなりの効果があるかもしれませんが、図3のグラフの通り、CIFSは広帯域で合理的なTCPの通信手法を用いても期待した効果を得る事ができないのです。