同じトンネルなのに2つのVPN速度テストが一致しない理由
新しい出口はテストサーバーを変え、遅いスタートはスコアを変える。宛先を固定し、ストリーム数を揃え、CPUコストと回線容量を分けて考える。
二回の実行、一本のトンネル、そして数値は三倍違う。その間トンネルは変わっていない。変わったのは測定のほうだ。見かけ上の位置からサーバーを選ぶテストサイト、一つの遅いスタートがパイプを満たすのか六つが満たすのかを決めるストリーム数、そして経路がまともに使われ始める前に終わってしまうほど短い測定時間。速度テストは間違っていないが、人々が求める問いより狭い問いに答えている。
新しい出口アドレスはテストの宛先を変える
ほとんどのテストサイトは測定サーバーを自動で選び、その選択はあなたの接続がどこから来ているように見えるかにも一部左右される。トンネルをオンにすれば見かけの国が変わり、選ばれるサーバーも変わり、比較は二つの異なるホストへの二つの異なる経路にまたがることになる。
その結果はVPNの測定ではまったくない。自分で選んでいないサーバーへの経路の測定であり、二回の差はトンネルがしたことよりも、そのサーバーのピアリングに支配されうる。
他の何かを変える前に宛先を固定する。信頼できるツールはどれもサーバーを明示的に選べるし、選べない場合でも結果ページには使われたサーバーが書かれていることが多く、二回が比較できないことに気づくには十分だ。サイトが何を見たのかを、その選択を信じる前に確認する。
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'
実行の間に国が変わっていれば、テストがその後選んだものもすべて変わっている。観測した出口を各結果の横に書けば、混乱のほとんどは消える。
遅いスタートは短いテストの大半が終わってから終わる
TCP接続は回線速度で始まらない。小さな輻輳ウィンドウから始まり、往復ごとにおおよそ倍になり、経路の容量に達するのは数回の往復のあとだ。遅延の大きい経路での十秒のテストは、その立ち上がりの間に寿命の相当部分を使い切ることがある。
だから遅延の大きいトンネルは短いテストで本来より低いスコアになり、だからこそ長い実行は設定を何も変えずに高い数値を報告することが多い。RFC 6349のスループット枠組みはこれを明示的に扱っており、本気の測定が定常状態に達するまで長く走るのはそのためだ。衛星経路での五秒の実行は道路ではなく加速装置を測っている。
一つの数値を信じるのではなく、接続の段階を見る。Curlは各段階を別々に報告するので、時間がハンドシェイクに使われているのか、立ち上がりに使われているのか、転送に使われているのかがわかる。
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.bin
同じ宛先に対して二回続けて実行する。二回目がずっと速ければ、測っていたのは経路ではなく立ち上がりであり、一回目だけを使った比較は疑わしい。
一本のストリームと六本のストリームは別のものを測る
単一のTCPストリームは、飛ばし続けられるウィンドウで制限され、それはおおよそ往復時間に速度を掛けたものだ。長い経路ではその積が一本のストリームが使う量を超えるので、一本のダウンロードは存在する容量を低く報告する。六本の並列ストリームがその隙間を埋め、より大きな数値を出す。
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net
どちらの数値も正しい。単一ストリームの数値は一本のダウンロードがどうなるかを示し、それは通常ブラウザのタブが得るものだ。並列の数値は経路が全体として運べる量を示し、それはトレントや分割ダウンロードが使えるものだ。片方をもう片方のように引用することが、健全なトンネルを理由もなく交換してしまう道だ。
並列の結果を単一ストリームの結果と比べるのは、VPNが速度を半分にしたと人々が結論づける最も一般的な道だ。方法を揃えてから比較する。三番目のコマンドのトレースは欠けている文脈を補う。ジッターの大きい経路はどちらのモードでも不安定な結果を出し、ストリーム数をいくら増やしてもそれは直らない。
暗号化はプロセッサ時間を、カプセル化はバイトを消費する
回線がどれだけ速くても、すべてのパケットで二つの仕組みが動く。暗号化はバイトあたりCPUを消費し、カプセル化は回線が運ばなければならないヘッダーのバイトを加える。どちらも天井として現れ、症状は異なる。
CPUの天井は高原として現れる。ストリームをいくら足してもスループットは上がらなくなり、回線が暇なのにマシンのプロセッサは忙しい。小型ルーターやスマートフォンではこれが実際の限界であることが多く、だから速い回線でも控えめなトンネルしか出ないことがある。
バイトのコストは小さいが一定だ。余分なヘッダーは一パケットあたりのペイロードを減らし、最大転送単位が固定の経路では、大きな転送で平均が遅いのではなく停止として現れるフラグメンテーションやブラックホールを引き起こすこともある。
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
この三つはよく混同される。利用者がどれも「VPNが遅い」と表現するからだ。より大きなマシンに反応するのは一つ目だけで、より小さなMTUに反応するのは二つ目だけで、キュー管理に反応するのは三つ目だけだ。
方法を記録に残す
残す価値のある結果は、端末、アクセス網、出口、測定サーバー、方向、ストリーム数、時間を名指しする。それらがなければ二つの数値は比較できず、数値を一つだけ載せたチケットは実のところ気分でしかない。
悪い実行も残す。一つの出口が毎回停止を起こす系列は平均よりはるかに情報が多く、停止こそが平均の隠すものだ。
そして実際に気にしているものをテストする。大きなダウンロードが目的ならファイルを落とす。通話が目的なら、アイドル時のスループットではなく負荷時の遅延を測る。トンネルは速度テストで良い点数を取りながら、どの会議も聞き取れなくすることがあるのだから。