为什么需要流量整形与QoS
想象一下家里同时在看高清视频、开视频会议、刷短视频和备份数据。路由器如果只按“谁先来谁先走”，视频会议延迟高、丢包多，结果就是通话断断续续。流量整形（shaping）和QoS（Quality of Service）就是把带宽切片、控制突发、保证关键业务优先度的手段。它们的目的很简单：把有限的网络资源按价值分配，让关键流量体验稳定。
核心概念一页纸速记
- 分类（Classification）：识别流量，依据IP/端口、VLAN、DSCP或应用指纹。
- 标记（Marking）：给包打标签（DSCP/TOS/802.1p），方便后续策略识别。
- 整形（Shaping）：平滑发送速率、控制突发，通常在出口口上应用。
- 限速（Policing）：强制上限，超出直接丢弃或打低优先级。
- 排队与调度（Queuing/Scheduling）：按优先级或权重分发带宽（PRIO、WRR、CBWFQ、HTB）。
- 监控与反馈：持续观测利用率、延迟、丢包并调整参数。
实施流程（五步走）
把复杂的操作拆成五个步骤：分类→标记→整形/限速→队列调度→监控与调整。费曼法则告诉我们：把每步用一句话解释清楚，然后立即做一个小实验。
步骤详解
- 分类与打标：先识别流量边界（办公子网、语音、关键API、P2P），用ACL或mangle把关键流量打成高优先级（DSCP EF、AF4等）。
- 选择整形 vs 限速：需要保留突发但总体平滑用整形（shaping）；需严格保护其他业务免受滥用用限速（policing）。
- 决定调度算法：语音/视频用Priority或低延迟队列，通用业务用加权轮询（WRR/CBWFQ/HTB）分配剩余带宽。
- 部署在出口侧：优先在出口链路（上行/出海链路）实施，因那是瓶颈所在。
- 监控与校准：用SLA指标（延迟、抖动、丢包）验证，并根据观测数据调整速率与队列权重。
设备级实操示例（关键配置思路）
Linux（tc + iptables/iptables mangle）示例思路
Linux 的 tc 提供强大的 qdisc/class/filter 能力，HTB 用于带宽分配、TBF 用于简单整形，SFQ/RED 用于公平排队与拥塞控制。
- 分类：用 iptables mangle 标记包（MARK）或直接用 tc filter 匹配 ip/port。
- 队列：给出口设备添加 root qdisc=htb，然后创建 class（例如1:10 语音 2M，1:20 视频 5M，1:30 默认 10M）。
- 示例命令（思路，不逐字粘贴）：tc qdisc add dev eth0 root handle 1: htb default 30；tc class add …；tc filter add … fw 指向 MARK。
Cisco IOS 常用模式
Cisco 常用 class-map / policy-map / service-policy 模式。重点是先 class-map 区分流量，再在 policy-map 中用 priority（for low latency）、bandwidth（CBWFQ）、shape/ policer 控制速度。
- class-map match ip dscp ef 对语音打高优先级。
- policy-map 中用 priority 语句保障语音延迟。
- 出口接口：service-policy output POLICY_NAME。
RouterOS（MikroTik）简洁思路
RouterOS 更直观：用 mangle 标记连接/包，再在 queues tree 中按标记分配带宽与优先级。Simple queues 适合小规模，Queues Tree 适合复杂分层。
DSCP 与优先级参考表
| 类别 | DSCP | 用途建议 |
| 语音实时 | EF (46) | 低延迟队列，priority/low-latency |
| 视频/会议 | AF41/AF42 | 高权重队列，保留带宽 |
| 交互式/应用 | AF21/AF22 | 中等权重，保证响应 |
| 后台备份 | CS1/BE | 低优先级，限速或排队于最后 |
常见误区与排错技巧
- 误区一：全部都打高优先级——结果是没有优先级可用。优先级是稀缺资源，要谨慎分配。
- 误区二：policing 代替 shaping——policing 丢包直接且粗暴，shaping 更适合平滑突发。
- 误区三：只在入口或只在内部做策略——出口链路通常是瓶颈，优先在出口施策。
排错清单（快速步骤）
- 确认分类是否命中：检查 tc filter / Cisco show policy-map statistics / RouterOS mangle counters。
- 验证标记是否正确：查看 packet/byte counters 或抓包看 DSCP/TOS 值。
- 观察队列占用：tc -s qdisc / show queue interface / queues tree stats。
- 如果语音抖动高，先检查队列优先级是否被“挤占”，调整 priority 大小或增加专用带宽。
- 当整体带宽饱和且重要业务仍受影响，考虑带宽扩容或在核心业务与后台业务间引入更严格的policing。
监控指标与工具
关注这些关键量化指标：带宽利用率、接口丢包、平均延迟、抖动（jitter）、队列长度和队列延迟。工具上：
- Linux：tc -s qdisc / ifstat / iperf / sFlow/NetFlow 采集。
- Cisco：show interface / show policy-map / NetFlow。
- RouterOS：interface traffic flow / queues tree counters。
小白上手的逐步操作建议（执行脚本式）
- 确认需求：列出要保障的业务和目标SLA（比如语音延迟<50ms，视频带宽≥5Mbps）。
- 在测试环境建立小规模模型：用 tc 或 Cisco 在隔离口上模拟真实流量做实验。
- 从保守配置开始：先保证语音优先，再按权重分配其余带宽。
- 监测至少24小时不同高峰时段表现，记录异常场景并微调速率与权重。
- 上线时逐步放量，保持回滚方案（原始配置备份）。
实战中的小技巧（经验之谈）
- 把“用户感知”作为核心衡量：有时抖动降低1ms胜过带宽多100kbps。
- DSCP 标记一致性很重要：内网、出口主机与云端都要认同同一套标记策略。
- 日志与监控要自动化：定期导出队列统计，结合告警避免人为盯盘。
- 别忘了加密流量：TLS/QUIC 下无法应用应用层识别时，依赖IP/端口或流量学习模型。
写到这里，脑子里又回到家里那套场景：孩子在看视频、老婆在开会、备份在夜里跑——把这套策略按优先级部署好，晚上全家不再互相干扰，就是目标。接下来你可以按上文的五步法，在测试口快速验证一个小策略，再放大到生产链路；遇到具体命令或错误信息可以把日志贴上来，我们可以一步步看。谢谢你耐心看完这些实操要点。