多线程为什么速度就快,如何排查原因

[florentino]

公司拉了一条移动的千兆 VPN 专线,北京-福州专线,使用 wget 从福州服务器请求北京服务器上面的资源,速度只能到 8M/s,但是使用 axel 进行多线程下载,速度可以到 40-50M/s

网上搜索了下,好像是 TCP 丢包策略,会导致单线程下载降速,但是 ping 了下两端,并没有丢包啊

有谁能知道原因是什么嘛,如何优化能使 wget 下载也能跑 40M/s 左右吗?

[dode]

套一层 wireguard VPN 看看

[fuis]

用 tcpdump 抓包看看就知道了

[Mithril]

如果你的服务器/ISP 没有限制单个链接速度的话，一般都是 TCP 流控生效了。

wget 不支持针对单个文件的多线程下载，如果你有多个文件的话，可以开多个 wget 同时下载不同的文件，但只有一个大文件就没办法了。

[dode]

https://v2.hysteria.network/zh/docs/misc/About-HTTP3/

[lambdaq]

不是 tcp 丢包策略，而是 tcp 拥堵控制

单线程是一个人排队。多线程就是 n 个人一起排队。别人效率当然高啊。

[FishBear]

https://github.com/FishOrBear/mTCP2
上这个 将多条 tcp 聚合成单条 干他

[tool2dx]

没什么原因，普通宽带就是 TCP 多线程 > 单线程。你就算用 iperf3 裸测网速，也是这个结果。

不过你 8M/s 和 40M/s 相比，还是有那么一点夸张。我测试下来降速 50%，是正常范围内的。

[Meltdown]

试试修改服务器的 tcp congestion control 算法

[BingoXuan]

tcp 的滑动窗口越大，也就使得通信过程中等待确认时候缓存的数据大小越大。给定 RTT ，滑动窗口越大速度会越快（快速确认数据传送完成）。当滑动窗口最大时候，RTT 就成了限制速度的天花板。但多线程就等于 RTT 几乎一致的情况下，累积窗口大小乘以线程数量，所以网速就快很多。

[D3EP]

关键字，带宽时延积。可以试着改下 socket buffer 。

[lxyv]

运营商的 qos 策略，开了单线程限速

[flynaj]

服务器，路由器都开启 bbr

[florentino]

感谢大家回复,我来挨个试试 🤏🤏

[bbsingao]

开 bbr 最方便

[florentino]

我用 tcpdump 导出了一下日志, 有大佬能给帮忙看下吗? 感激不尽
https://wwiq.lanzoue.com/ix6sE2c6rj9g

[florentino]

我问了一下 AI 给的结论是下面这个:

从你提供的 Wireshark 捕获数据中，我们可以观察到以下情况：

1. **TCP 三次握手和数据传输**：数据包显示了源 IP 地址 `192.168.102.200` 在端口 `8080` 和目的 IP 地址 `192.168.102.12` 在端口 `36850` 之间的 TCP 通信。数据包的序列号（ Seq ）在增加，表明数据正在被传输。

2. **重复确认（ Duplicate ACKs ）**：日志中出现了多个重复确认（例如 `[TCP Dup ACK 752#23]`），这通常意味着接收方（`192.168.102.12`）没有收到预期的数据包，因此它发送重复的确认来提示发送方（`192.168.102.200`）重传丢失的数据包。

3. **快速重传（ TCP Fast Retransmission ）**：数据包 `#819` 显示了一个快速重传，这表明发送方在收到三个或更多的重复确认后，重传了丢失的数据包。

4. **乱序数据包（ TCP Out-Of-Order ）**：数据包 `#775` 和 `#823` 显示了乱序的数据包，这意味着接收方收到了不是按顺序到达的数据包。

5. **大窗口大小**：发送方的窗口大小（ Win ）是 `30080`，这表明发送方有足够的接收缓冲区来接收数据。

6. **大的数据包大小**：一些数据包的长度（ Len ）相当大，例如 `2962` 和 `27578` 字节，这表明有大量的数据正在被传输。

7. **时间戳（ TSval 和 TSecr ）**：时间戳用于测量往返时间（ RTT ）和确保数据包的顺序。它们在数据包之间是一致的，表明通信是连续的。

8. **TCP 窗口缩放（ TCP Window Scaling ）**：数据包 `#847` 显示了一个非常大的窗口大小，这可能是使用了 TCP 窗口缩放选项。

从这些信息中，我们可以推断出可能存在网络延迟或丢包问题，导致接收方没有按预期收到数据包，因此发送了重复的确认。发送方随后执行了快速重传来尝试解决这个问题。乱序的数据包也可能表明网络中的延迟或重传问题。

要解决这个问题，你可能需要检查网络连接的质量，包括路由器、交换机和物理连接。此外，检查是否有网络拥塞或带宽限制也很重要。如果问题持续存在，可能需要进一步的网络诊断，包括使用 Wireshark 捕获更长时间的数据包来观察是否有持续的模式。

[fuis]

从统计图上看，经典的丢包现象。细化进去有大量的 dup ack 和 out-of-order 证实了这一点，丢包大概持续了 0.15s

[fuis]

解决的办法嘛，最简单的先改成 bbr 试试，要是好了就不用搞别的了

[xqzr]

MTU

[FishBear]

tcp 丢包就是因为你速度太快了 给你丢包 控制你的网速 ping 当然不会显示丢包了