用TC优化腾讯云Linux服务器QOS软限速导致的断流

关键词:QOS 限速 惩罚机制 断流 腾讯云 轻量 Youtube卡顿 tc 流量控制 技术 随笔

腾讯云最近推出的轻量应用服务器Lighthouse深受广大MJJ们的欢迎,所谓的高频低价,不得不为他宣传一波!

【腾讯云】轻量应用服务器Lighthouse,上云「轻」而易举,1核1G3M低至128元/年,高带宽首选!

最近很多小伙伴都反映腾讯云轻量服务器测速满满的,即使是晚高峰也能在Speedtest跑到多少多少balabala......但是加载Youtube视频却是一卡一卡的断流严重,为什么呢?

经过我们上手测试,通过对Youtube低谷时段的断流情况和速度图都是匀速30Mbps左右的判断,事因腾讯云轻量应用服务器使用的限速策略,实质上也是一种QOS限速,当网关检测到上行流量在一定周期内超出本周期的限制时就会采取策略主动丢包以降低流量速率,等待下一个统计周期才会解除丢包策略,这样的一个周期一般称为惩罚周期。如图是在腾讯云香港轻量与广州CVM之间的iperf3测试(香港发包),可见其限速周期(时长时短)。

香港 -> 广州 惩罚周期较长,iperf3测试出现超过0.2秒断点

这在一般大陆内部使用问题不大,但是在丢包情况相对严重的时候会放大问题,如图在晚高峰22:00时段的Youtube速度图可见断流严重以至于速度几乎不更新,视频也是卡卡的,当断点遇上视频进度条的拖拽就会严重影响游戏体验!(Youtube测试环境,广州电信100M宽带)

断点导致的断流严重,速度显示也只有17M左右,影响视频进度条拖拽

在尝试进行工单沟通提交问题无果之后,笔者开启了贤者模式,因曾经遇到的限速都没有如此严重的断流,曾经使用的Linux网络协议栈QOS模块TC(Traffic Controll)是非常稳定,我们是否可以使用这个模块来限制流量上行,从而避免触发腾讯云轻量云的限速惩罚呢?答案是肯定的!

如果有需要了解TC模块的整体功能,大家可以移步搜索引擎查阅文献,笔者在查阅了相关模块的使用方式之后在这大致介绍(腾讯云香港轻量CentOS 7.8系统自带模块,如果提示tc找不到可以尝试yum install tc -y安装,其余问题请移步搜索引擎):

  • TC模块分有 队列qdisc、分类class、过滤器filter 三个部分:
    • 队列就是对应网卡接口的数据队列,就是我们平时用的bbr拥塞算法所对应的fq队列的那个队列
    • 分类就是队列中的不同流量的分类,可以对不同流量加以不同的流量和优先级控制
    • 过滤器则可以把各种方式归类为上述的各个分类,可以结合iptables打标记mark的方式或者软路由中的路由归类,但本文未使用
  • 限速方式有多种,如hbt、cbq等,本文使用hbt

下面就直接开始干Shell:

代码语言:javascript
复制
# 删除eth0原有的tc队列,如果有配置过tc,请不要直接使用!
# tc qdisc del dev eth0 root

为eth0网口添加新的tc队列

默认流量分类为0可加上default将默认分类设为其他值

tc qdisc add dev eth0 root handle 1: htb

设置根分类限速,将限制eth0网口30Mbps,有效避免腾讯云轻量惩罚机制

rate为保证带宽,ceil为最大带宽,可选prio设置优先级

tc class add dev eth0 parent 1: classid 1: htb rate 30mbit ceil 30mbit

可选设置其他分类(class中的1:x就是分类x,默认分类中的0可省略)

tc class add dev eth0 parent 1: classid 1:2 htb rate 20mbit ceil 20mbit prio 2

对本文所用到的iperf3端口流量用iptables进行标记并处理

iptables -t mangle -A POSTROUTING -p tcp --sport 12345 -j MARK --set-mark 2

iptables -t mangle -A POSTROUTING -p tcp --sport 12345 -j RETURN

使用过滤器filter将iptables标记的mark 2归类为class 1:2

tc filter add dev eth0 parent 1:0 protocol ip handle 2 fw classid 1:2

执行上述的脚本之后,如果装有bbr的Linux,eth0网口的队列算法将会从fq变为qdisc,重启之后tc规则会丢失,同时全局限速30Mbps,高玩可以解锁其他玩法!直接上iperf3效果图:

有一定量的带宽损失,但速度表现稳定,无断点

有人可能会认为这样操作可能会浪费超过10%的带宽,其实不然,在笔者尝试优化的过程中,限速31Mbps与限速32Mbps带宽可能会提升,但是偶然也会出现断流惩罚的问题,如果进行长时间30秒的iperf3测试,估计大家可以看到平均速度其实是接近的。如果不需要Youtube速度稳定不断流,只需其他业务稳定,可以退一步优化将限速限制为32Mbps,经测试相当稳定!

无tc
有tc

在Youtube测试中表现也非常不错,速度图可以跳动且稳定在20Mbps以上,拖拽卡顿感明显减弱,机器重获新生!

几乎没有断流,断点时间非常短,效果良好

最后附上双程mtr测试图:

回程mtr
回程tcp mtr
去程mtr

以上就是基础笔记内容,如有笔误请评论或通过邮件告知,如需转载请注明出处:大鸡测评 https://www.daji-mark.com/?p=474