数字が意味を持つようにVPNの速度を測る方法
テストサーバーを固定し、下位層を動かさず、遅延とスループットを分けて読む。トンネルは何かを測る前に経路を変えてしまう。
速度テストが測るのはVPNそのものではない。測るのは経路であり、トンネルを有効にすると最初のバイトが動く前にその経路の一部が置き換わる。だから同じノートPCでも、どちらの側も何も変わっていないのに、あるサイトでは健全な数値が出て別のサイトでは悪い数値が出る。結果は経路についての証拠として読み、製品の点数として読まないこと。
比較に意味があるかどうかは、両方の実行が同じ目標に当たったか、アクセス網が動かずにいたか、そして遅延を容量と並べて記録したか、という三つの点で決まる。
トンネルが最初のバイトの前に書き換えるもの
クライアントはすべてのパケットをさらにもう一つのヘッダーで包むので、パケットあたりの使えるペイロードは小さく、コストは転送あたりではなくパケットあたりにかかる。つまり大きなファイルは、トンネルを通さない同じファイルより多くのパケットを必要とする。こうした余分は、見える設定ではなくパケット数として現れる。
そこから二つの帰結が出る。大きなブロックで組んだテストはパケットあたりのコストを感じ、多数の小さな要求で組んだテストは代わりに往復を感じる。そして経路MTUの探索が途中で遮断されていると、トンネルはより小さなパケットサイズに落ち着き、暗号方式とは何の関係もない理由でスループットが下がる。
上限は直接見ることができる。Linuxで断片化せずに通る最大のペイロードを求め、次にトンネルを有効にして繰り返す:
ping -M do -s 1472 -c 3 203.0.113.10
それが失敗したら、1,400まで下げて再試行する。1,380バイトしか運ばないトンネルは、経路のもっと先で何かが絞っていると告げており、クライアント側の調整では持ち上がらない。
トンネルが有効になるとテストサーバーが動く理由
ほとんどのツールは、自分が見える公開アドレスから近いサーバーを選ぶ。トンネルが有効ならそのアドレスは出口ノードのものなので、ツールは別の都市や国のホストを選ぶことがある。そのとき比べているのは二つの宛先であり、両者の差には出口からテスト用ホストまでの距離が含まれる。
最初の実行の前にサーバーを名前かIDで固定し、以後のすべての実行でそれを保つ。ツールが保たないなら自分で制御できる目標を選んで自分で動かし、iperf3 -c test.example.net -R -t 20で宛先を固定すれば昨日と比べられる数値が得られる。
変数を一つ変える、下位層は一つではない
無線がいつもの隠れた変化で、ノートPCが動けば信号強度が変わり、隣人が通話を始めればチャネルの混雑が変わる。だからWi-Fiでの十分差の二回の実行は、同じテストの繰り返しではない。有線にするか、信号レベルを書き留めた固定位置にすれば、その雑音の大半は消える。各実行の開始時と終了時に信号レベルを記すだけで、二つの実行を一緒に見てよいかを示せるのが普通だ。
端末の負荷も同じ籠に入る。一つのコアで暗号化するクライアントは、リンクよりずっと早く自分の上限に当たり、バックグラウンドの同期はさらに早く当たる。実行中はCPUを見て、他に何が開いていたかを記す。電源設定もここで噛みつくことがあり、バッテリー駆動のノートPCはリンクが混むはるか前にプロセッサを制限しかねない。
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
下位層を平均するのではなく、動かさずにおく。一致する三回の実行は、別々の部屋で取った十回より多くを語る。
遅延、損失、ICMPはそれぞれ別の問いに答える
pingは固定アドレスに小さな探査を送るが、多くの網はICMPに低い優先度で応答するか、まったく無視する。返事がないことは探査について述べており、アプリケーションのパケットについてではない。負荷で往復時間が上がるのは、普通は待ち行列が埋まっているという意味で、経路が長くなったという意味ではない。
トンネルが遅延を足すか知るには、同じ目標をトンネルありとなしで比べるか、同じアクセス網から届く二つの出口を比べる。探査を何度も走らせてばらつきを見るべきで、平均は通話を使いものにならなくする変動をちょうど隠してしまう。
遅いと感じた作業に戻る
通話がまだ途切れるのに数値だけ良くなる指標は、別の何かに答えている。調査のきっかけになった作業を、会議であれファイル共有であれリモートデスクトップのセッションであれ、再実行する。数値が良くなって作業が良くならないなら、ボトルネックはテストが届かなかった場所、たとえばトンネルの向こうのサーバーや自分の側の上り回線にあった。
すべての実行を、端末、アクセス網、端点、プロトコル、目標、時刻とともに記録する。一度も接続しなかった実行は、スループット零ではなく到達性の結果なので、消さずにその札の下に残す。
次の比較の前の短い一覧
目標を固定し、なぜそれを選んだかを書き留める。経路が許すパケットサイズを記録しておけば、後での低下に説明がつく。アクセス網を同じに保ち、CPU負荷を記し、差を信じる前に三回実行する。
そのうえで変えるのは正確に一つだけにして、繰り返す。説明できる比較は、数字が大きい比較に勝る。