TCP-over-TCPの課税：アーキテクチャの解剖

あなたのトンネルが遅いのはISPのせいではありません。パケットが「ダブル再送」ループにハマっているからです。システムエンジニアにとって、高速な光ファイバーはTCPストリームをもう一つのTCPストリームに包むと、ダイヤルアップ接続のように感じられます。この現象はネットワーキング界ではTCP-over-TCP Tax（またはより劇的にTCPメルトダウン）として知られ、古典的なアーキテクチャのアンチパターンです。

この解剖では、SSHトンネル、OpenVPN-TCP、その他のネストされたTCPアーキテクチャがわずかなパケット損失でも失敗する理由と、WireGuardやQUICのような現代の代替手段が「遅い」トンネルの唯一の解決策である理由を数学的・アルゴリズム的に解説します。

1. カプセル化の解剖学

課税の理解にはまずスタックを見てみましょう。SSHトンネルやTCPベースのVPNを実行するとき、単にデータを送るだけでなく、Inner TCPの状態機械全体をOuter TCPの状態機械にカプセル化しています。

標準の非トンネル接続では、TCPはフロー制御と信頼性をIP層上で直接管理します（これは「ベストエフォート」で信頼性は低いです）。しかし、トンネル内では：

Inner TCP（アプリケーション層）はリモートホストと通信していると思っています。シーケンス番号、ACK、輻輳ウィンドウ（cwnd）を管理します。
Outer TCP（トンネル）は、内側のパケットを生のペイロードとして扱います。独自のシーケンス番号、ACK、cwndを追加します。

完璧なネットワークではこれが機能しますが、インターネットは決して完璧ではありません。

2. 数学的解剖：なぜ1%の損失が90%の遅延に感じるのか

「課税」の核心は、2つの層がパケット損失にどう反応するかにあります。単一層のTCP接続では、スループットはおおよそMathis方程式によって支配されます：

Throughput ≤ MSS / (RTT × √p)

ここで： - MSS：最大セグメントサイズ - RTT：往復時間 - p：パケット損失確率

TCPをネストすると、損失確率pは線形にスループットを減らすだけでなく、2つの独立したタイマー間の同期衝突を引き起こします。

ダブルリトランスミッションループ

物理線上でパケットが失われたと想像してください：

Outer TCPの反応：トンネルは失われたパケットを検知し、すべてを停止して再送します。cwndは半分に減少します。
Inner TCPの視点：トンネルが再送中の間、アプリケーションのパケットは「スタック」し、バッファ内に留まります。Inner TCPはRTTの大きなスパイクを認識します。
メルトダウン：Outer TCPの再送に成功するまでの時間が、Inner TCPのRTO（再送タイムアウト）より長い場合、Inner TCPもパケット損失と判断し、自身の再送をトリガーします。

これにより、2層が同じデータを送信し続ける状態になり、トンネルはすでに輻輳状態です。アプリケーションは負荷を倍増させ、バッファは冗長な再送で満杯になり、実効RTTは秒単位に膨れ上がります。

最近の研究によると、内側と外側のTCPの制御ループはお互いに破壊的に干渉しあい、外側のTCPが接続の健全性を隠すことで、わずかなパケット損失が壊滅的なパフォーマンス低下に変わるのです。

3. ヘッド・オブ・ライン（HoL）ブロッキング：シーケンシャルな牢獄

TCPは信頼性のあるバイトストリームプロトコルです。送信された順番通りにデータを受け取ることを保証します。これが最大の強みであり、トンネル内では致命的な欠点です。

シーケンシャルキュー

パケット#1が失われても、パケット#2、#3、#4が安全に到着した場合、TCPスタックはパケット#2–4をアプリケーションに渡せません。パケット#1が再送されて到着するまで、バッファに留まります。

SSHトンネルではこの効果はグローバルです。複数のストリーム（例：データベース接続とWebリクエスト）を一つのSSHトンネルで多重化している場合、データベースストリームのパケット1つが失われると、Webリクエストの完了がブロックされます。たとえWebパケットが完璧に到着していてもです。

待ち時間の数学

n個の未送信パケットと損失率pのストリームでHoLブロッキングによる遅延確率はおおよそ1 - (1-p)^nです。ウィンドウサイズnが大きくなると、遅延の可能性は100%に近づきます。特に高帯域遅延積を満たすためにウィンドウサイズが大きくなる現代の環境では、問題はさらに顕著です。

4. 実世界の影響：最新のベンチマークとケーススタディ

WireGuardと従来のVPN

最近の詳細な研究では、TCP-over-TCPの課税の証拠が示されています。VMware環境では、WireGuardはOpenVPNの110.34 Mbpsに対し、210.64 MbpsのTCPスループットを示し、パケット損失も12.35%と47.01%と大きく異なります。

フィールドテストではさらに劇的な結果が得られています。実用的なベンチマーク条件下で、WireGuardは平均3.3倍高速で、TCP-over-TCPアーキテクチャのコストを実証しています。

スケールでのパフォーマンス

現代のVPNソリューションは大きく進化しています。ギガビットネットワーク上で、Netmakerは平均7.88 Gbits/secのデータ転送速度を達成し、カーネルのWireGuard（7.89 Gbits/sec）とほぼ同等です。このネイティブに近いパフォーマンスは、WireGuardがTCP-over-TCPの課税を完全に回避しているためです。

さらに、困難なネットワーク条件下でもパフォーマンス差は拡大します。WireGuardは、約4,000行のコードと、すべてのプロセッサで効率的に動作するChaCha20-Poly1305暗号化、カーネル統合によるパケット処理の高速化により、その性能を実現しています。

実世界の展開結果

消費者向けハードウェアでもWireGuardの性能は印象的です。最新のルーターのベンチマークでは、ミッドレンジハードウェアでも1,080 Mbps近くのリンク速度を達成しています。

5. 「メルトダウン」と輻輳制御の衝突

CUBICやNewRenoのようなTCPアルゴリズムは、帯域幅を探るためにドロップを待ちます。これらのアルゴリズムがネストされると、同じリソースを争います：

Outer TCPはパイプを満たそうとします。
Inner TCPも同じく満たそうとします。
ドロップが起きると、両者はバックオフします。

Outer TCPがInner TCPのACKをバッファリングしているため、Inner TCPのRTT推定は「ノイジー」になり、帯域遅延積（BDP）を正確に計算できなくなります。

この「ACK圧縮」は、内側の接続が安定した高速状態に到達するのを妨げます。この設計は、TCP接続の積み重ねに失敗しやすく、TCPメルトダウンと呼ばれるネットワークの遅延低下を引き起こします。これは、遅い外側の接続が上位層に再送を積み重ねさせ、下層が処理できる以上の負荷をかけるときに起こります。

6. MTU/MSSの「サイレントキラー」

パケット損失がゼロでも、「フラグメンテーション課税」を支払っている可能性があります。

標準のEthernetフレームは1500バイトです。SSHやVPNはヘッダー（暗号化やカプセル化）を追加します。結果のパケットが1520バイトの場合、2つに分割される必要があります。

フラグメンテーション： - パケット数が倍増 - CPUの割り込みオーバーヘッドも倍増 - 1つのフラグメントが失われると、元のパケット全体が破棄される

SSHトンネルでは、Inner TCPセグメントがトンネルのペイロードに収まるように、最大セグメントサイズ（MSS）を調整（クランプ）する必要があります。

例：IPTables MSSクランピング

# フラグメンテーションを防ぐためにMSSをPath MTUにクランプ
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

7. 現代の解決策：UDPベースのカプセル化

エンジニアリングのコンセンサスは明確です：トンネルはステートレスであるべきです。

なぜWireGuardが勝つのか

WireGuardはUDPを使用します。暗号化されたパケットが失われても、WireGuardは気にしません。再送も輻輳ウィンドウも持ちません。責任はInner TCPに戻します。

利点：

ダブルリトランスミッションなし：回復はアプリケーション層だけが担当
HoLブロッキングなし：Packet #2はPacket #1が失われても復号・配信可能
カーネル統合：WireGuardはLinuxカーネル（バージョン5.6以降）に組み込まれており、ユーザースペースのSSHトンネルのオーバーヘッドを回避

UDPは自体では再送しないため、UDPの場合、失われたパケットの再送はInner TCPだけが行い、積み重なることなく問題を回避します。

なぜQUIC（HTTP/3）が未来なのか

QUICは、UDPの上に「より賢い」TCPを構築します。マルチプレックスストリームをHoLブロッキングなしでサポートします。QUICトンネル内のストリームの一つがパケットを失っても、他のストリームは影響を受けません。

QUICのパフォーマンス革新

実世界の展開例では、QUICの利点が示されています：

Googleの論文によると、QUICの基本メカニズムは、Google検索結果の読み込み時間を平均8%、モバイルでは3.6%、最も遅い1%のユーザーでは最大16%の高速化をもたらしました。

動画ストリーミングでは、YouTubeの動画再生において最大20%のバッファリング削減が観測されています。

大手CDNプロバイダーもこれらの効果を規模で検証しています。ヨーロッパのサッカーライブストリーミングイベントでは、HTTP/3接続の約69%が5 Mbps以上のスループットを達成し、HTTP/2の56%を上回っています。

接続確立速度

QUICを使うことで、HTTP/3はHTTP/2より33%高速に接続を確立できます。トランスポートとTLSのハンドシェイクを一つにまとめることで、往復回数を削減しています。

2024-2025年のHTTP/3採用

このプロトコルは実験段階から主流へと移行しています。2024-2025年までに、Chrome、Firefox、Safari、Edgeなどの主要ブラウザはデフォルトでHTTP/3をサポートし、ウェブリクエストの数十パーセントがHTTP/3を使用しています。

主要なインターネット企業も積極的に採用しています。GoogleやMetaなどの大手はすでにHTTP/3を大量に利用しており、現在のインターネットトラフィックの一部を占めています。

実世界のHTTP/3パフォーマンス

包括的なベンチマークは、一貫した改善を示しています。HTTP/3は、すべてのテストケースで前身より高速であり、その多重化の特性により、どこにもHead-of-lineブロッキングは発生していません。

モバイルユーザーには特に大きな恩恵があります。2025年のAkamaiレポートでは、HTTP/3がモバイルネットワークのレイテンシを30%削減し、従来のTCPの課題を解決しています。

なぜ大手プラットフォームは、よりコストのかかるQUIC/HTTP/3の展開に投資しているのか？QUICとHTTP/3は、より多くの暗号化処理を必要とし、CPUとメモリのコストがTCPやHTTP/2より高いですが、その利益が十分に上回っています。

このため、cloudflared（Cloudflare Tunnels）などのツールは、デフォルトのトランスポートとしてQUICに移行しています。

8. エンジニアのチェックリスト：課税を避ける

あなたのトンネルがFiber接続にもかかわらず遅いと感じる場合、次のアーキテクチャの解剖を行ってください：

1. TCPベースのVPNの使用をやめる

WireGuardやTailscaleに切り替えましょう。どうしてもOpenVPNを使う場合は、トランスポートをTCPからUDPに変更してください。

なぜ重要か：信頼性の高いプロトコルと考えられるTCP VPNも、実際にはラインがほぼ完璧でないときにしか信頼できません。完全に壊れる前に、遅延を増やしスループットを低下させる重複再送が発生します。

2. SSHトンネルの監査

開発用途ならssh -Lでも問題ありませんが、本番のデータ移動にはボトルネックです。UDPやQUICベースのプロキシを検討してください。

3. MTUの確認

以下のコマンドで、フラグメントせずに通過できる最大パケットサイズを調べます：

ping -M do -s 1472 <宛先>

トンネルがアクティブな場合、この値は低くなります（通常1420や1380）。適宜MTU設定を調整してください。

4. バッファブローの確認

ネストされたTCPはバッファブローを悪化させます。fq_codelやCAKEをキューイングディシプリン（qdisc）として設定し、遅延スパイクを抑制します：

# CAKE qdiscをトンネルインターフェースに設定
tc qdisc replace dev wg0 root cake bandwidth 100mbit

5. 最新の代替案の検討

WebアプリケーションにはHTTP/3の利用を推奨します。カスタムトンネリングには、QUICベースのソリューションを検討し、SSHやOpenVPN-TCPに頼らない設計を心がけてください。

9. トレードオフの理解

TCP-over-TCPがまだ使われるケース

すべての欠点にもかかわらず、TCP-over-TCPトンネルは特定のシナリオで存続しています：

ファイアウォール越え：一部の企業ネットワークはポート443のアウトバウンドTCPのみ許可しています。
レガシーシステム：既存インフラがUDPベースのプロトコルをサポートしていない場合。
シンプルさ：SSHトンネルは普及しており、追加ソフトウェア不要です。

しかし、最近の進展によりこれらの懸念は解消されつつあります。TCP-over-MPTCPの問題を解決する前に、標準的な推奨は明確です：内側のVPNがTCPの場合は、外側のトンネルをUDPベースにして、メルトダウン問題を回避しましょう。

パフォーマンスの現実

TCP-over-TCPの失敗条件を理解することは、システム設計にとって重要です：

TCPトンネルは、エンドホスト間で送信されたパケットを一つのTCP接続として集約・転送しますが、ほとんどのアプリケーションはTCPを使用しているため、2つのTCP輻輳制御が同時に動作し、干渉します。

結果として、TCPメルトダウンは、外側のTCPの輻輳ウィンドウが著しく縮小し、再送タイムアウトが膨らみ、送信バッファが満杯になる状態を引き起こし、内側のTCPが書き込みできず、ACKも送信されなくなります。

10. 未来展望：TCP後のインターネット

TCPからUDPベースのプロトコルへの移行は、インターネットの輸送の根本的な再考を意味します：

QUICのアーキテクチャ革新

QUICは、Transport Layer Security (TLS)と密接に連携しています。QUICでは、TLSが大部分のプロトコル自体を暗号化し、TCPのようにパケット番号やコネクション終了信号などのメタデータが中間装置に見えなくなります。これにより、セキュリティとパフォーマンスが向上し、接続確立の遅延も削減されます。

ストリームのマルチプレックス化

HTTPはストリームを知っていますが、TCPはそうではありません。TCPでは、異なるストリームのフレームは順序付きセグメントとして送信され、損失した場合はタイムアウト後に再送され、他のセグメントをブロックします。QUICはこれを解決し、ストリームをトランスポート層の第一級の概念にします。これにより、HTTP/2 over TCPのHead-of-lineブロッキングを排除します。

モバイルと不安定なネットワーク

QUICは、ネットワークの切り替えをまたいで接続を維持できます。TCPは同じエンドポイント（IPとポート）を必要としますが、QUICはこれを不要にし、WiFiとモバイルデータ間のシームレスなハンドオフを可能にします。これがTCPが設計されていなかったシナリオです。

結論

TCP-over-TCPの課税は、信頼性の二重の利益相反です。あまりに「信頼性」を追求すると、トンネルは使い物にならなくなります。

証拠は圧倒的です： - WireGuardはTCPベースのVPNより2-3倍高速 - HTTP/3は実世界で明確な改善をもたらす - 主要なインターネットプラットフォームは、コストが高くてもQUICを採用 - 最新のカーネルにはWireGuardがネイティブに組み込まれている

エンジニアリングの世界では、最速の道は、パケットを手放すべきときに手放すことを知っている道です。UDPを使ったトンネルを選び、TCPはアプリケーション層で処理させ、課税をやめましょう。

インターネット輸送の未来は明確です：UDPベースのステートレストンネル、WireGuardやQUICの採用です。ネットワークが高速化・複雑化する中、TCP-over-TCP問題のアーキテクチャ的教訓はますます重要になります。プロトコルを賢く選び、トレードオフを理解し、ネットワークの現実に沿ったシステムを構築しましょう。

追加リソース

自身の設定をテスト

VPNやトンネルのパフォーマンスをベンチマークするには：

# iperf3でスループットをテスト
iperf3 -c <サーバー> -t 30 -P 4

# レイテンシをテスト
ping -c 100 <宛先>

# パケット損失を確認
mtr -c 100 <宛先>

結果をトンネル有無で比較し、パフォーマンスへの影響を定量化してください。