TCP-over-TCPのパフォーマンスは、TCP単独（2014））よりも大幅に低下していますか？
多くの管理者は、ServerFaultやその他の場所で、TCP-over-TCPのアイデアがどれほどひどいかを継続します。 VPNで。 TCP Meltdownでない場合、わずかなパケット損失でも少なくとも深刻なスループットの低下に苦しむことになるため、TCP-over-TCPは厳密に回避する必要があります。 true、たとえば2001年 この記事 が作成されたが、まだ参照されている。
しかし、それ以来、テクノロジーとプロトコルに大きな進歩がありました。今日では、ほぼすべての場所に「選択的ACK」が実装されており、ムーアの法則により、はるかに多くのメモリが提供され、Gbitアップリンク用に最適化されたTCPバッファが大きくなりました。また、パケット損失もはるかに少ない最近の非無線リンクの問題これにより、TCP-over-TCPの問題が大幅に軽減されますね。
たとえば、次のような実際のシナリオがあることに注意してください。 TCPベースのVPNは、UDP/ESPベースのVPNよりも実装と操作が簡単です（以下を参照）。したがって、私の質問：
TCP-over-TCPのパフォーマンスがどのような状況（リンクパケットの損失と待機時間）で大幅に悪化するかTCP単独、SACKを想定）サポートと適切なサイズのTCP両端のバッファ？
（外部接続）パケット損失/待機時間と（内部接続）スループット/ジッターの相関関係を示すいくつかの測定値を確認してください-TCP-over-TCPの場合、およびTCP私は この興味深い記事 を見つけましたが、それは遅延のみを考慮しており、（外部の）パケット損失に対処していないようです。
また、TCPとTCP-overの間のパフォーマンスギャップを狭めるために推奨される設定（TCPオプション、バッファー設定、MTU/MSSの削減など））がありますか？ -TCP？
更新：私たちの理論的根拠。
この質問は、いくつかの実際のシナリオでは依然として非常に関連があります。例えば。センサーデータを収集し、VPN経由でプラットフォームにフィードする大規模な建物に組み込みデバイスを展開します。私たちが直面している問題は、ファイアウォールと不適切に設定されたアップリンクであり、私たちの管理下になく、消極的なIT部門と組み合わされています。議論される詳細な例を参照してください ここ 。
そのような多くの場合、非TCPからTCPベースのVPNに切り替える（私たちのようにOpenVPNを使用すれば非常に簡単です）のは簡単な修正であり、困難な指先の戦いを回避できます。例えば。しばしばTCPポート443は一般に許可されます（少なくともプロキシ経由で）、またはTCPのMSSオプションを減らすだけでパスMTUの問題を克服できます。
どのような状況でTCPベースのVPNを実行可能な代替と見なすことができるかを知っておくとよいでしょう。そのため、どちらのオプションの長所と短所よりも情報に基づいた決定を下すことができます。たとえば、非無線リンクではTCP-VPNが問題ないことはわかっていますが、3Gアップリンクでかなりのパケット損失と高遅延のリモートクライアントを共有しています-TCP-VPNはそこでどのように機能しますか？
タイトルと中心的な質問をそれに応じて改善しようとしました。私はそれが理にかなっていると思います。
あなたが見せるよりも実際にはもっと議論されていると思います。確かに古い、関連するLinux FAQがあります： http://www.tldp.org/HOWTO/VPN-HOWTO/
私はPPP-over-ssh-over-ADSLを12年以上使用してきましたが、失敗することはありませんでした。そのため、私の経験から、運命論者はおそらく大げさだと言っても過言ではありません。 TCP over TCPは、RTC接続、衛星リンク、および非常に低いスループットまたは非常に長い遅延ですが、ほとんどの場合これを使用します機能します。
さて、本当の質問は次のとおりです。なぜTCP over TCPを使用するのか？私がPPP-over-sshをセットアップしたときの主な理由は、当時はそれがクイックVPNを構築するのにはるかに最も簡単な方法だったからです;それから、私はまったくの怠惰からそれを使いました。
今日では、OpenVPNやIPSec VPNなどの設定が簡単で実用的なツールが存在するため、このTCP-over-TCPの問題に煩わされる必要はありません。