许多pipe理员在ServerFault和其他地方继续保持TCP-over-TCP的想法，例如在VPN中。 即使是最轻微的数据包丢失，如果不是TCP崩溃，至less会造成吞吐量严重下降，因此严格要避免使用TCP-over-TCP。 而这可能曾经是真实的，例如2001年，当这篇文章写出来，仍然提到。
但从那以后，我们看到了技术和协议方面的重大进展。 现在我们几乎在所有地方都实现了“select性确认”，摩尔定律给了我们更多的内存，而且还有大量针对Gbit上行链路优化的TCP缓冲区。 此外，在非无线电链路上，丢包现象也less得多。 所有这些都应该显着缓解TCP-over-TCP问题，不是吗？
请注意，现实世界中，基于TCP的VPN比基于UDP / ESP的VPN更容易实现和运行（请参阅下面的内容）。 所以我的问题是：
在什么情况下（链接数据包丢失和延迟）是TCP-over-TCP单独执行显着更坏的TCP，假定SACK支持和两端的大小合适的TCP缓冲区？
这将是非常好的，所以看到一些测量结果显示TCP-over-TCP和TCP本身的（外部连接）数据包丢失/延迟和（内部连接）吞吐量/抖动之间的相关性。 我发现这篇有趣的文章 ，但它似乎只关心延迟，而不是解决（外部）数据包丢失。
另外：是否有build议的设置（例如，TCP选项，缓冲区设置，减lessMTU / MSS等）来缩小TCP和TCP-over-TCP之间的性能差距？
更新：我们的理由。
这个问题在现实世界中仍然非常重要。 例如，我们将embedded式设备部署在收集传感器数据的大型build筑物中，并通过VPN将其馈入我们的平台。 我们面临的问题是防火墙和不正确configuration的上行链路，我们不在我们的控制之下，加上不情愿的IT部门。 请参阅此处讨论的详细示例。
在很多这样的情况下，从非TCP切换到基于TCP的VPN（如果您像我们一样使用OpenVPN，非常简单）是一个快速修复，可以让我们避开艰难的指向战争。 例如通常TCP端口443通常是允许的（至less通过代理），或者我们可以通过简单地减lessTCP的MSS选项来克服Path-MTU问题。
很高兴知道在什么情况下基于TCP的VPN可以被认为是一个可行的select，所以我们可以做出明智的决定，超过这两种select的利弊。 例如，我们知道在非无线链路上TCP-VPN对我们来说是好的，但是我们在3G上行链路上确实拥有相当数量的远程客户端，并且丢包和高延迟 – TCP-VPN如何在那里执行？
我试图改善标题和中心问题。 我希望这是有道理的。
我认为这实际上比你做出的辩论要多。 有一个公认的旧的，相关的Linux常见问题： http : //www.tldp.org/HOWTO/VPN-HOWTO/
我已经使用了一个超过ADSL的PPP-over-ADSL超过12年，它从来没有让我失望，所以从我的经验，我敢说，预言家可能在很大程度上夸大。 TCP over TCP对于RTC连接，卫星链路和其他链路吞吐量非常低或者很长的延迟可能是一个坏主意，但是对于大多数用途来说，它只是起作用 。
现在真正的问题是：为什么你会使用TCP over TCP？ 当我build立我的PPP-over-ssh时，很大程度上是因为当时build立一个快速VPN是最简单的方法。 那么我从此以后就一直使用它。
现在有一些实用的，易于设置的工具，如OpenVPN，IPSec VPNs，这样你就不需要打扰你这个TCP-over-TCP问题了。