まず、RTT(往復遅延時間)というのはパケットを送信して受信した側が送信側にACKパケットを送り、送信側でそれを受取るまでの時間です。
ネットワーク疎通テストに使う ping も結果に RTT が表示されますよね。(XP だと下記の time のところです)
>ping 10.0.120.1
Reply from 10.0.120.1: bytes=32 time=38ms TTL=54
さて、これとは別にTCPプロトコルにはウィンドウサイズというものがあります。
TCPは確実にパケットが届いたかどうかを確認するため、受信側が送信側にACKパケットを返すわけですが、毎回のパケット一つずつにACKを返すと非常に効率が悪いため、送信側が複数のパケットを送信し、その複数パケットに対してまとめて1回のACKを返すという仕組みをとってます。
この"複数のパケットの単位"がウィンドウサイズになるわけですね。
(TCPウィンドウサイズはWindowsとかだとRWINと呼ばれており、一時期ブロードバンド回線ならこの値を大きくすることでネットの高速化につながるというような情報もちらほら見られました。)
このウィンドウサイズですが、基本的はOSで決まっています。
WindowsXPだと64KB(65535Byte)です。
WindowsXPやWindowsServer2003以前のウィンドウサイズについては、Windows Server 2003 SP1 での TCP 受信ウィンドウのデフォルト サイズ変更についてが参考になります。
TCPの当初の規格ではウィンドウサイズは最大64KBですが、後に規格拡張されたようで、次世代の TCP/IP スタックのパフォーマンスの拡張機能によるとVista以降だと最大16MBまで増やすようです。
(WindowsのウィンドウサイズはOSが徐々に大きくしてくれるようですね。つまり品質の悪い回線は小さく、いい回線は大きくしてくれるようです。最大値は上述の通りバージョンによって異なりますが。。)
さて、ここからが本題ですが、ウィンドウサイズとRTTからTCPのスループットを求めることができます。
TCPのACKはウィンドウサイズ毎に送信側に返ってくる(この時間がRTT)ので、TCPの理論最大スループットは下記の計算式で求めることができるわけです。
スループット(bps) = TCPウィンドウサイズ(KB) * 8 / RTT(S)
仮にウィンドウサイズ64KBで、RTTが10msだとすると、1秒間に64KBを100回送ることができるということになるので、下記のようになります。
65535byte * 8 / 0.010s = 52,428,000bps
これらの計算方法については下記サイトが参考になります。
教科書には載っていない ネットワークエンジニアの実践技術:第1回 FTPでスループット計測するときの注意事項|gihyo.jp
@IT:連載 基礎から学ぶWindowsネットワーク 第14回 信頼性のある通信を実現するTCPプロトコル(その1) 1.信頼性のある通信を実現するための仕組み(※2の部分に式があります)
ということで、実際にテストをしてみました。
まず、RTTですが、Pingで計ってみます。
>ping -l 65500 192.168.0.11
Pinging 192.168.0.11 with 65500 bytes of data:
Reply from 192.168.0.11: bytes=65500 time=11ms TTL=128
Reply from 192.168.0.11: bytes=65500 time=11ms TTL=128
Reply from 192.168.0.11: bytes=65500 time=11ms TTL=128
Reply from 192.168.0.11: bytes=65500 time=11ms TTL=128
Ping statistics for 192.168.125.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 11ms, Average = 11ms
RTTは11ms=0.011sとなってますね。OSはXPなので、pingのパケット長はXPのウィンドウ最大サイズと同じ64KBにしています。
後は、計算式に当てはめてみると下記のようになります。
65500byte * 8 / 0.011s = 47,636,363bps
ん? 47Mbps???? 測定したのはL2スイッチを2個経由しただけの100Base-TX LANなので、こんなに遅いことはないはずです。
実際に、Iperfで下記の設定で測定してみたところ、94Mbpsはでる結果になりました。上記で求めた理論値(47Mbps)の倍になっています。
bin/iperf.exe -c 192.168.0.11 -P 1 -i 1 -p 5001 -w 64.0K -f b -t 10
...
[1904] 0.0-10.0 sec 118194176 Bytes 94547474 bits/sec
ここで引っ掛かったのは ping で計測した RTT の値です。
よくよく調べたら、Ping の応答に当たるICMPエコーは、送信元が送ったデータパケットをそっくりそのまま消すようです。(先頭のタイプフィールドにエコー応答(0)とするようですが。。)
つまり、Pingで64KBのパケットを送った場合、RTTの値は64KBの往復値つまり128KBの時間となるわけですね。
このPingの仕様に関しては、@IT:連載 基礎から学ぶWindowsネットワーク 第12回 TCP/IPプロトコルを支えるICMPメッセージ 1.ICMPメッセージ(1)、pingでネットワークの速度を調査する - @ITが参考になります。
ということで、Pingで求めたRTTから論理スループットを計算するには下記のようにしないといけないようです。
スループット(bps) = 65,500byte * 2(往復するから) * 8 / RTT(S)
この式で上記の値を計算すると下記のようになり、実測とほぼ近い値が出ます。
65500byte * 2 * 8 / 0.011s = 95,272,727bps
Pingは最大65500バイトまでしか送れないので、それを超えたバイトをおくって純粋なRTT(ウィンドウサイズ先頭の送信開始から、ACKパケットが返ってくる時間)を測定できるようなフリーのツールがあればいいのですが、なかなかみあたりません。。。
もし、pingで65,535byteを送信できれば以下の式でスループットを計算できます。(XPの場合。他のOSの場合はそのOSのTCP最大ウィンドウサイズで測定する必要あり)
スループット(bps) = 65,535byte * 2(往復するから) * 8 / RTT(S)
しばらくの間にすっかりネットワークの詳しい動作について忘れてしまっている3流PGです。
参考:
@IT:連載 基礎から学ぶWindowsネットワーク 第15回 信頼性のある通信を実現するTCPプロトコル(2) 1.TCPパケットの構造
TCPの理論スループット: ネットワーク技術の覚書 - Kaztan's Cafe
@IT:連載 基礎から学ぶWindowsネットワーク 第14回 信頼性のある通信を実現するTCPプロトコル(その1) 2.シーケンス番号とウィンドウ制御
第2回 TCP/IP高速化:大量データをまとめて送信 - スループット向上の切り札「TCP/IP高速化技術」:ITpro
ASCII.jp:WANの遅延を抑えて、レスポンスアップする
速度測定サイトについて|サービス情報サイト|サポート情報|ご利用中のお客さま|NTT東日本フレッツ公式 ウィンドウサイズとRTTによるスループットの関係図が参考になります。
ピカラ光サービス [徳島 香川 愛媛 高知] | (ピカラ光ねっと) ウィンドウサイズとRTTによるスループットの関係図が参考になります。