TCP-over-TCPのパフォーマンスは、どのような状況でTCP単独よりも著しく悪いですか（2014）？
多くの管理者は、ServerFaultやその他の場所で、たとえばVPNのようなTCP-over-TCPのアイデアがどれほど悪いかを永続させています。TCPのメルトダウンでなければ、わずかなパケット損失でも少なくとも深刻なスループット低下に悩まされるため、TCP-over-TCPは厳密に回避する必要があります。そして、おそらく2001年にこの記事が書かれた2001年はまだ言及されているが、それはおそらくすべて真実だった。 しかし、それ以来、テクノロジーとプロトコルに大きな進歩が見られました。最近では、ほぼすべての場所で「選択的ACK」が実装されており、ムーアの法則により非常に多くのメモリが提供されており、Gbitアップリンク用に最適化された大きなTCPバッファが付属しています。また、最近では、非無線リンクでのパケット損失の問題ははるかに少なくなっています。これはすべて、TCP-over-TCPの問題を大幅に軽減するはずです。 たとえば、TCPベースのVPNは、UDP / ESPベースのVPNよりも実装および操作が簡単な現実のシナリオがあることに注意してください（以下を参照）。したがって、私の質問： TCP-over-TCPのパフォーマンスは、どのような状況（リンクパケットの損失と遅延）で、SACKサポートと両端の適切なサイズのTCPバッファーを想定して、TCP単独よりも著しく悪化しますか？ TCP-over-TCPおよびTCPのみの場合、（外部接続）パケット損失/遅延と（内部接続）スループット/ジッターとの相関関係を示す測定値を参照してください。この興味深い記事を見つけましたが、それはレイテンシーのみに関心があり、（外部）パケット損失には対処していないようです。 また、TCPとTCP-over-TCPのパフォーマンスのギャップを狭めるための推奨設定（TCPオプション、バッファー設定、MTU / MSSの削減など）はありますか？ 更新：根拠。 この質問は、実際のシナリオでは依然として非常に重要です。たとえば、センサーデータを収集し、それをVPN経由でプラットフォームに送信する大規模な建物に組み込みデバイスを展開します。私たちが直面している問題は、ファイアウォールと不適切に構成されたアップリンクであり、私たちの管理下になく、消極的なIT部門と組み合わされています。ここで説明されている詳細な例を参照してください。 そのような場合の多くでは、非TCPからTCPベースのVPNへの切り替え（私たちのようなOpenVPNを使用している場合は非常に簡単です）は、困難な指先の戦いを回避するための簡単な修正です。たとえば、多くの場合、TCPポート443は一般に許可されます（少なくともプロキシ経由）。または、TCPのMSSオプションを減らすだけでPath-MTUの問題を克服できます。 どのような状況下でTCPベースのVPNが実行可能な代替手段と見なされるかを知っておくとよいでしょう。そのため、いずれかのオプションの長所と短所を上回る情報に基づいた決定を下すことができます。たとえば、非無線リンクではTCP-VPNは問題ないことはわかっていますが、3Gアップリンク上のリモートクライアントはかなりの割合でパケット損失が大きく、待ち時間が長くなっています-TCP-VPNはどのように機能しますか？ それに応じてタイトルと中心的な質問を改善しようとしました。理にかなっているといいのですが。