路由器 K2P,固件 padavan，linux 3.4，默认情况下路由器开木马连接 VPS，speedtest 单线程测速，cpu 未满载
调整为 linux 5.x 内核的参数
echo 4096 131072 6291456 > /proc/sys/net/ipv4/tcp_rmem
echo 212992 > /proc/sys/net/core/rmem_default
echo 4194304 >/proc/sys/net/core/rmem_max
此时测速 speedtest 单线程测速可以跑满路由器 cpu 的一个线程了，cpu 成为瓶颈，明天测测超频后的速度
 |
1
redsonic Mar 3, 2020
tcp 本来就是靠 ACK 携带 window 信息的正向反馈系统，可以想象成一个远程反馈令牌桶，扩大 window 就是扩大令牌桶数量。除此之外启动算法也决定高延迟下数据流的响应速度。
|
 |
3
bibiisme OP @redsonic 这个是 cn2 gia 的线路，改了后速度还算比较正常。还有些高丢包的线路，linux3.4 的 k2p 改了后也和 linux 5.4 的设备网速差距很大，不知道是哪里的问题，记忆中 tcp 的拥塞控制只影响发送来着。
|
|
4
redsonic Mar 3, 2020  1
@bibiisme 其实就是接收方的 window 来驱动发送方，接收方回馈的越快，回馈时携带的 window 越大，那么发送方越卖力。如果延迟大的线路你需要改大 window 来让发送方填埋整个线路，否则就会浪费。而低延迟线路没有这个问题。如果是高丢包的线路，整个反馈机制会受到冲击，window 大小就不那么重要了。
|
|
9
redsonic Mar 3, 2020
接受端没有，发送端可以换 bbr 拥塞算法，也可以用 tc 限速，回避因接收方限速丢包后引发的一系列重传机制。
|
|
11
redsonic Mar 3, 2020
@bibiisme 因为现在的 TCP ACK 都是选择重传 SACK，就是只重传丢失的包，所以塞满包的线路丢几个然后重传影响不大，调大 window 还是好的做法。我之前说的是高丢包情况下比如 10%以上，什么机制都歇菜除了那些魔改的，但真的不建议用。
|
|
12
bibiisme OP @redsonic 发送端没打算改，因为手上的 n1 linux 5.4 啥都没改也跑得起来。就是这个 LINUX 3.4 的 K2P 即使增大了窗口，也还是不如 N1，唉。。。。
|
 |
13
zhs227 Mar 3, 2020
大的 BDP 会对网速提升有帮助。
|
Select Language