1
在什么情况下TCP-over-TCP的性能要比单独使用TCP的性能差很多(2014年)?
许多管理员(在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在那里将如何执行? 我试图相应地改善标题和核心问题。我希望这是有道理的。