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

2017-07-12 19:22:01 +08:00
 KCheshireCat

最近测试了本地 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

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

4954 次点击
所在节点    宽带症候群
11 条回复
datocp
2017-07-12 19:56:12 +08:00
可以搜一下 tc hfsc,网上有一篇文档说明延迟,带宽,流量饱和程度是如何计算的。
实际上光纤当达到总带宽 80-90%左右时延迟不会有明显波动。所以这里有个叫 80%的分界点。而我们平时会计对不同的流量进行 class 分类处理,以针对不同流量做优先级控制通常,这就像一根大水管
datocp
2017-07-12 20:16:26 +08:00
可以搜一下 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
那条公式很好的说明了延迟是可以计算的,它跟总带宽 /跟剩余带宽的关系。一旦做了 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
运营商表示这是你的福利
yylzcom
2017-07-13 09:01:15 +08:00
你需要一个带 QoS 功能的路由器,我自己首推 Tomato by Shibby,看看国内有哪些汉化版和能刷的机器吧
8355
2017-07-13 10:09:16 +08:00
其实你就是需要一个 Qos 路由器 我用华硕 87U 设置一下流量优先级就行了. 目前优先级 游戏 网页 通讯工具 其他 流媒体 文件传输

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/374863

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX