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

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

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

5139 次点击
所在节点    宽带症候群
12 条回复
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 设置一下流量优先级就行了. 目前优先级 游戏 网页 通讯工具 其他 流媒体 文件传输

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

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

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

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

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

© 2021 V2EX