高遅延でWireGuard VPNの速度が低下する理由

はじめに

海外からGL.iNetルーターのWireGuard VPNサーバーに接続すると、自宅の対称型ギガビット回線や滞在先（例：Airbnb）の同等に高速な回線と比べて、インターネット速度が大幅に低下することに驚くユーザーは少なくありません。通常は、サーバー側またはクライアント側のISPに原因がある場合があります。しかし、遅延はスループット、つまりダウンロード／アップロード速度に非常に大きな実際の影響を与えるにもかかわらず、見落とされがちな要因です。本記事では、遅延（すなわちpingの結果）が大きい場合に速度が低下する理由を説明し、現実的な期待値をお伝えします。

遅延とは何か、なぜ重要なのか

遅延とは、データがデバイスからVPNサーバーへ到達し、戻ってくるまでにかかる時間です。一般にミリ秒（ms）で測定されます。たとえば、ベトナムにあるGL.iNetルーターからテキサス州のVPNサーバーに接続する場合、往復時間（RTT）は容易に250-300 msになります。

技術的にはインターネット速度が「高速」でも、高遅延は実際のダウンロードおよびアップロード性能を著しく制限する可能性があります。特にTCPベースのプロトコル（HTTPs、ファイル転送、多くのアプリなど）で顕著です。WireGuard自体はUDPを使用しますが、VPNトンネルを通過するトラフィック（Webトラフィック、ストリーミングなど）は多くの場合TCPベースです。そのTCPデータはWireGuardによってUDPでラップされ、インターネット経由で送信されます。

TCPのボトルネック：スループットは遅延に左右される

TCPパフォーマンスを左右する重要な式は次のとおりです。

TCP Window Size = Throughput x RTT
まず、いくつかの用語を説明します。

• TCP Window Sizeは、確認応答が必要になる前に、システムが「転送中」（未確認）の状態にしておけるデータ量です。
• Throughputは実効速度、つまり1秒あたりに送受信できるデータ量です。
• RTT（Round-Trip Time）は、パケットを送信してから受信するまでの遅延です。

GL.iNet Subredditメンバーの実例

ベトナムに滞在し、GL.iNet Flint 2ルーターで稼働するテキサス州の自宅のWireGuard VPNサーバーに接続しているとします。

• サーバー所在地：米国テキサス州
  
  • ローカル速度（対称型光回線） 700 Mbps download / 940 Mbps upload
• クライアント所在地：ベトナム
  
  • ローカル速度（VPNなし）：455 Mbps download / 634 Mbps upload
    
  • ローカル速度（WireGuard VPNクライアント有効時）：47.3 Mbps download / 12.1 Mbps upload, 288 ms ping

まず、あらゆるネットワーク接続に共通する制約をいくつか確認しましょう。

1. ISPの性能差と近隣地域での混雑：速度は100 Mbps単位で変動することがあります。
2. Wi-Fi性能：物理的な環境、他の無線機器からの干渉、クライアントデバイスの性能、Wi-Fiに本質的に備わる半二重特性（全二重のEthernetとは対照的）によって大きく変動します。
   • 現実的なWi-Fi性能について詳しくは、こちらをお読みください：https://www.wiisfi.com/。1つ目の制約は制御できません。2つ目の制約もほとんど制御できませんが、可能な限り有線のEthernet接続を使用することで、取り除ける可能性があります。

帯域幅遅延積

一見すると、クライアント側のVPN速度テスト結果は期待外れに見えるかもしれません。しかし、この遅延を考慮すると、実際にはかなり良好な結果です。先ほどの式を使って説明します。
TCP Window Size = 47.3 Mbps x 0.288 seconds
　 　 　 　    = 13.6 Mb, or ~1.7 MB

1.7 MBのTCPウィンドウサイズは実際にはかなり大きく、288 msの遅延がある接続でこれを実現していることは、TCPが妥当に機能していることを意味します。しかし、元のTCPウィンドウサイズフィールドは65,535 bytes（約64 KB）に制限されているのに、これはどのように可能なのでしょうか。

パフォーマンスを向上させるTCP Window Scaling

答えは、現代の高帯域幅・高遅延ネットワークをサポートするために導入されたTCP Window Scalingという機能にあります。Microsoftがこの記事で説明しているように、TCPウィンドウサイズフィールドは16ビットしかないため、スケーリング前のウィンドウは65,535 bytesに制限されます。これを克服するため、RFC 7323でTCP window scaleオプションが導入され、ウィンドウサイズを最大14ビット左シフトできるようになり、最大ウィンドウサイズは実質的に1 GBまで増加しました。スケーリング係数はTCPの3ウェイハンドシェイク時にネゴシエーションされます。有効になると、エンドポイントは元のウィンドウサイズを乗算できます。クライアントデバイスのOSにある輻輳制御アルゴリズムは、適切なウィンドウサイズのスケーリングを決定するために常に動作しています。Microsoft Windows OSの場合のように、ウィンドウサイズの「自動調整」がダウンロードスループットの最大化に特に不十分なこともあります。

OSがネゴシエーションしたTCPウィンドウサイズと、遅延がスループットに与える影響の例 出典：duckware.com/blog/how-windows-is-killing-internet-download-speeds

TCPウィンドウサイズを増やし続けられない理由

TCPウィンドウサイズは、最終的には利用可能な帯域幅と往復時間に依存します。ただし、スループットを上げるためにウィンドウサイズを大きくすればよい、というほど単純ではありません。ある程度を超えると、より大きなウィンドウサイズは送信側と受信側の双方でより多くのメモリと処理能力を必要とします。その結果、デバイスやネットワークの負荷が過大になり、パケット損失の増加や性能低下につながる可能性があります。

したがって、前述のシナリオでは、約1.7 MBのTCPウィンドウサイズは実際にはごく標準的であり、高遅延を考慮すれば良好な接続性能を示しています。約2 MBという一般的な上限は、多くの現代的なシステムにとって、スループットとリソース使用量のバランスを取る実用的な上限として機能する場合があります。2 MBのウィンドウと288 msの遅延では、理論上の最大スループットは約55.5 Mbpsとなります。これは、両端（サーバーとクライアント）の生のインターネット接続がはるかに高速であっても、これを超える速度の実現が難しくなる理由を説明します。先ほどの式の変数をスループットについて解くように並べ替えると、80 msの遅延と2 MBのウィンドウサイズでは、理論上約200 Mbpsを実現できることが分かります。残念ながら、物理的距離（Texas <-> Vietnam）のため、物理法則によりこの遅延値を達成することはできません。

まとめ

この記事が、海外でWireGuard VPNを使用する際のダウンロード／アップロード速度について、より現実的な期待値を持つ助けになれば幸いです。最後に、ルーターは多数のTCPセッションを同時に処理していることを忘れないでください。人気のGL.iNet Flint 2は十分な1 GBのDDR4 RAMを搭載していますが、そのFlint 2に接続するクライアント側ルーターはRAMがはるかに少ない可能性があり、TCPウィンドウサイズのスケーリングにおける制約要因となることがあります。

WireGuard VPNの設定に関するトラブルシューティングと理解に役立つ詳細やヒントについては、次のGL.iNetフォーラム投稿をご覧ください：https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

GL.iNetホームルーターのご紹介