VPN は直接接続より速くなるのか

オフィスの回線で這うように遅い転送が、トンネル経由では速く終わることがある。追加のカプセル化を考えると不可能に見えるが、この見かけの逆説は比べる対象を間違えていることから生じる。トンネルは処理を増やす一方で、トラフィックがどのネットワーク経路を通るか、宛先がどのアドレスを見るか、そして場合によってはどのサーバーが応答するかまで変える。速度について結論を出す前に、この三つの効果を切り分ける必要がある。

トンネルが変えうる三つのこと

一つ目は経路の中継である。インターネットのルーティングは計測された遅延ではなく、事業者のポリシーと商取引関係に従うため、VPN 事業者を経由する経路は直接経路とは別のネットワークを通ることがある。混雑した交換点を避けたり、接続性の良い交換点に着地したりできるが、同じくらい簡単に悪くなることもある。

二つ目は宛先である。出口アドレスが変わると DNS の応答が変わることが多く、CDN が別のキャッシュや別のリージョンを割り当てることもある。その場合、改善の一部はトンネルではなく新しいサーバーのものだ。クライアント側で何も変えなくても、同じホスト名がより近い、あるいは負荷の低いサーバーに着地することがある。

三つ目はトランスポートの挙動である。カプセル化は実効パケットサイズを変え、損失のある中間区間を避けるトンネルでは、TCP フローが何度も後退する代わりにウィンドウを広げられることがある。どれも普遍的な高速化の仕組みではない。それぞれ観測すべき条件である。これらを切り分けることが、単なる興味を事実に変える。

変えられないこと

トンネルの中の何も、端末とネットワークの間の回線に容量を足さない。飽和した Wi-Fi チャネル、混雑したラストマイル、上限のあるモバイル契約はどちらの経路も同じように制限し、トンネル経由の速度テストがその天井を超えることはない。同じ回線がカプセル化されたパケットを運ぶのだから、カプセル化は容量を消費できても生み出すことはできない。変わるのは、その回線を出た後にパケットがどこへ行くかである。だから速いトンネルの結果には、必ず最初のホップより上流の説明がある。

サーバー側の制限も同じくらい無関心である。遠隔のホストが遅く応答するなら、良い経路は遅い応答をより効率よく届けるだけで、利用者は依然として待つ。負荷のかかった共有オリジンは、同じ瞬間にどちらの経路でも遅く見える。

経路を正しく比較する

アプリケーション、方向、時間、同時実行数を同じに保ち、変えるのは経路だけにする。各テストを同じ時間帯に複数回実行し、出口アドレスとリゾルバーの応答をスループットと並べて記録する。一度の実行は測定ではなく標本であり、一回の速いダウンロードは経路について何も語らないキャッシュヒットかもしれない。結果より先に条件を書き留める。数字は後から解釈するのが難しい。

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

リゾルバーの応答は、ほとんどの比較が省略する細部であり、同じサーバーを強制すると消える「改善」を説明する。実行ごとにアドレスが違うなら、そのテストは二つの経路ではなく二つの宛先を比べている。スループットと並べて遅延と損失を報告する。全体として速くても対話的な要求ごとに遅延を足す経路は、不満を言ったワークロードにとって良いものではない。尋ねて待つものにとっては、往復時間のほうが大容量の速度より重要だ。

違いを残す価値があるとき

承認されたトンネルが特定のワークロードを確実に改善するなら、それは正当な運用上の選択である。ワークロード、測定、使用した出口を文書化する。使える記録は、一つのホスト、トンネルが作った出口アドレス、リゾルバーの応答、そして同じ日の直接経路の同じ数値を示す。これだけあれば、次の技術者は議論をやり直す代わりに比較を再現できる。それでも事業者が何かを制限している証拠にはならず、他のアプリケーションや他の時間帯には当てはまらない。

測定の記録は設定と一緒に保管する。改善がまだ存在するかという次の問いに答えるものであり、経路が変わったのかワークロードが変わったのかを知る唯一の方法である。日付のない記録では、その問いにまったく答えられない。