宽带下行跑满带宽后延迟飙升是什么问题?

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2486 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近测试了本地 3 条线路,一条电信 50M 对等企业宽带,一条联通家宽 100M 下 20M 上,一条移动家宽 100M 下 30M 上.
发现,电信和联通跑满下行后延迟飙升.就路由第一跳的地址就能有 300+ms,但是不丢包.
移动没有问题,跑满延时正常.
跑满上行的时候延迟没有明显增加.

然后我对每秒下行大包数量(pps)做了限制之后,只要下行带宽没占满,哪怕只留下 1M,延迟就不会明显上升. 限制规则如下,对应 100M 下行.

iptables -N PPPoELimit
iptables -A PPPoELimit -m hashlimit --hashlimit-upto 8130/sec --hashlimit-burst 909 --hashlimit-name PPPoE -j RETURN
iptables -A PPPoELimit -j DROP
iptables -A INPUT -i ppp0 -m length --length 1000:65535 -j PPPoELimit

查一些资料觉得可能是做限速的设备缓冲区过大,或者 QoS 做的不合理造成.
https://en.wikipedia.org/wiki/Bufferbloat

请问这个会是什么问题,要如何向运营商反馈?

第 1 条附言 · 2017-07-13 20:56:04 +08:00

附上另一种限速实现

tc qdisc add dev ppp0 root sfq perturb 10
tc qdisc add dev ppp0 ingress
tc filter add dev ppp0 ingress u32 match u32 0x00000400 0x0000FC00 police mtu 1500 rate 97mbit burst 4m drop

pppoelimit

iptables

下行

家宽

11 条回复 • 2017-07-13 10:09:16 +08:00

datocp

2017-07-12 19:56:12 +08:00 via Android

可以搜一下 tc hfsc，网上有一篇文档说明延迟，带宽，流量饱和程度是如何计算的。
实际上光纤当达到总带宽 80-90%左右时延迟不会有明显波动。所以这里有个叫 80%的分界点。而我们平时会计对不同的流量进行 class 分类处理，以针对不同流量做优先级控制通常，这就像一根大水管

datocp

2017-07-12 20:16:26 +08:00 via Android

可以搜一下 tc hfsc，网上有一篇文档说明延迟，带宽，流量饱和程度是如何计算的。
8*1500 byte(包大小) / 512000 bit/s(剩余.带宽) = 23.4375ms
htb 算法，实际上光纤当达到总带宽 80-90%左右时延迟不会有明显波动。所以这里有个叫 80%的分界点。而我们平时会计对不同的流量进行 class 分类处理，以针对不同流量做优先级控制通常解决流量和延迟，这就像一根大水管接上不同粗细的小水管，只要低于 80%的通过量就可以达到很好延迟。而大于 80%的通过量换来的是延迟的增加。

ovear

2017-07-12 20:37:28 +08:00

这个我觉得是电信联通的通病
没有做到 ICMP 包优先通过而已。
其实影响不怎么大。。你流量上去了，握手一样慢的

KCheshireCat

2017-07-12 22:38:25 +08:00

@ovear #3

我是在测速的时候分别试过 udp,tcp 和 icmp,都是延迟增大.截图中就是发 tcp 的握手包来测的延迟.

@datocp #2

tc hfsc 是发包策略,你说的延时计算方法是一条流间隔多少时间至少要发一个 1500 字节的包才能保证这条流有足够的上行流量.
我这情况是收包控流,目前我知道的方法就是通过丢包触发对端的拥塞算法来降低流量.

ovear

2017-07-12 22:41:27 +08:00

@KCheshireCat 移动方面 TCP 的 ping 也不会变化？那估计做了小包优先，或者出口限速，而不是局段限速了。

msg7086

2017-07-13 02:38:23 +08:00

这就说到网络原理了。
网络带宽是固定的，所以不可能传输超过带宽的数据量。
当你有过量的数据要下载的时候（例如 ICMP 的返回包），数据会堆积在宽带的入口。
这个入口会有一个队列，数据到达以后开始排队，先排到的就先发掉，后排到的就慢慢等着。
队列有一个容量上限，超过容量上限的数据都会被扔出去。
数据包被扔出去以后，对方会重新发包，数据包重新进队列。
这么反反复复以后，有一定概率这个包会落在队列之内，就会被成功发出来。
所以你看到的这个延迟，可能是返回包在队列里等着被发送而造成的延迟，也可能是被队列丢弃以后重发而造成的延迟。

msg7086

2017-07-13 02:39:34 +08:00

至于本地发送影响不大，我猜是本地 QoS 对小包有优化吧。

datocp

2017-07-13 07:19:56 +08:00 via Android

那条公式很好的说明了延迟是可以计算的，它跟总带宽 /跟剩余带宽的关系。一旦做了 qos,也就是延迟是跟当前水管的流量饱合程度在 80%上下有关系。
所以 qos 通常用来解决游戏的延迟和 p2p 的流量，分根小水管给目的 ip 144.144.144.144 只要保证实际通过流量低于 80%就可以获得低延迟。另外一根大水管给 p2p100%通过。在光纤两种造成的延迟可以达到 20ms 以下跟接近 600ms 的效果。所以这种问题基本是在自己本地网络通过 qos 策略就可以控制的，出了本地，人家的网络拥堵也没办法了。

hashlimt 跟 limit 一样，一个比较平和的对发包进行控制以达到流量抑制。openwrt sqm 描述的一些理论不怎么看，现在已经可以做到 95%以上的流量通过保证延迟和流量的平衡。linux 的 qos 效果还是非常不错的。

Showfom

2017-07-13 08:16:30 +08:00 via iPhone

运营商表示这是你的福利

yylzcom

2017-07-13 09:01:15 +08:00

你需要一个带 QoS 功能的路由器，我自己首推 Tomato by Shibby，看看国内有哪些汉化版和能刷的机器吧

8355

2017-07-13 10:09:16 +08:00

其实你就是需要一个 Qos 路由器我用华硕 87U 设置一下流量优先级就行了. 目前优先级游戏网页通讯工具其他流媒体文件传输

这样就基本是如果有符合优先级的数据包就会优先传送类似这种下载速度会有一定影响, 如果只看看网页之类的完全没问题.
我现在是一遍看电视一遍游戏一边看在线视频基本没问题.