扫码获取 VIP 码
添加管理员微信获取 VIP 码
QoS 的全称是 Quality of Service，中文译作"服务质量"。这个译名容易让人产生误解，以为 QoS 讨论的是"服务好不好用"之类的感性评价。实际上在计算机网络领域，QoS 是一个严格量化的技术概念，它指的是一系列使网络能够为不同流量提供差异化传输保障的机制集合。从工程角度定义，QoS 是网络设备——路由器与交换机——对 IP 数据包实施分类、标记、排队、调度、整形和丢弃策略的能力总和。
QoS 的核心目标不是让所有流量都快，而是在带宽、时延、抖动、丢包率这四个维度上为不同业务分配不同等级的资源。传统网络像一条不分车道的公路，所有车辆混行，救护车和货车一起堵；部署了 QoS 的网络则划分出应急车道和公交专用道，关键业务获得优先通行权。这种差异化处理的必要性在多媒体时代尤为突出，语音通话对这个毫秒级的时延波动都无法容忍，文件下载则对带宽敏感但对时延不敏感，不同业务对网络的要求天然不同，QoS 就是为这种差异而生。
QoS 之所以成为网络规划设计师考试的必考点，是因为它是大型网络设计的核心命题。没有任何一个企业骨干网、数据中心网络或运营商承载网能绕开 QoS。不理解 QoS 模型，就无法完成网络规划方案中服务质量保障章节的撰写，更无法在真题中准确区分三种模型的实现机制和适用场景。需要特别澄清一个概念边界：QoS 模型讨论的是"用什么架构框架来实现服务质量保障"，而不是具体的队列调度算法如优先级队列、加权公平队列或低时延队列，也不是流量监管技术如令牌桶和漏桶。那些属于 QoS 的实现工具，而模型回答的是更高层次的问题——网络应该用什么样的架构思想来管理流量？这个区分本身就是选择题中的高频考点。
网络工程领域存在一个朴素的规律：任何技术方案都是特定历史条件下的妥协产物，QoS 模型的演进也不例外。理解三大模型产生的时代背景和各自面临的核心矛盾，比死记硬背它们的特征更加重要。
Best-Effort Service，中文译为"尽力而为服务模型"，是互联网与生俱来的默认 QoS 模型。它的设计思想极其简单：网络对所有 IP 数据包一视同仁，采用先入先出队列进行转发，不提供任何带宽预留、时延保障或丢包率承诺。路由器尽力转发每一个包，但如果拥塞发生，该丢就丢，没有任何特殊照顾。
这种模型在今天的语音视频时代听起来不可思议，但在互联网诞生初期却是一个精妙的设计选择。TCP/IP 协议栈的设计者们面临一个取舍：如果要求网络核心提供复杂的状态管理和资源预留，路由器就必须维护每条流的上下文信息，这对早期硬件来说是灾难性的性能开销。Best-Effort 模型将智能推到了网络边缘，即端主机上的 TCP 拥塞控制机制，让核心路由器保持极简。这个"边缘智能、核心傻瓜"的哲学至今仍是互联网架构的根基。
Best-Effort 模型的优点显而易见：实现成本为零，扩展性无限，所有路由器出厂即支持。缺点同样致命：无法区分语音、视频、数据等不同业务的传输需求。在早期以电子邮件和网页浏览为主的流量模式下这不是问题，但实时通信的爆发式增长让 Best-Effort 走到极限。你能接受电话通话每隔几秒就断一次吗？答案显然是否定的。正是这个需求推动了 IntServ 的诞生。
Integrated Service，简称 IntServ，中文译为"集成服务模型"。它诞生于二十世纪九十年代初期，IETF 在 RFC 1633 中正式定义了这一框架。IntServ 的核心思想非常直接：既然 Best-Effort 的问题在于不区分流量，那就让应用程序在发送数据之前先向网络申请资源，获批之后再开始传输。这就像打电话之前先确认线路空闲——在信令层面完成资源协商再开始数据通信。
IntServ 定义了三种服务等级。第一类 Guaranteed Service（保证服务）提供严格的带宽和时延上限，适用于对时延极度敏感的实时语音业务。第二类 Controlled-Load Service（受控负载服务）不承诺绝对时延上限，但保证即使在网络拥塞时也能获得与轻载网络近似的服务质量，适用于视频会议等有一定容忍度的实时业务。第三类就是默认的 Best-Effort，不提供任何保证。这三类服务的层次感非常清晰，但问题出在它们的实现机制上。
实现 IntServ 的核心信令协议是 RSVP，全称 Resource Reservation Protocol（资源预留协议）。RSVP 的工作流程可以概括为"先探路再预留"：发送方先向接收方发送 Path 消息，沿途路由器记录路径信息并积累路径特征如可用的最大带宽和最小时延；接收方收到 Path 消息后，沿原路回传 Resv 消息，携带具体的资源预留请求，包括期望的带宽大小和时延上限；路径上的每台路由器检查自己是否有足够的资源，有则预留并将请求向上一跳转发，没有则拒绝并返回错误。
IntServ 在学术上非常优雅，但在工程实践中遭遇了致命问题——可扩展性。因为 RSVP 要求沿途每一台路由器都为每条数据流维护独立的软状态，需要定时刷新，过期则删除。这意味着网络核心路由器可能需要维护数百万条流的状态信息，对路由器的内存和中央处理器是灾难性的负担。此外，IntServ 要求全网所有路由器都支持 RSVP，在异构网络中部署几乎不可能。IntServ 并未完全消亡，它在 MPLS 流量工程等特定场景中仍然发挥着重要作用，但它显然不可能成为互联网级别的 QoS 方案。它的失败催生了 DiffServ 的诞生。
Differentiated Service，简称 DiffServ，中文译为"区分服务模型"。IETF 在 RFC 2474 和 RFC 2475 中正式定义了这一框架。DiffServ 的设计者们从 IntServ 的失败中吸取了最关键的一条教训：不要试图在互联网核心维护逐流状态。他们提出的替代思路极为务实——把复杂的分类和标记工作全部推到网络边界，核心路由器只根据数据包头部的一个固定字段做简单的逐跳行为选择。这就是 DiffServ 的精髓：边缘复杂、核心简单。
具体来说，DiffServ 的工作方式是：当数据包进入 DiffServ 网络域时，边界路由器检查数据包的五元组信息，包括源 IP 地址、目的 IP 地址、协议类型、源端口和目的端口，根据预设策略在 IP 头部的 DS 字段中写入一个 DSCP 值；核心路由器收到数据包后，只读取 DSCP 值，查表得到对应的 PHB，然后按照 PHB 定义的队列和丢弃策略转发数据包。整个过程核心路由器不需要维护任何流状态，始终只面对有限数量的 DSCP 类别——这从根本上解决了 IntServ 的可扩展性问题。本质上，DiffServ 是在 Best-Effort 的简单性和 IntServ 的确定性之间找到了一个工程上可行的平衡点，这也是它在实际网络中大规模替代 IntServ 的根本原因。
DiffServ 对 IP 协议做出的最重要修改，是重新定义了 IPv4 头部中的服务类型字段。在传统 IP 协议中，这个 8 比特字段的前 3 位用于 IP 优先级，后 5 位包含时延、吞吐量、可靠性、成本等标志位，这些标志位几乎从未被实际使用。DiffServ 将这 8 个比特重新命名为 DS 字段，即 Differentiated Services Field，其中前 6 位称为 DSCP，即 Differentiated Services Code Point（区分服务代码点），后 2 位预留给显式拥塞通知功能使用。
理解 DSCP 的关键在于它本质上是一个索引值——它告诉路由器"把这个数据包归到哪一类"，而真正的转发行为取决于路由器配置的 PHB，即 Per-Hop Behavior（逐跳行为）。DSCP 值本身不直接对应"优先级高"或"优先级低"，它需要通过 PHB 来解释和执行。这种解耦设计是 DiffServ 的精巧之处：同一个 DSCP 值可以在不同网络域中映射到不同的 PHB，实现策略的灵活定制。例如，运营商 A 可能将 DSCP 46 映射到严格的优先队列，而运营商 B 可能只给它一个加权公平队列的较高权重——数据包上的标记不变，但网络对它的处理方式可以按域自定义。
PHB 是 DiffServ 模型中真正决定数据包命运的部分。IETF 定义了两大类标准的 PHB，每一类都可能出现在真题中，必须掌握它们的特征和对应关系。
确保转发，英文名 Assured Forwarding，简称 AF。AF 的核心设计是保证概率而不保证带宽——网络承诺在拥塞时以一定概率转发你的数据包，但不会承诺一定不丢。AF 被划分为四个等级，即 AF1 到 AF4，每个等级内部又包含三个丢弃优先级，分别是低、中、高，共计十二个 AF 类别。等级的数值越大代表转发优先级越高，而丢弃优先级在数值上越小代表越不容易被丢弃——即"低"的丢弃优先级高于"高"的丢弃优先级。命名格式如 AF31 表示等级 3、丢弃优先级 1（低丢弃概率）。常见的映射场景是将 AF4 分配给信令流量，AF3 给实时视频，AF2 给关键业务数据，AF1 给普通数据。真题中经常考察"AF41 和 AF13 哪个优先级更高"这类陷阱题，答案是 AF41，因为等级 4 高于等级 1，与丢弃优先级无关。
加速转发，英文名 Expedited Forwarding，简称 EF。EF 的设计目标是提供低时延、低抖动、低丢包率的虚拟专线服务，适用于对端到端时延有严格要求的实时业务。EF PHB 的核心机制是：路由器为 EF 流量分配一个优先队列，确保 EF 数据包的离开速率不低于配置速率，从而将端到端时延和抖动控制在一个很小的范围内。EF 的推荐 DSCP 值为 101110，换算为十进制即 46，这是一个高频考点。在真题中还出现过直接问"哪个 DSCP 值对应最低时延服务"之类的变形，答案一律指向 EF。
除了 AF 和 EF 之外，还有一个默认 PHB，对应的 DSCP 值为全零，即 000000。默认 PHB 就是传统的 Best-Effort 行为，不提供任何服务质量保障。所有不支持 DiffS
本篇完！