什么是 TCP-over-TCP?TCP 模式下的 OpenVPN 如何避免该问题?

diw*_*enx 6 networking vpn openvpn tcp

本文解释了为什么TCP-over-TCP 可能会造成性能灾难。

我对此问题的理解是,“外部”TCP 连接处理数据包丢失和网络拥塞,并通过增加超时(从而降低吞吐量)来相应地采取行动。然而,“内部”TCP 连接看不到这些网络状况,因为它们是由外部 TCP“固定”的。因此,“内部”TCP 继续以先前的速度发送数据包,从而破坏了“外部”TCP 连接的内部发送缓冲区。

我的问题是:

  1. 我的理解正确吗?
  2. 看起来 TCP-over-TCP 崩溃只是内部的(即,它只影响本地缓冲区),但它是否也会影响网络?它是否会导致网络更加拥塞并且是否会降低同一网络上的其他连接的性能?
  3. 基于TCP的VPN如何解决这个问题?OpenVPN 有一篇关于此的文章,但没有说明为什么这在实践中不是问题(或者是吗?)

非常感谢您的回答!

ASB*_*Bai 5

以我的理解,“tcp 熔断”问题并不难解决:只需为内部 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熔断问题。

我们使用这种方法来优化 tcp-over-tcp 链路。即使在高延迟(数百毫秒)和高丢包的线路上,我们也没有发现任何不利影响。

PS:在高延迟、高丢包、高带宽的线路上,显然需要为内部tcp连接准备一个大的窗口来占用全部带宽。

更新:

这里的问题是,为什么 TCP-over-TCP 对基于 TCP 的 VPN 没有明显的影响?

因为在很少丢包的高质量线路上,TCP熔断现象并不突出。


Fre*_*rik 0

我认为这更多地与TCP 的工作方式有关,而不是与 OpenVPN 本身有关。这是长篇大论和我的几分钱:

我的理解正确吗?

大致上是的,但是内部 TCP 连接不受“保护”。如果外部丢弃数据包并且吞吐量变低或延迟变高,内部连接也会受到此限制,请注意,它无法充分利用性能并开始回退。

看起来 TCP-over-TCP 崩溃只是内部的(即,它只影响本地缓冲区),但它是否也会影响网络?

您将只有一个到服务器的 TCP 连接,因此这只会影响该特定连接及其中的任何内容。崩溃指的是我在之前的答案中描述的内容。

它是否会导致网络更加拥塞并且是否会降低同一网络上的其他连接的性能?

不,但我需要在这里定义“网络”。如果您的互联网连接状况不佳,那么是的,所有内容都会出现数据包丢失或其他传输问题。如果您的意思是您的客户端 <=> 服务器连接存在问题,那么您的非 VPN 连接不会受到影响。

基于TCP的VPN如何解决这个问题?

通过使用与服务器的单个连接,在该连接内发送流量并期待最好的结果。

OpenVPN有一篇关于这个的文章,但没有说为什么在实践中不是问题,在实践中是否有问题。

是的。TCP 在数据包大小方面的开销比 UDP 高得多,因此连接中包含两个 TCP 标头(内部加外部)总是会造成大小损失。重新发送和 TCP 加速也会影响您的性能。如果您有良好的连接,即无掉线、低延迟和高带宽,那么您将不会看到太多的斜坡上升/回退/重新发送,因此不会注意到这一点。如果您的连接状况不佳,那么第一个答案就会发挥作用,外部连接可能会下降,这将影响内部流量,而内部流量也会下降,数据包可能会变得混乱并被重新发送等等,这肯定会影响隧道性能。

答案很长。我希望这对比我更多的人有意义。