通过 LFN 上传到互联网的 TCP 速度很慢

通过 LFN 上传到互联网的 TCP 速度很慢

我有两个 Linux VM,它们之间由 50 mbps WAN 连接隔开。此 WAN 链路的 RTT 约为 70ms,因此存在一定延迟。我一直在测试每个 VM 的上传到 Internet 的吞吐量。基本设置是站点 A 具有 Internet 连接,并且还具有到站点 B 的 WAN 连接。站点 B 使用站点 A 的 Internet 连接。

我注意到站点 B 的互联网上传速度比站点 A 要慢得多。我只是使用一些互联网速度测试站点来测试我的上传速度。我使用每个站点的相同互联网速度测试站点和服务器进行测试。我也进行了很多次测试。

我运行了一些 Wireshark 测试,以查看发生了什么。我假设互联网服务器没有打开足够宽的 TCP 窗口来解释来自站点 B 的 70ms 额外延迟。然而,TCP 窗口是完全打开的,实际上是我的站点 B 服务器停止传输,等待 ACK 到来后再发送更多数据。

我查看了很多内容:TCP 时间戳、SACK 和窗口缩放均已启用。我已按如下方式增加了缓冲区:

net.core.rmem_max = 67108864 
net.core.wmem_max = 67108864 
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_congestion_control=cubic

我还增加了传输队列的长度,如下所示:

ifconfig eth0 txqueuelen 10000

最后,我禁用了 VM 上的软件 TCP 段卸载(我的服务器上没有硬件 TOE)。

尽管如此,Wireshark 还是显示我获得的传输数据不超过 11,000 字节。在传输开始时我确实丢了一些数据包,但当传输真正开始时,我本以为会有更多数据传输。

有人能解释一下为什么在实际传输的数据如此之少的情况下,发送方要保留数据吗?

答案1

我在您的数据包跟踪中看到的是拥塞控制对数据包丢失做出的反应。

客户端首先发送初始 9 个段,然后是慢启动,每次收到 ACK 数据包时都会发送两个段。

慢启动算法持续进行,直到服务器发出的第一个重复 ACK 表明数据包已丢失。这种情况发生在有 20820 个字节在传输中时。此后,客户端将以较慢的速度增加拥塞窗口。

第二次拥塞发生在传输开始仅半秒后。此后,传输中的字节数从大约 15K 增长到 68012 字节,此时第三次拥塞发生,即传输开始 6 秒后。

第三次拥塞后,传输中约有 54KB 字节。该数据不断增加,直到传输中达到 94384 字节,第四次拥塞发生,此时传输已进行 10 秒。

跟踪的其余部分还出现了多起拥塞情况。如果数据包丢失的次数没有那么频繁,传输速度可能能够加快。由于它很早就出现了第一次数据包丢失,因此需要很长时间才能达到全速。

因此,您需要弄清楚为什么在 TCP 连接期间这么早就丢失了数据包。事实证明,此时丢失的数据包是连接开始时连续发送的 9 个数据包之一。这表明客户端配置的设置太高了initcwnd。从您提供的一次数据包捕获来看,合理的设置应该是4

initcwnd设置是针对每个路由表条目单独指定的。可以使用命令查看和更改它们ip route

相关内容