Pingを使用して帯域速度は計算できません

はじめに

TwitterのTLで流れてきたのですが、「Pingを使ってネットワークの速度を計測できる」という情報を信じちゃう方が一定数いるようです。
調べてみたら、思ったよりもTechブログや技術系メディアで取り上げられているのでちょっとまずいなと思いました。
そこで、この記事ではその誤解を明確に否定し、論拠を示しながら正しい情報をお伝えしたいと思います。

【参考】Pingで帯域計測を紹介している記事

ざっと検索してみたところ以下の記事が上位にヒットしました。

...って結構多いんですね...うーん...

回線品質の指標とは（基礎のお勉強）

そもそも、ネットワーク回線の品質を測定するための指標は「速度」だけではありません。
まずは、4つの指標について解説します。

1. 帯域（スループット）

帯域は単位時間あたりに転送できるデータ量を指します。
「スループット」「帯域幅」「回線速度」も概ね同じ意味です。
一般的に「10ギガ回線」といえば、その回線の最大速度が10Gbpsであることを意味します。

ただし、実際の通信速度はネットワーク経路上の最も遅い区間（ボトルネック）以上の速度が出ません。
例えば、10Gbpsの光回線を利用していても、途中経路上でどこか1か所でも1Gbpsになっていれば、実際の通信速度は1Gbps以下になってしまいます。

2. 遅延（レイテンシ）

遅延は、データが送信元から宛先まで到達し、応答パケットを受信するのにかかる時間を指します。
最近ではPingの使い方を紹介する記事等でも「Ping値」として紹介されることがありますが、正しくは「遅延」または「レイテンシ」です。
RTT（Round Trip Time）も遅延のことを指します。
*「Ping値」を現場で使うと、総ツッコミを受けると思うので試してみてください笑笑

3. 損失（パケットロス）

損失は、送信されたデータのうち、宛先から応答を受信できずロストした割合を指します。
宛先へ到達しなかったケースももちろん、相手先が応答しないなど、理由は問わず「応答を受信しなかった」ものはパケットロスとして扱われます。（当然ですが...）
国際回線では意識することが多いですが、日本国内では日常的に気にするレベルでパケットが失われることはほとんどないと思います。
損失率が高いとデータ通信の再送が必要になることで、間接的にスループットを低下させる要因になる場合があります。

4. ジッター（ゆらぎ）

ジッターは、遅延時間がどれだけ変動するかを示す指標です。
値が大きいということは、遅延のばらつきが大きいということです。ジッターが大きくなるとパケットの到着順序が乱れて入れ替わるなどの問題が発生します。

TCPであれば、受信側でソートしてデータを完成させてから受け取るのであまり問題ありませんが、通話アプリや動画配信などではUDPで転送しているため、通話品質が大幅に低下する原因になります。

Pingで計測できるもの

Pingはネットワーク診断に便利なツールですが、計測できるのは遅延(レイテンシ)のみです。
一応、損失も見ることはできますが、参考にできるほどの母数がないです。

まずは、Pingの実行結果を見てみましょう。

Microsoft Windows [Version 10.0.22631.4460]
(c) Microsoft Corporation. All rights reserved.

C:\Users\DummyUser>ping google.com

Pinging google.com [142.250.72.206] with 32 bytes of data:
Reply from 142.250.72.206: bytes=32 time=20ms TTL=115
Reply from 142.250.72.206: bytes=32 time=21ms TTL=115
Reply from 142.250.72.206: bytes=32 time=22ms TTL=115
Reply from 142.250.72.206: bytes=32 time=20ms TTL=115

Ping statistics for 142.250.72.206:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 20ms, Maximum = 22ms, Average = 21ms

C:\Users\DummyUser>

Pingは小さなデータを相手に送信して応答を受信するシンプルなプロトコルです。
得られる情報は端的に以下の2つしかありません。

損失: 1発ごとに応答を受信できたかどうか。
遅延: 送信してから応答を受信するまでの時間を計測。

Pingで帯域を計測する誤った方法

pingでネットワークの速度を調査する - ＠IT

pingを1回実行すると、これだけのサイズのパケットが往復することになるので、それと所要時間からおおよそのネットワークの速度を計算できる。ヘッダーやIPフラグメント化（元は1つだったIPパケットが複数に分断されること。右上の関連記事参照）のオーバーヘッドなどを全て無視すると、次のようになる。

　帯域≒（データ・サイズ×2）÷所要時間［bytes/s］

誤っている点だらけなのですが、道路に例えるとイメージしやすいと思います。

帯域幅を求めてください
→　東名高速を1時間当たり 何台が通過できるか を求めてください。
帯域 = データ量 ÷ 遅延で求められる
→　データ量は 車の台数、遅延は 移動にかかった時間 で求められる。

これが正しいとすれば...

東京-名古屋間の所要時間は 5時間
テストに参加した台数は 5台
→　東名高速は1時間当たり 1台しか通れません！

そんなわけないですよね...

Pingで計測するのがなぜ誤りなのか

扱うデータ量が少なすぎる
帯域幅を測りたいのであれば、最低でもその帯域をパンパンに埋める必要があります。
そうでなければ実測で測れません。
Pingは32byteしかありません。オプション使って最大値にしても1パケットの最大値(MTU)でも1500bytesです。
細めの100Mbpsの帯域を測るだけでも1秒に 100,000発 程度は打たないと話にならないですね。

遅延は距離によって長くなる
そもそも遠距離になるほど遅延が大きくなります。
例えばブラジルはすごく遠いので、遅延は300msecかかります。
都内同士は近いので、遅延は1msecで済みます。
どちらも100Mbpsの回線ならば10GBのデータを送信するのに15分弱かかります。
応答を待たずに次々送るんですから...当たり前ですよね？
先ほどの計算式が正しいのであれば、300msecかかるブラジル宛より1msecの東京宛が 300倍も帯域が太い ことになりますね。
同じ100Mbpsの回線なのに…

正しい帯域幅測定方法

こちらは様々な記事で紹介されていますので、弊社で利用している主なツールを紹介するにとどめます。
ただし、どのツールを使ってもワイヤーレート(リンク速度)は出ません。
~~通常のPCであれば1台当たり100~300Mbps程度です。~~
追記:ちゃんと性能出てるPCなら800〜950Mbps出るみたいです。(私はオンボロPC流用なので…)

それを超える測定をしたい場合は単純に台数を増やす必要があります。

1. Nana

ネットワーク機器の転送処理能力（スループット）について