TCP-over-TCP とは何ですか? TCP モードの OpenVPN はどのようにしてこの問題を回避しますか?

Question 1

私の理解では、「TCP メルトダウン」問題を解決するのは難しくありません。内部 TCP 接続の再送信タイムアウトを大きく設定するだけで済みます。

内部 TCP 接続の最小再送タイムアウトを大幅に増加させることにより、内部 TCP のタイムアウト再送メカニズムを事実上無効にしました。したがって、TCP メルトダウンの問題は回避されます。

たとえば、Linux では、ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12sOpenVPN を介して確立されたすべての内部接続の最小再送信タイムアウトを 0.2 秒から 12 秒に増やすことができます (192.168.168.1/24 が OpenVPN ネットワークセグメントであると想定します)。

上記のコマンドを OpenVPN の up イベントコールバックとして設定できます。この方法で、TCP メルトダウンの問題を簡単な方法で回避できました。

この方法を使用して、tcp-over-tcp リンクを最適化します。遅延が長く (数百ミリ秒)、パケット損失が多い回線でも、悪影響は確認されていません。

PS: 遅延、パケット損失、帯域幅が大きい回線では、内部 TCP 接続が全帯域幅を占有できるように大きなウィンドウを準備する必要があることは明らかです。

アップデート：

ここでの疑問は、なぜ TCP-over-TCP が TCP ベースの VPN に顕著な効果をもたらさないのかということです。

パケット損失がほとんどない高品質回線では、TCP メルトダウン現象は顕著ではありません。

Answer

私の理解では、「TCP メルトダウン」問題を解決するのは難しくありません。内部 TCP 接続の再送信タイムアウトを大きく設定するだけで済みます。

内部 TCP 接続の最小再送タイムアウトを大幅に増加させることにより、内部 TCP のタイムアウト再送メカニズムを事実上無効にしました。したがって、TCP メルトダウンの問題は回避されます。

たとえば、Linux では、ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12sOpenVPN を介して確立されたすべての内部接続の最小再送信タイムアウトを 0.2 秒から 12 秒に増やすことができます (192.168.168.1/24 が OpenVPN ネットワークセグメントであると想定します)。

上記のコマンドを OpenVPN の up イベントコールバックとして設定できます。この方法で、TCP メルトダウンの問題を簡単な方法で回避できました。

この方法を使用して、tcp-over-tcp リンクを最適化します。遅延が長く (数百ミリ秒)、パケット損失が多い回線でも、悪影響は確認されていません。

PS: 遅延、パケット損失、帯域幅が大きい回線では、内部 TCP 接続が全帯域幅を占有できるように大きなウィンドウを準備する必要があることは明らかです。

アップデート：

ここでの疑問は、なぜ TCP-over-TCP が TCP ベースの VPN に顕著な効果をもたらさないのかということです。

パケット損失がほとんどない高品質回線では、TCP メルトダウン現象は顕著ではありません。

Question 2

これは、TCP動作しますが、OpenVPN 自体では動作しません。ここでは長い愚痴と私の意見を述べます。

私の理解は正しいでしょうか?

大まかに言えばそうですが、内部の TCP 接続は「保護」されていません。外部でパケットがドロップされ、スループットが低下したり、遅延が増大したりする場合、内部の接続もこれによって制限され、完全なパフォーマンスを使用できないことに気付き、バックオフを開始します。

TCP-over-TCP のメルトダウンは内部のみ (つまり、ローカルバッファーのみに影響) であるように見えますが、ネットワークにも影響しますか?

サーバーへの TCP 接続は 1 つだけなので、これは特定の接続とそこに含まれるものにのみ影響します。メルトダウンが指すのは、前の回答で説明したとおりです。

ネットワークの混雑がさらに増加し、同じネットワーク上の他の接続が低下しますか?

いいえ、ただし、ここでは「ネットワーク」を定義する必要があります。インターネットへの接続が悪い場合は、パケットのドロップやその他の伝送の問題が発生することになります。クライアント <=> サーバー接続にのみ問題があるという意味であれば、VPN 以外の接続は影響を受けません。

TCP ベースの VPN はこの問題をどのように解決するのでしょうか?

サーバーへの単一の接続を使用して、その接続内でトラフィックを送信し、最善の結果を期待します。

OpenVPN にはこれに関する記事がありますが、なぜそれが実際に問題にならないのか、実際に問題になるのかについては書かれていません。

はい。TCP はパケットサイズに関して UDP よりもオーバーヘッドがはるかに大きいため、接続に 2 つの TCP ヘッダー (内部と外部) があることで常にサイズペナルティが発生します。再送信と TCP ランプアップもパフォーマンスに影響します。接続が良好 (つまり、ドロップなし、低遅延、高帯域幅) であれば、ランプアップ/バックオフ/再送信はほとんど発生せず、これに気付くことはありません。接続が悪い場合は、最初の答えが影響します。外部接続がランプダウンし、これが内部トラフィックに影響してランプダウンし、パケットが順序どおりに進まなくなり再送信されるなど、トンネルのパフォーマンスに確実に影響します。

長い答えは長いです。私以外の誰かにとっても、これが意味を成すものであることを願っています。

Answer