众所周知，SQM 在应对缓冲区膨胀时候的效果非常好，但是在连接数高、上行满载的网络环境下，最简单的piece_of_cake.qos还是差强人意，会出现正常网页/app 浏览由于偶发性丢包引起的高延迟，运气不好某个请求甚至连续丢包到失败；或者你有公网 IP 连接的时候，上行流量没法被很好的分配；

这几天看了一下layer_cake.qos和 DSCP 相关的内容，解决了上面提出的问题。

说明：

1. 仅针对上行
2. 图传是 imgbb ，看不到带梯子，点击跳大图

对比效果

这是直接使用piece_of_cake.qos时上行接口一周的监控数据，第一张表可以看到上行是时刻满载的；第二张表可以看到高峰期 PCDN 对整个网络延迟的影响，高达 100ms ；第三张表可以看到拥塞时的丢包统计数据；

值得一提的是，这里主要是因为 PCDN 的包多，且和正常流量混在了一起；实际使用，包括测速显示的网络延迟并没有那么高；主要问题还是上面说到的，SQM 通过丢包尽可能满足延迟需求的时候是无差别攻击，偶尔会出现正常浏览的包被丢掉。

最严重的应当是高峰期上传、实时语音视频，以及公司访问家里的时候，受 PCDN 的影响就会很明显。

这是调整后的数据，BE 即 Best Effort ，尽力而为，大多数数据包没分类都会被分到这里，最高可以用满整个上行，其实大部分时候，它就相当于piece_of_cake.qos

BK 即 Bulk ，DSCP CS1 及其他的慢速流量都会被分配到这里，SQM diffserv4 规则下，最多只能用 3648Kbit 的带宽

可见已经吃满了上行，且存在延迟和丢包。

BE 和 BK 在 15:25 之后的数据是我特意在公司直接播放了家里的一段高码率视频，把上行拉到了 40-50Mbps ，可以看到 BK 明显被压制；调整前，公网下载家里的文件，最高就 5Mbps 的速度，高峰期还没有；调整后，几乎可以吃满 50Mbps 的带宽，此时去看 PCDN 的速率被压到了 4Mbps 左右；

SQM 配置参考

首先是基于你的上下行带宽*85%-95%设置一个值

注意使用layer_cake.qos，才能为 PCDN/BT/PT 的流量分类

注意黄色框的内容是要填写的

入口（下行）填：

nat dual-dsthost ingress 

出口（上行）填：

nat dual-srchost diffserv4 

这里的 nat dual-xxx 意思是在 NAT 的环境下实施每 IP 公平策略，即所有 IP 均分带宽；其实关于这点我也很奇怪，如果是每 IP 公平，按理说不应该会有上面说的高峰期 5Mbps 都达不到，应该是 http 服务器和 pcdn 主机平分 50Mbps 的带宽；除非它把我那 70 多个几乎没流量，沉默的波比设备也算进去了...

ingress 我忘了啥意思了...

layer_cake.qos默认会使用diffserv3，其实我觉得也足够了，家用主要还是把 background traffic 处理掉，毕竟绝大部分时候我们跑的都是 Best Effort

如果不清楚什么是数据包开销，直接按图设置即可；这个值偏大会浪费一点带宽，但是小了会影响 QOS 的效果；

给 PCDN/BT/PT 流量打上低速 DSCP 标识

因为我家的 PCDN 都是单独的机器，所以这里只贴个按 MAC 处理的规则，如果不是，或者有更精细的处理需求的，可以按照这个思路想办法：

iptables -t mangle -A PREROUTING -m mac --mac-source xx:xx:xx:xx:xx:xx -j DSCP --set-dscp-class CS1 -m comment --comment "dcsp-wxedge" 

需要特别注意的是，必须关闭快速转发引擎/FastPath 之类的东西，不然打标不生效！

参考：

SQM Details

更加精细化，可以给指定 URL 分类的方案