Nil*_*ann 27 networking vpn ip tcp network-protocols
许多管理员一直在坚持——在 ServerFault 和其他地方——TCP-over-TCP 的想法有多糟糕，例如在 VPN 中。如果不是 TCP 崩溃，即使是最轻微的数据包丢失也会使一个人遭受至少严重的吞吐量下降，因此应严格避免 TCP-over-TCP。这可能曾经是真的，例如 2001年写这篇文章时仍然被引用。
但从那时起，我们看到了技术和协议的重大进步。现在我们几乎在所有地方都实现了“选择性 ACK”，摩尔定律给了我们更多的内存，随之而来的是针对 Gbit 上行链路优化的大型 TCP 缓冲区。如今，在非无线电链路上，数据包丢失的问题要少得多。所有这些都应该显着缓解 TCP-over-TCP 问题，不是吗？
请注意，在现实世界中，例如基于 TCP 的 VPN 比基于 UDP/ESP 的 VPN 更容易实现和操作（参见下文）。因此我的问题：
在什么情况下（链路数据包丢失和延迟），TCP-over-TCP 的性能比单独的 TCP 差得多，假设两端都有 SACK 支持和大小合适的 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 在那里的性能如何？
我试图相应地改进标题和中心问题；我希望这是有道理的。
我认为它实际上比你表现出来的更具争议性。有一个公认的旧的相关 Linux 常见问题解答：http : //www.tldp.org/HOWTO/VPN-HOWTO/
我使用 PPP-over-ssh-over-ADSL 已经超过 12 年了，它从来没有让我失望，所以根据我的经验，我敢说末日论者可能在很大程度上夸大其词。TCP over TCP 对于 RTC 连接、卫星链接和其他具有非常低吞吐量或非常长延迟的链接可能是一个坏主意，但对于大多数用途，它只是有效。
现在真正的问题是：你为什么要使用TCP通过TCP可言？当我设置 PPP-over-ssh 时，主要是因为当时它是构建快速 VPN 的最简单方法；然后我一直使用它，因为纯粹是懒惰。
现在有一些实用且易于设置的工具，例如 OpenVPN、IPSec VPN，这样您就不必再为 TCP-over-TCP 问题而烦恼了。