2. QoS服务模型：三种模型的对比与选型
聊到QoS，咱们得先搞清楚一个根本问题：网络到底该怎么给不同的流量“排座位”？
我做了十几年交换芯片，见过太多团队一上来就堆硬件资源，结果发现流量调度还是乱成一锅粥。说白了，QoS不是靠蛮力，而是靠策略。而策略的根基，就是服务模型。
今天咱们把三种主流模型掰开揉碎了讲。嗯，先看一张总览图，心里有个谱。
2.1 Best-Effort 服务模型
这是最原始、最朴素的模型。你想想看，早期的互联网就是靠这个跑起来的。
核心思想：网络尽力把数据包送到目的地，但不做任何承诺。丢包？重传。延迟？忍着。说白了，就是“能送就送，送不了拉倒”。
在硬件设计上，Best-Effort 模型几乎不需要额外的逻辑。一个简单的 FIFO 队列，配上轮询调度，就搞定了。我早期做的一款 10G 交换机，用的就是纯 Best-Effort。那时候流量小，问题不大。
硬件实现要点：
- 单个队列，FIFO 出队
- 无优先级判断
- 无拥塞避免机制（最多加个尾部丢弃）
- 调度器：最简单的 Round-Robin 或严格优先级
注意：千万别在实时业务上用 Best-Effort。我曾经见过一个团队把 VoIP 跑在纯尽力而为的网络上，结果通话质量惨不忍睹。嗯，后来他们老老实实加了 DiffServ。
2.2 IntServ（综合服务）模型
IntServ 是另一种极端——它试图给每个流都提供“VIP 通道”。
核心思想：在数据传送之前，先通过 RSVP（资源预留协议）信令，沿着路径逐跳申请带宽。每个节点都要为这个流预留资源，保证端到端的服务质量。
听起来很完美，对吧？但问题出在可扩展性上。
我参与过一个运营商级交换芯片的项目，当时客户要求支持 IntServ。我们算了一笔账：如果每个流都要维护状态，那一个 10G 端口上可能同时有几百万个流。芯片内部的流表、调度器、计数器……全部爆炸。
我个人习惯：只有在网络规模很小（比如企业园区网的核心层），或者对延迟有极致要求的场景（比如高频交易），我才会考虑 IntServ。否则，还是绕道走吧。
硬件实现要点：
- 需要维护每流状态（流表、带宽计数器）
- 支持 RSVP 信令处理（控制平面）
- 精确的整形器（Shaper）和调度器
- 资源预留的准入控制
2.3 DiffServ（区分服务）模型
DiffServ 是我个人最喜欢的模型。它聪明地避开了 IntServ 的坑，又比 Best-Effort 多了控制力。
核心思想：把流量分成几个大类（比如金、银、铜），在网络入口处打上 DSCP 标记。核心节点只看标记，按类处理，不再关心单个流。
你想想看，这多适合硬件实现？
我在设计一款 25.6T 的交换芯片时，用的就是 DiffServ 架构。我们在入口做了 8 个优先级队列，每个队列对应不同的 PHB（逐跳行为）。核心调度器只需要在这 8 个队列之间做调度，完全不用管背后有几万个流。
硬件实现要点：
- 入口分类器：根据 DSCP/IP/端口 做标记
- 多级队列：通常 8 个优先级队列
- 调度算法：WRR、SP、WFQ 等
- 拥塞避免：WRED（加权随机早期检测）
- 整形器：基于类的流量整形
// 典型的 DiffServ 队列配置示例（伪代码）
// 假设 8 个优先级队列，Q7 最高，Q0 最低
queue_config qos_config[8] = {
{ .queue_id = 7, .weight = 50, .min_th = 80, .max_th = 100 }, // 金
{ .queue_id = 6, .weight = 30, .min_th = 60, .max_th = 90 }, // 银
{ .queue_id = 5, .weight = 15, .min_th = 40, .max_th = 80 }, // 铜
// ... 其他队列
};
// 调度时，按权重分配带宽
void schedule_packet() {
for (int i = 7; i >= 0; i--) {
if (queue_has_packet(i) && queue_length(i) < qos_config[i].max_th) {
dequeue(i);
break;
}
}
}
2.4 三种模型的对比与选型
好了，三种模型都讲完了。咱们来做个对比，方便你选型时参考。
| 对比维度 | Best-Effort | IntServ | DiffServ |
|---|---|---|---|
| 服务质量保证 | 无 | 硬保证（端到端） | 软保证（统计复用） |
| 可扩展性 | 极高 | 极低（每流状态） | 高（聚合流） |
| 实现复杂度 | 低 | 高（信令+状态机） | 中（分类+调度） |
| 硬件成本 | 低 | 极高（大容量流表） | 中（多级队列） |
| 适用场景 | 普通数据、背景流量 | 小规模、高要求网络 | 大规模、多业务网络 |
| 典型协议 | 无 | RSVP | DSCP、PHB |
我的选型建议：
- 如果你在做数据中心交换机，选 DiffServ。这是目前最主流的选择，没有之一。
- 如果你在做运营商核心路由器，也是 DiffServ。配合 MPLS TE 使用，效果很好。
- 如果你在做工业控制或车载网络，且网络规模很小（几十个节点），可以考虑 IntServ。
- 如果你在做 IoT 网关或低端接入设备，Best-Effort 就够了，别浪费硬件资源。
避坑指南：我曾经在一个项目中，试图用 DiffServ 来模拟 IntServ 的硬保证效果。结果发现，在拥塞发生时，DiffServ 只能做到“优先丢弃低优先级”，无法保证高优先级流量的绝对带宽。后来我们加了严格的准入控制和整形，才勉强达到要求。记住：DiffServ 是“区分”，不是“保证”。
好了，三种模型就聊到这里。下一节咱们会深入 DiffServ 的硬件实现细节，包括 DSCP 标记、PHB 行为、以及队列调度器的具体设计。嗯，到时候我会拿出一些真实的芯片设计案例来分享。
公众号:蓝海资料掘金营，微信deep3321