%EF%BC%9F.png)
许多管理员在 ServerFault 和其他地方不断强调 TCP-over-TCP 是多么糟糕的想法，例如在 VPN 中。即使是最轻微的数据包丢失也会使人们遭受至少严重的吞吐量下降，如果不是 TCP 崩溃的话，因此必须严格避免使用 TCP-over-TCP。这可能曾经都是真的，例如 2001 年本文写成至今仍被提及。
但自那时以来，我们看到技术和协议取得了重大进展。如今，我们几乎在所有地方都实施了“选择性确认”，摩尔定律为我们提供了更多的内存，随之而来的是针对 Gbit 上行链路优化的大型 TCP 缓冲区。此外，如今在非无线电链路上，数据包丢失问题已经大大减少。所有这些都应该可以大大缓解 TCP-over-TCP 问题，不是吗？
请注意，在现实场景中，基于 TCP 的 VPN 比基于 UDP/ESP 的 VPN 更易于实现和操作（详见下文）。因此，我的问题是：
假设两端都支持 SACK 且 TCP 缓冲区大小合适，在什么情况下（链路数据包丢失和延迟），TCP-over-TCP 的性能会比单独的 TCP 差很多？
如果能看到一些测量结果显示（外部连接）数据包丢失/延迟与（内部连接）吞吐量/抖动之间的相关性（对于 TCP-over-TCP 和仅对于 TCP），那就太好了。我发现这篇有趣的文章，但它似乎只关心延迟，而不解决（外部）数据包丢失问题。
另外：是否有推荐的设置（例如 TCP 选项、缓冲区设置、减少 MTU/MSS 等）来缩小 TCP 和 TCP-over-TCP 之间的性能差距？
更新：我们的理由。
这个问题在某些现实场景中仍然非常重要。例如，我们在大型建筑中部署嵌入式设备，收集传感器数据并通过 VPN 将其输入到我们的平台。我们面临的问题是防火墙和配置不当的上行链路不受我们控制，再加上 IT 部门的不情愿。请参阅讨论的详细示例这里。
在很多此类情况下，从非 TCP 切换到基于 TCP 的 VPN（如果您像我们一样使用 OpenVPN，则非常容易）是一种快速解决方案，可让我们避免艰难的指责之争。例如，通常 TCP 端口 443 通常是允许的（至少通过代理），或者我们可以通过简单地减少 TCP 的 MSS 选项来解决 Path-MTU 问题。
了解在什么情况下基于 TCP 的 VPN 可以被视为可行的替代方案是件好事，这样我们就可以做出明智的决定，权衡两种选择的利弊。例如，我们知道 TCP-VPN 在非无线电链路上是可行的，但我们在 3G 上行链路上确实有相当一部分远程客户端存在严重的数据包丢失和高延迟 - TCP-VPN 在那里的表现如何？
我尝试相应地改进标题和核心问题；我希望它有意义。
答案1
我认为它实际上比你想象的更有争议。有一个公认的古老相关 Linux FAQ：http://www.tldp.org/HOWTO/VPN-HOWTO/
我已经使用 PPP-over-ssh-over-ADSL 超过 12 年了，它从来没有让我失望过，所以从我的经验来看，我敢说那些预言家可能夸大其词。对于 RTC 连接、卫星链路和其他吞吐量非常低或延迟非常长的链路来说，TCP over TCP 可能不是一个好主意，但对于大多数用途来说刚刚起作用。
现在真正的问题是：为什么要使用 TCP over TCP根本? 当我设置我的 PPP-over-ssh 时，主要是因为当时它是迄今为止构建快速 VPN 最简单的方法；从那时起，我一直出于懒惰而使用它。
如今，有了像 OpenVPN、IPSec VPN 等实用且易于设置的工具，您就再也不需要为这个 TCP-over-TCP 问题而烦恼了。
答案2
Soft-ether VPN 是 TCP over TCP 实现的一个示例。在正常情况下和完美的网络吞吐量下，VPN 工作正常，延迟可以接受。但是，如果有一点点噪音或数据包丢失（由于某些国家/地区使用防火墙阻止 VPN），Soft-ether 会变得非常慢，延迟高，连接丢失很多。此外，在这些情况下进行简单的 ping 测试会显示 UDP/TCP 与 TCP/TCP 实现之间存在显著差异。