Linux tcp 接收窗口影响高延迟下网速？

[bibiisme]

路由器 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 成为瓶颈，明天测测超频后的速度

[redsonic]

tcp 本来就是靠 ACK 携带 window 信息的正向反馈系统，可以想象成一个远程反馈令牌桶，扩大 window 就是扩大令牌桶数量。除此之外启动算法也决定高延迟下数据流的响应速度。

[bibiisme]

@redsonic 算法是指 cubic bbr 这种吗?算法的话只影响发送吧，接收端有算法控制嘛?

[bibiisme]

@redsonic 这个是 cn2 gia 的线路，改了后速度还算比较正常。还有些高丢包的线路，linux3.4 的 k2p 改了后也和 linux 5.4 的设备网速差距很大，不知道是哪里的问题，记忆中 tcp 的拥塞控制只影响发送来着。

[redsonic]

@bibiisme 其实就是接收方的 window 来驱动发送方，接收方回馈的越快，回馈时携带的 window 越大，那么发送方越卖力。如果延迟大的线路你需要改大 window 来让发送方填埋整个线路，否则就会浪费。而低延迟线路没有这个问题。如果是高丢包的线路，整个反馈机制会受到冲击，window 大小就不那么重要了。

[bibiisme]

@redsonic 那看来光改参数是没用了，估计是新内核整个反馈机制都有大变动了，所以高丢包线路差距较大

[redsonic]

@bibiisme 你线路好改参数就解决问题了，如果丢包厉害啥也救不了。如果都用 kcp 只会使情况更糟。

[bibiisme]

@redsonic 丢包不严重，百分之几吧，结果 n1 几十 m，k2p 十 m。。。

[bibiisme]

@redsonic 那麻烦问下，接收端除了接收窗口还有什么可以调节的吗。。。

[redsonic]

接受端没有，发送端可以换 bbr 拥塞算法，也可以用 tc 限速，回避因接收方限速丢包后引发的一系列重传机制。

[bibiisme]

@redsonic 那就很迷了，同样的服务端+线路，增大窗口后跑这种有丢包的线路还是有差距。。。跑国内确实和你说的一样没啥差别。

[redsonic]

@bibiisme 因为现在的 TCP ACK 都是选择重传 SACK，就是只重传丢失的包，所以塞满包的线路丢几个然后重传影响不大，调大 window 还是好的做法。我之前说的是高丢包情况下比如 10%以上，什么机制都歇菜除了那些魔改的，但真的不建议用。

[bibiisme]

@redsonic 发送端没打算改，因为手上的 n1 linux 5.4 啥都没改也跑得起来。就是这个 LINUX 3.4 的 K2P 即使增大了窗口，也还是不如 N1，唉。。。。

[zhs227]

大的 BDP 会对网速提升有帮助。

[redsonic]

@redsonic 像这种情况你需要裸跑 iperf 抓包分析了。有性能要求还是用软路由吧，懒得折腾。