1MBのファイルアクセスに10分――WANの体感速度が改善しないのはなぜ？：最適化から始まる、WAN高速化への道（2/3 ページ）

[井上猛雄，ITmedia]

TCPやアプリケーション固有の欠点

　ところで、WANの回線速度が遅いのなら、単純にWAN回線を増強すればよいのではないかという素朴な疑問が頭に浮かぶ。だが、問題はそう簡単ではないようだ。

　まず、コスト的な問題がある。WANの増強によって、月額の回線コストが跳ね上がることもあるからだ。例えば、前述のDRの要件において、データセンターにバックアップデータをコピーする際、特にこれが顕著になる。

　F5ネットワークスの武堂貴宏シニアプロダクトマーケティングマネージャーは、「RTO（Rocovery Time Objective：目標復旧時間）の観点からバックアップを頻繁に取り、データを早く復旧したい。その際には、なるべく効率良くデータを転送したい、というユーザーの要望がある。一方で、IP-VPNなどの広域ネットワークでは100万円後半ぐらいのコストが掛かり、ユーザーが回線増強をあきらめてしまうケースもある」と指摘する。

　また、WAN回線のコストの問題だけでなく、もっと本質的な問題もある。いくらWAN回線を太くしたからといっても、必ずしも速度が改善するとは限らないからだ。インターネットが普及した現在、企業で用いられるプロトコルはTCPが中心になっている。TCPのスループットは、データを送受信する際のバッファ容量「ウィンドウサイズ」と、パケットが通信ホストの間を往復する時間「ラウンドトリップタイム（RTT）」によって決まる。つまり、「TCPスループット＝ウィンドウサイズ÷RTT」という式が成り立つ。

　ここでウィンドウサイズが大きければ、一度に多くのパケットを送れることになるが、Windows 2000/XPでのウィンドウサイズはデフォルトで16KB（最大64KB）になっている。もちろん遅延時間のRTTを短縮すれば、スループットは向上するが、海外拠点を結ぶWANなどの場合には、距離による遅延の問題も大きく、スループットの向上にも限界がある。例えば、東京と大阪ではRTTは約20msほどだが、東京−ニューヨーク間など太平洋をまたぐと約140msになってしまうと言われている。

　表1は距離遅延と理論的な最大通信速度の関係を示したものだ。いくら太い回線にしても、東京−ニューヨーク間では理論的には最大で約920Kbpsしか速度が出せないことになる。

表1●距離遅延と理論的な最大通信速度の関係

区間	遅延時間（往復）	理論的な最大通信速度
東京-大阪間	約20ms	約6.4Mbps
東京-ソウル間	約80ms	約1.6Mbps
東京-ニューヨーク間	約140ms	約920kbps

　また、信頼性の高い通信を実現するTCPならではの特徴があだになってしまうこともある。

　詳しく説明すると、TCPでは、通信を開始する際にセッションを確立し、データ転送後に確認応答パケット（ACK：Acknowledgement）を返す（図2）。終了時にも同様の手順を踏むコネクション型の通信方式だ。

図2●TCPの通信手順。TCPは信頼性の高い通信を実現するが、確認応答が遅れたりパケットロスが発生すると、結果としてスループットに影響を与えることになる

　もし、ある時間内にACKが返ってこない場合は、送信パケットが喪失したものとみなし、再送処理の手続きに入る。回線品質が悪くて経路の途中でパケットロスが多発したり、確認応答が遅れたりすると（タイムアウト）パケットを再送することになるが、この際にすでに送られたパケットが重複して送られることもある。パケットロスが発生した際には、経路上の混雑を悪化させないように輻輳（ふくそう）回避の仕組みが働くが、送信時のウィンドウサイズを小さくしてデータ量を絞り込むため、結果としてスループットに影響を与えることになる。