这是一个创建于 42 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司拉了一条移动的千兆 VPN 专线,北京-福州专线,使用 wget 从福州服务器请求北京服务器上面的资源,速度只能到 8M/s,但是使用 axel 进行多线程下载,速度可以到 40-50M/s
网上搜索了下,好像是 TCP 丢包策略,会导致单线程下载降速,但是 ping 了下两端,并没有丢包啊
有谁能知道原因是什么嘛,如何优化能使 wget 下载也能跑 40M/s 左右吗?
21 条回复 • 2024-10-12 10:53:53 +08:00
 |
1
dode 42 天前
套一层 wireguard VPN 看看
|
 |
2
fuis 42 天前  1
用 tcpdump 抓包看看就知道了
|
 |
3
Mithril 42 天前
如果你的服务器/ISP 没有限制单个链接速度的话，一般都是 TCP 流控生效了。
wget 不支持针对单个文件的多线程下载，如果你有多个文件的话，可以开多个 wget 同时下载不同的文件，但只有一个大文件就没办法了。 |
 |
5
lambdaq 42 天前
不是 tcp 丢包策略，而是 tcp 拥堵控制
单线程是一个人排队。多线程就是 n 个人一起排队。别人效率当然高啊。 |
 |
6
FishBear 42 天前
https://github.com/FishOrBear/mTCP2
上这个 将多条 tcp 聚合成单条 干他 |
 |
7
tool2dx 42 天前 1
没什么原因，普通宽带就是 TCP 多线程 > 单线程。你就算用 iperf3 裸测网速，也是这个结果。
不过你 8M/s 和 40M/s 相比，还是有那么一点夸张。我测试下来降速 50%，是正常范围内的。 |
 |
8
Meltdown 42 天前 1
试试修改服务器的 tcp congestion control 算法
|
 |
9
BingoXuan 42 天前
tcp 的滑动窗口越大，也就使得通信过程中等待确认时候缓存的数据大小越大。给定 RTT ，滑动窗口越大速度会越快（快速确认数据传送完成）。当滑动窗口最大时候，RTT 就成了限制速度的天花板。但多线程就等于 RTT 几乎一致的情况下，累积窗口大小乘以线程数量，所以网速就快很多。
|
 |
10
D3EP 42 天前
关键字，带宽时延积。可以试着改下 socket buffer 。
|
 |
11
lxyv 42 天前
运营商的 qos 策略，开了单线程限速
|
 |
12
flynaj 42 天前 via Android
服务器，路由器都开启 bbr
|
 |
13
florentino OP 感谢大家回复,我来挨个试试 🤏🤏
|
 |
14
bbsingao 42 天前
开 bbr 最方便
|
|
15
florentino OP 我用 tcpdump 导出了一下日志, 有大佬能给帮忙看下吗? 感激不尽
https://wwiq.lanzoue.com/ix6sE2c6rj9g |
|
16
florentino OP 我问了一下 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 捕获更长时间的数据包来观察是否有持续的模式。 |
|
17
fuis 42 天前
从统计图上看，经典的丢包现象。细化进去有大量的 dup ack 和 out-of-order 证实了这一点，丢包大概持续了 0.15s
 |
|
18
fuis 42 天前 1
解决的办法嘛，最简单的先改成 bbr 试试，要是好了就不用搞别的了
|
 |
19
xqzr 41 天前
MTU
|
|
20
FishBear 41 天前
tcp 丢包就是因为你速度太快了 给你丢包 控制你的网速 ping 当然不会显示丢包了
|
|
21
florentino OP 最终结果, 线程开到 200 下载速度就到 1G 了, 太离谱了
但是具体原因还是没有深究出来, 稀里糊涂的就跑上去了 []( https://imgse.com/i/pAYwcPU) |
Select Language