众所周知，SQM 在应对缓冲区膨胀时候的效果非常好，但是在连接数高、上行满载的网络环境下，最简单的piece_of_cake.qos还是差强人意，会出现正常网页/app 浏览由于偶发性丢包引起的高延迟，运气不好某个请求甚至连续丢包到失败；或者你有公网 IP 连接的时候，上行流量没法被很好的分配；
这几天看了一下layer_cake.qos和 DSCP 相关的内容，解决了上面提出的问题。
说明：
这是直接使用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 左右；
首先是基于你的上下行带宽*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 都是单独的机器，所以这里只贴个按 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 之类的东西，不然打标不生效！
参考：
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.