许多管理员（在ServerFault和其他地方）一直保持不变，例如，在VPN中，TCP-over-TCP是多么糟糕的想法。即使不是TCP崩溃，即使是最轻微的数据包丢失也将使至少遭受严重的吞吐量下降，因此必须严格避免TCP-over-TCP。这可能曾经是真的，例如2001 年撰写本文时仍在引用。
但是从那以后，我们看到了技术和协议的重大进步。如今，几乎在所有地方都实现了“选择性ACK”，摩尔定律为我们提供了更多的存储空间，随之而来的是为千兆位上行链路优化的大型TCP缓冲区。如今，在非无线电链路上，数据包丢失也不再是问题。所有这些都可以大大缓解TCP-over-TCP问题，不是吗？
请注意，在现实世界中，例如，基于TCP的VPN比基于UDP / ESP的VPN更易于实现和操作（请参阅下文）。因此我的问题是：
在什么情况下（链路数据包丢失和等待时间），TCP-over-TCP的性能要比单独的TCP差很多，假设SACK支持并且两端的TCP缓冲区大小合适。
太棒了，因此请查看一些测量结果，以显示（外部连接）数据包丢失/延迟与（内部连接）吞吐量/抖动之间的相关性-对于TCP-over-TCP和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在那里将如何执行？
我试图相应地改善标题和核心问题。我希望这是有道理的。