アプリケーショントラフィック管理入門 第5回

WAN高速化の基礎技術　第1弾

WANの遅延を抑えて、レスポンスアップする

信頼性を重視した
TCPの最適化

　まずは、現在プロトコルとして主流となっているTCPの問題が挙げられる。TCPはIPの上位にあたるトランスポート層のプロトコルで、ポート番号によってアプリケーションの特定を可能にするほか、IPの通信に信頼性を加える仕組みを持っている。Webやメールのほか、多くのアプリケーションはこのTCPを用いて、データを送受信する。

　このうちTCPの再送メカニズムがふくそう制御など信頼性を確保する仕組みが、パフォーマンスの劣化を生む要因となっている。レスポンスが低下する最大の理由はパケットロスとそれに伴う遅延だ。パケットロスは文字通りパケットが経路上で損失すること。また、遅延とは文字通りパケットの到着が遅れることを指す。

　インターネットが普及した1990年代、通信環境は必ずしも安定したものではなく、パケットロスや遅延という出来事は珍しいものではなかった。そもそも帯域が細く、伝送能力が低かった時代には、パケットロスや遅延自体が許容されてきた経緯がある。しかし、ネットワークがブロードバンド化するとともに、遅延の影響は無視できなくなってきた。そこで、低速な回線を前提としていたTCPは修正が必要になってきたのだ（図3）。

図3　TCPの再送遅延とふくそう制御の問題点

　スループットは帯域とは関係ない遅延は2台のホストの間で往復にかかる時間であるRTT（Round TripTime）で計測される。RTTは、TCPにおいてはパケットを送ってから、相手から確認応答（ACK）が戻ってくるまでの時間を指す。TCPのスループットは、帯域とは関係なく、このRTTとウィンドウサイズから算出される（図4）。ウィンドウサイズとは受信確認を受け取らずに一度に送れる量を指す。そしてTCPのスループットは、ウィンドウサイズ（ビット）/RTTという式で算出される。Windows XPでの標準ウィンドウサイズは16KBなので、遅延が10ms（ミリ秒）だと、たとえ100Mbpsの帯域があってもスループットは12.5Mbpsしか出ないのだ。

　また、当然ながらRTTが長ければ長いほど、スループットは下がる。通常、LAN内においては1ms程度に留まるのでほとんど遅延はないが、国内でのWANでの通信で10～50ms程度、国際WANやケータイ系通信では100～300msにも及ぶことになる。送信したパケットの確認応答を待ってから次を送るTCPにおいては、RTTの長さは致命的というわけだ。パケット送りっぱなしのUDPに比べ、やり取りの多いTCPではパケットの交換ごとにRTTが累積され、大きな遅延となってしまう。

図4 スループットの算出はRTTとウィンドウサイズが必須。回線の帯域とは関係はない

タイムアウトでパケットロスを検知

　TCPでは、いったんパケットロスが発生すると、遅延が発生しやすくなる。TCPではパケットロスを、タイムアウトで検知する。一定時間、宛先から確認応答が戻ってこなければ、パケットロスが発生したと判定するわけだ。当然、ACKパケットが戻ってこなければ、次のパケットを送信ができないので、その分RTTは大きくなる。

　また、TCPでは、いったんパケットをロスすると、ふくそう制御の機能により、ウィンドウサイズは一気に半分にまで下げられる。そこからスロースタートで徐々に元のウィンドウサイズまで回復するという手はずになる。つまり、帯域が太ければ回復に時間がかかるため、遅延はますます大きくなるわけだ。

　次回はこれらTCPの弱点を解消するための技術に迫る。