4、QoS配置实战：WMM、802.1p优先级映射、智能家居设备流量整形、带宽保障策略
说到智能家居网络，很多人第一反应是“信号覆盖”。但说实话，信号满格≠体验流畅。真正让智能家居系统“翻车”的，往往是流量拥堵——你想想看，全家几十个设备同时在线，摄像头在上传视频，音箱在播放音乐，扫地机在回传地图，网关在同步状态……这时候如果没做好QoS，最先掉链子的就是那些对延迟最敏感的设备。
我这些年调试过的智能家居网络，少说也有上百套了。早期我犯过一个低级错误：给所有设备都开了“最高优先级”。结果呢？所有流量都抢着插队，反而谁都没快起来。嗯，这里要记住一个核心原则——QoS不是给所有设备“加速”，而是给关键业务“让路”。
4.1 WMM：Wi-Fi多媒体，智能家居的“交通警察”
WMM（Wi-Fi Multimedia）是Wi-Fi联盟定义的QoS基础协议。说白了，它把无线流量分成四个“车道”：
| 接入类别（AC） | 典型业务 | 优先级 | 我常用的场景 |
|---|---|---|---|
| AC_VO（语音） | VoIP电话、智能音箱唤醒 | 最高 | 门铃对讲、语音控制指令 |
| AC_VI（视频） | 视频流、监控摄像头 | 高 | 安防摄像头、智能电视 |
| AC_BE（尽力而为） | 普通数据、网页浏览 | 中 | 手机刷视频、设备OTA升级 |
| AC_BK（背景） | 后台下载、日志上报 | 低 | 固件静默更新、设备状态同步 |
在路由器后台开启WMM后，每个Wi-Fi帧头里都会带上AC标记。无线AP看到AC_VO的帧，就会优先发送。我建议你务必开启WMM——现在99%的家用路由器默认就是开启的，但有些用户刷了第三方固件后不小心关掉了，结果智能音箱经常“唤醒失败”。
4.2 802.1p优先级映射：从有线到无线的“标签传递”
WMM管的是无线段，那有线端呢？这就轮到802.1p了。它是在以太网帧的VLAN标签里塞了3个bit的优先级字段（0-7）。数值越大，优先级越高。
我在项目中遇到过这样一个坑：客户家里装了全屋智能，核心交换机是网管型的，但AP接在傻瓜交换机上。结果呢？AP发出的802.1p标记到了傻瓜交换机直接被剥离了，优先级信息全丢。从那以后，我坚持所有接入层交换机都支持802.1p透传。
这里给出一张我常用的映射表，把WMM的AC和802.1p对应起来：
| 802.1p优先级 | WMM AC | 典型设备 |
|---|---|---|
| 7 | AC_VO | 智能门铃、紧急报警面板 |
| 6 | AC_VO | 语音助手（唤醒流） |
| 5 | AC_VI | 安防摄像头主码流 |
| 4 | AC_VI | 视频门铃、子码流 |
| 3 | AC_BE | 传感器数据、状态上报 |
| 2 | AC_BE | 手机App控制指令 |
| 1 | AC_BK | 日志上传、固件下载 |
| 0 | AC_BK | 背景流量、P2P同步 |
4.3 智能家居设备流量整形：别让“突发”冲垮网络
流量整形（Traffic Shaping），说白了就是“限速但不丢包”。智能家居设备有个特点：平时几乎没流量，但一有事件就是突发。比如摄像头检测到移动，瞬间上传一段1080p视频；智能门锁被触发，立刻上报一条带图片的日志。
如果不做整形，这些突发流量会瞬间占满上行带宽，导致其他设备的控制指令延迟。我常用的策略是“令牌桶”算法——允许短时间突发，但限制平均速率。
以OpenWrt为例，一个典型的整形配置：
# 对摄像头子码流做整形：限制上行512kbps，允许突发1MB
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbit ceil 1mbit burst 1m
# 匹配摄像头MAC，将流量导入class 1:10
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
match u32 0x001122334455 0xffffffffffff at -12 \
flowid 1:10
这段代码的意思是：给摄像头单独开一个“车道”，平均速度512kbps，但允许瞬间冲到1Mbps。这样既保证了视频流畅，又不会把上行带宽吃光。
4.4 带宽保障策略：给关键业务“划拨专线”
带宽保障（Bandwidth Guarantee）和流量整形是两回事。整形是“限制上限”，保障是“保证下限”。对于智能家居来说，真正需要保障的是两类流量：
- 控制指令：开灯、关窗帘、解锁门——这些数据包很小，但延迟必须低。我建议给这类流量预留至少1Mbps的“专线”。
- 安防视频：主码流通常需要2-4Mbps上行。如果家里有4个摄像头同时上传，就需要保障8-16Mbps。
在实战中，我推荐使用“分层保障”策略：
- 第一层：保障（控制指令 + 安防主码流）——预留总带宽的40%
- 第二层：尽力保障（视频子码流、传感器数据）——预留总带宽的30%
- 第三层：共享池（娱乐流量、下载、OTA）——使用剩余30%
举个例子，你家上行带宽是50Mbps，那么：
- 控制指令 + 安防主码流：保证20Mbps
- 子码流 + 传感器：保证15Mbps
- 其他流量：共享15Mbps，互相竞争
这样即使有人在下载大文件，门铃对讲也不会卡顿。
4.5 一张图看懂QoS配置全流程
下面这张SVG图，我把整个QoS配置的逻辑串起来了——从设备识别、优先级标记、流量整形到带宽保障，每一步都对应着具体的配置动作。
4.6 避坑指南：我曾经踩过的三个坑
最后分享几个实战中容易翻车的地方，都是我用真金白银换来的教训：