ネットワ-クの速度を調べる方法

●「速さ」 の意味は?
●遅延時間を測る
●データ帯域を測る
 特定のサーバ間の速度の調査
 試験用のファイルを作る
 wgetで速度を測定
 スクリプト
●速度低下や変動の原因
●回線を高速化すべきか?どこまで?


●「速さ」 の意味は?

 TCP/IP に使っている回線のスピードと言っても大まかには "バンド幅" と "レイテンシ" の2つがある。
●遅延時間を測る

 片道の時間遅れ(latency)を独立して測るのは困難。pingコマンドで往復遅延時間(round-trip time)を調べる。

 GPS時計で高精度に時刻をあわせたマシン間でなら往路と復路を別々に測れそうだ。ミリ秒単位(注:1ミリ秒は距離に換算して 200km 程度)までの測定なら基本レベルの演習問題かな? GPS clockの同期精度は安直にサーバを作っても数micro秒の精度が出る(距離に換算して数百m)。(ヒント:RFCでNTPのプロトコルを調べる。)(ヒント:ntpのソースを見よう。)

●データ帯域を測る

 特定のサーバ間の速度の調査

 以下の方法では、FTPサーバに試験用のファイルを作成しておいてgetして所要時間を測定する。前述しているように、遠くのサーバとの間でこれをやると、遅延時間を測定するのと同じ事になる。

 回線の先にFTP(または、WWW)サーバが必要。LANの試験なら簡単だが、外部接続ではこれが一番のネックかも。試験用ファイルのサイズに拘らないなら、適当なanonymous FTPサーバ(または、WWWサーバ)から適当なサイズのファイルをダウンロードすると良い。

 試験用のファイルを作る

 回線能力にあわせて適当なサイズの試験用ファイルを作る。1M、10Mなどの切りの良いサイズなのは、転送時間の見積もりがしやすいからで、特に深い意味は無い。

例えば、1Mbpsの回線の場合、1Mbyteのファイルでは所要時間は最低でも8秒程度。10Mbyteのファイルだと、その10倍だから約80秒かかる。

$ dd bs=1024 count=10  if=/dev/urandom of=test_10K
$ dd bs=1024 count=100  if=/dev/urandom of=test_100K
$ dd bs=1024 count=1024  if=/dev/urandom of=test_1M
$ dd bs=1024 count=10240  if=/dev/urandom of=test_10M
$ dd bs=1024 count=102400  if=/dev/urandom of=test_100M
$ ls -l test_10M
-rw-r--r--    1 kodama   users    10485760  8月  2日  01:34 test_10M
      test_10M は 10M byte のサイズ

 wgetで速度を測定
  1. サーバ側のディスク読み込みなどの影響があるため、数回繰り返し測定する。
  2. getした内容は/dev/nullに捨てる(クライアント側のディスク負荷の影響を避けるため)。
  3. 大まかな回線能力の見積もりをしておいて、試験用ファイルのサイズの中から適当なものを選ぶ。ファイルが小さ過ぎると他のオーバーヘッドの影響が大きいので誤差が大きい。ファイルが大き過ぎると時間がかかり過ぎる。良く分からないなら、小さい方からtest_10K、test_100K、test_1M、test_10Mの順に試験してゆき、時間がかかり過ぎない程度で止める。
  4. ネットワークやサーバにかなりの負荷がかかる。他に迷惑をかけないように注意しよう。
  5. 上で作ったファイルでなくても、適当な大きさのファイルが(ftpやwwwに)あればなんでも良い。試験したい回線の向こう側に、ftpやhttpサーバを自分で確保するのは LAN の試験以外では難しい。要するに適度に大きめのファイルがあればなんでも良い。ただし、他人の利用との干渉が無い方が良いので混雑しているところや細い回線の先は避ける。
※anonynmousでデータを取得する場合
$ wget -O - ftp://localhost/test_100M > /dev/null
--2015-04-16 15:51:27--  ftp://localhost/test_100M
           => `-'
localhost をDNSに問いあわせています... 127.0.0.1
localhost|127.0.0.1|:21 に接続しています... 接続しました。
anonymous としてログインしています... ログインしました!
==> SYST ... 完了しました。    ==> PWD ... 完了しました。
==> TYPE I ... 完了しました。  ==> CWD は必要ありません。
==> SIZE test_100M ... 104857600
==> PASV ... 完了しました。    ==> RETR test_100M ... 完了しました。
長さ: 104857600 (100M) (確証はありません)
100%[==========================================================>] 104、857、600 --.-K/s 時間 0.09s   
2015-04-16 15:51:27 (1.03 GB/s) - stdout へ出力しました [104857600]
※あるアカウントでデータを取得する場合
$ wget --ftp-user=hoge --ftp-password=password -O - ftp://localhost/test_10M > /dev/null
--2015-04-16 14:22:16--  ftp://localhost/test_10M
           => `-'
localhost をDNSに問いあわせています... 127.0.0.1
localhost|127.0.0.1|:21 に接続しています... 接続しました。
user としてログインしています... ログインしました!
==> SYST ... 完了しました。    ==> PWD ... 完了しました。
==> TYPE I ... 完了しました。  ==> CWD は必要ありません。
==> SIZE test_10M ... 10485760
==> PASV ... 完了しました。    ==> RETR test_10M ... 完了しました。
長さ: 10485760 (10M) (確証はありません)
100%[==========================================================>] 10、485、760  --.-K/s 時間 0.01s   
2015-04-16 14:22:16 (1.00 GB/s) - stdout へ出力しました [10485760]

 この例では、内的な処理((localhost)だけで、ネットワークは使わないのでこれ(69.44[MB/s]=555[Mb/s])が今回使用したPCで測定できる最高速を表す。最近のCPUなら、内的な処理はもっと速いはず。

 実際の測定では上の "localhost" の部分をFTPサーバ名に変えて使う。

 スクリプト

 スクリプトを作ったが、wgetを直に動かして、2〜3回観察するだけでも良いと思えて来た。

 10Mのファイルのダウンロードをn回測定して、速度の平均を表示するスクリプト。wgetの起動時間などの影響で少し誤差が出る。 ネットワークにかなりの負荷がかかる。

#!/bin/sh
# Measure network speed。
# Usage:  net-speed。sh  (resource URL)  [iteration]
resource=$1
## e.g.
## ftp://localhost/pub/test_10M
## http://localhost/~test/test_10M
count0=$2
if [ -z "$count0" ] ; then count0=3; fi
# fill up server cache.
wget -O - -q ${resource} > /dev/null
LOOP(){
   count=0
   while [ $count0 -gt $count ]; do
      count=`expr $count "+" 1`
      (time wget -O - -q ${resource} > /dev/null)2>&1
   done
}
LOOP | gawk 'END{print "Average: "sum/n}/real/{gsub(/[ms]/、" ");n=n+1;s=10/($2*60+$3);sum=sum+s;print s"[M/sec]"}'

●速度低下や変動の原因

 問題がありそうなら経路上にある要素を順に検討してゆく。
●回線を高速化すべきか?どこまで?

 上で説明した様に、個々のTCPセッションに関しては、帯域の限界は往復遅延時間で制限されてしまう。 つまり、回線が太くなっても、相手の返事待ちでデータをケーブルに詰め込めないなら無意味。 この境目となる距離はデータがケーブル中を占有する長さが目安となる。

以下では、TCP 通信を基準に回線の品質と使用目的について概説してみた。 ただし、UDP を使ったビデオ配信などを行うなら、以下とは違った観点で評価する必要がある。