「ほっ」と。キャンペーン
(ネットワーク)TCPのスループットとRTTの関係
まず、RTT(往復遅延時間)というのはパケットを送信して受信した側が送信側にACKパケットを送り、送信側でそれを受取るまでの時間です。

e0091163_22465544.jpg


ネットワーク疎通テストに使う 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を返すという仕組みをとってます。
この"複数のパケットの単位"がウィンドウサイズになるわけですね。

e0091163_22465868.jpg



(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:ネットワークの設定は正しいか?
@IT:連載 基礎から学ぶWindowsネットワーク 第14回 信頼性のある通信を実現するTCPプロトコル(その1) 2.シーケンス番号とウィンドウ制御
第2回 TCP/IP高速化:大量データをまとめて送信 - スループット向上の切り札「TCP/IP高速化技術」:ITpro
ASCII.jp:WANの遅延を抑えて、レスポンスアップする
速度測定サイトについて|サービス情報サイト|サポート情報|ご利用中のお客さま|NTT東日本フレッツ公式 ウィンドウサイズとRTTによるスループットの関係図が参考になります。
ピカラ光サービス [徳島 香川 愛媛 高知] | (ピカラ光ねっと) ウィンドウサイズとRTTによるスループットの関係図が参考になります。
[PR]
by Jehoshaphat | 2011-08-29 22:48 | ネットワーク | Trackback | Comments(5)
トラックバックURL : http://jehupc.exblog.jp/tb/15349359
トラックバックする(会員専用) [ヘルプ]
※このブログはトラックバック承認制を適用しています。 ブログの持ち主が承認するまでトラックバックは表示されません。
Commented by 飛行機嫌い at 2012-08-24 21:01 x
1桁間違っていて、正しくは下記のようになると思います。
*****
仮にウィンドウサイズ64KBで、RTTが10msだとすると、1秒間に64KBを100回送ることができるということになるので、下記のようになります。
65535byte * 8 / 0.01s = 52,428,000bps
Commented by 飛行機嫌い at 2012-08-24 21:17 x
スループットを計算する式のTCPウィンドウサイズとして65535byteと65500byteが混在していますが、ネットワーク速度の実測値と比較するためにWindowsXPのデフォルトのRWINでの値を計算するのであれば、65535byteで統一すべきだと思います。pingの上限値である65500byteをそこで用いるのには、何か意味があるのでしょうか?
Commented by 飛行機嫌い at 2012-08-24 22:12 x
2012-08-24 21:17のコメントの続きです。
pingで測定したRTTを使ってスループットを計算する場合は、ping -lで指定したパケット長である65500byteを用いる、ということでしょうか? もしそうであれば、下記のようにしないといけないように思います。
*****
ということで、Pingで求めたRTTから論理スループットを計算するには下記のようにしないといけないようです。
スループット(bps) = 65,500byte * 2(往復するから) * 8 / RTT(S)
Commented by Jehoshaphat at 2012-09-10 12:39
3流PGです。
コメントありがとうございます。

>1桁間違っていて、正しくは下記のようになると思います。
>*****
>仮にウィンドウサイズ64KBで、RTTが10msだとすると、1秒間に64KBを100回送ることができるということになるので、下記のようになります。
>65535byte * 8 / 0.01s = 52,428,000bps
秒の単位が違ってましたね。修正しました。


>スループットを計算する式のTCPウィンドウサイズとして65535byteと65500byteが混在していますが、ネットワーク速度の実測値と比較するためにWindowsXPのデフォルトのRWINでの値を計算するのであれば、65535byteで統一すべきだと思います。pingの上限値である65500byteをそこで用いるのには、何か意味があるのでしょうか?
pingの結果(RTT)から、大まかなスループットを簡単に求めたいというのが今回のお題です。
ですので、本来は仰るようにPingの送信サイズをTCPウィンドウサイズと合わせるべきですが、本文中にも書いているようにpingは最大65500バイトまでしか送れません。
それで、pingの実測値で計算する場合は65500byteで計算しています。
Commented by Jehoshaphat at 2012-09-10 12:40
つづき...
書き方が悪かったかもしれませんが、本文中にある「スループット(bps) = 65,535byte * 2(往復するから) * 8 / RTT(S)」というのは理論的な計算式です。(TCPウィンドウサイズでRTTが計測できた場合の式です。) 
実際には、既に述べたようにpingを使ってRTTを測定する場合、TCPウィンドウサイズ(65535byte)では計測できず65500byteまでしかパケット送出できないので、理論式ではなく、誤差がでることを承知で 65500 を使っているわけです。
(わかりやすいように書き方を修正しました。)

最近のOSはウィンドウサイズが大きくなっており、そのサイズのでRTTが簡単に求められないので、pingのRTTからスループットを求めるのは意味がないことなのかもしれません。

RTTから大体のスループットが計算さえ出来れば、ネットワーク的にかなり距離の離れた拠点間VPNを設計する場合に目安になるかと思います。


<< (IS03)「USBストレージ... (ネットワーク)回線速度測定ツ... >>