许多管理员一直在坚持——在 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 的 …
我们正在 BGAN 卫星链路上运行 OpenVPN VPN，其中 ping 时间约为 3 秒。我们在tun配置中使用它，并且我们在 Linux (CentOS) 上运行。它主要是通过链接发送的电子邮件，但是一旦邮件包含大附件，VPN 似乎就会停止。
该“我可以通过隧道ping通，但任何实际工作导致其锁定。这是一个MTU的问题？” OpenVPN 常见问题解答中的问题似乎准确地描述了我的问题，但使用mssfix和fragment似乎仍然无法改善这种情况。
我的主要测试是使用scp通过 VPN 复制 2MB 文件。它将复制大约 192kbytes，然后报告一个- 停止 -状态。如果我等待几秒钟，它会再次开始复制，然后再经过几 KB 后再次停止。
无论我是否在 OpenVPN 配置中设置了fragment或mssfix选项，都会发生这种停顿（尽管设置fragment 1000似乎确实减少了停顿，但并没有消除它）。OpenVPNmtu-test报告 MTU 大小为 1542。
我在互联网上搜索了更多关于如何以及何时使用mssfixand 的建议fragment，但我只找到与 FAQ 相同的页面，并没有详细说明如何以及何时使用哪些参数。
我的问题是：
mssfix和fragment？mssfix和fragment组合使用吗？mssfix和fragment是解决方案tun-mtu，link-mtu和 …