这文章解释了为什么 TCP-over-TCP 可能导致性能灾难。
我对这个问题的理解是，“外部”TCP 连接处理网络数据包丢失和拥塞，并通过增加超时（从而降低吞吐量）采取相应措施。但是，“内部”TCP 连接看不到这些网络状况，因为它们已被外部 TCP“修复”。因此，“内部”TCP 继续以之前的速度发送数据包，从而使“外部”TCP 连接的内部发送缓冲区爆满。
我的问题是：
- 我的理解正确吗？
- 看来 TCP-over-TCP 崩溃只是内部问题（即，它只影响本地缓冲区），但它是否也会影响网络？它是否会导致网络拥塞加剧，并降低同一网络上其他连接的性能？
- 基于 TCP 的 VPN 如何解决这个问题？OpenVPN 有一个文章但它没有说明为什么这在实践中不是一个问题（或者是？）
非常感谢您的回答！
答案1
据我所知，“tcp meltdown”问题并不难解决：只需要为内部 tcp 连接设置一个较大的重传超时时间。
通过大幅增加内层 TCP 连接的最小重传超时时间，我们有效地禁用了内层 TCP 的超时重传机制，从而避免了 TCP 崩溃问题。
例如在linux中，您可以使用ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12s将通过OpenVPN建立的所有内部连接的最小重传超时时间从0.2秒增加到12秒(假设192.168.168.1/24是您的OpenVPN网段)。
你可以将上面的命令设置为OpenVPN的up事件回调。这样，我们实际上就用一种简单的方法避免了tcp meltdown问题。
我们用此方法对tcp-over-tcp链路进行优化，即使在高延迟（数百毫秒）、高丢包的线路上，也没有发现任何不良影响。
PS：在高延迟，高丢包，高带宽的线路上，显然需要准备一个大的窗口让内层tcp连接占用全部带宽。
更新：
这里的问题是为什么 TCP-over-TCP 对基于 TCP 的 VPN 没有明显的效果？
因为在很少丢包的高质量线路上，TCP崩溃现象并不突出。
答案2
我认为这更多地与TCP可以，但 OpenVPN 本身不行。下面是一段长篇大论和我的几点看法：
我的理解正确吗？
大致上是的，但内部 TCP 连接不受“保护”。如果外部丢包，吞吐量变低或延迟变高，内部连接也会受到限制，请注意，它无法充分利用性能并开始退缩。
看来 TCP-over-TCP 崩溃仅仅是内部的（即，它只影响本地缓冲区）但它是否也会影响网络？
您与服务器之间只有一个 TCP 连接，因此这只会影响该特定连接及其中的所有内容。崩溃所指的内容是我在上一个回答中描述的。
它是否会导致网络更加拥塞并降低同一网络上的其他连接质量？
不，但我需要在这里定义“网络”。如果您的互联网连接不好，那么是的，所有人都会遭受数据包丢失或其他传输问题。如果您的意思是只有您的客户端<=>服务器连接存在问题，那么您的非 VPN 连接不会受到影响。
基于TCP的VPN如何解决这个问题？
通过使用与服务器的单一连接，发送该连接内的流量并希望获得最佳效果。
OpenVPN 有一篇关于此的文章但是它没有说明为什么这在实践中不是一个问题，这在实践中是一个问题。
是的。TCP 在数据包大小方面的开销比 UDP 高得多，因此，如果在连接中使用两个 TCP 报头（内部和外部），您总是会付出大小代价。重新发送和 TCP 加速也会影响您的性能。如果您的连接良好，即没有掉线、低延迟和高带宽，那么您将看不到太多的加速/退避/重新发送，因此不会注意到这一点。如果您的连接不好，那么第一个答案就会发挥作用，外部连接可能会减速，这将影响内部流量，从而减速，数据包可能会变得无序并被重新发送等等，这肯定会影响隧道性能。
答案很长。我希望这对其他人来说也更有意义。