摘要

  • IPv4 最早用优先级和服务类型表达愿望；DiffServ 后来让六位 DSCP 选择逐跳行为，同时把分类、计量、整形、监管和重标记放在策略边界。
  • DSCP 不是预约凭证。AF 与 EF 只有在本地资源、入口规则和跨域约定彼此吻合时才形成服务；接收网络始终可以接受、翻译、归零或拒绝外来的标记。

报文先到达的不是队列，而是边界

假设企业网给一段语音流标上 Expedited Forwarding。企业自己的出口按配置把它送进短队列，并给这类流量留出一定服务速率。报文进入运营商网络时，那六个位仍然清楚可见，但其中没有客户身份、购买记录、流量额度，也没有运营商签字承诺的容量。

入口设备因此必须重新判断。它可以依据地址、端口与用户关系分类，检查速率是否越界，保留原标记，也可以改写、降为默认或丢弃。一个报文在前一个链路受到优待，并不使后一张网络负有同样义务。

这正是 DiffServ 最重要的制度设计：字段跨越边界，队列主权留在本地。

1981 年的 TOS 是一种愿望表达

RFC 791 在 1981 年定义 IPv4 时，给 Type of Service 留出一个八位组。三个位表示优先级，其余指示低时延、高吞吐或高可靠等抽象偏好。发送方不用理解 ARPANET、卫星网或其他底层网络的全部机制，就能告诉中间系统自己希望得到哪类处理。

规范同时留下了重要限制。Network Control 优先级只打算在网络内部使用，真正如何使用、由谁控制，交给每张网络自行决定。网络若在意高优先级被滥用，就必须自己限制访问。发送者能够填写字段，不等于它因此取得资源资格。

到 1992 年，RFC 1349 把隐藏的问题写得更直接：TOS 严格说来只是建议机制，不适合请求服务保证。有些网络没有第二条更好的路线，自然不会因为 TOS 改变转发；应用也不能用它说明自己到底需要多少带宽、最长能容忍多少时延。

一个标记可以说明“我更在乎什么”，却不能凭空造出容量。这一失败没有被后来架构掩盖，反而成为 DiffServ 的起点。

1998 年：把不能保证变成可以扩展

若每个核心路由器都保存每条应用流、每个客户的状态，互联网规模扩大后成本会急剧上升。1998 年 12 月发布的 RFC 2474 与 RFC 2475 选择另一条路：报文携带简短分类，边界承担复杂判断，核心按聚合流执行少量逐跳行为。

IPv4 原 TOS 八位组和 IPv6 Traffic Class 的高六位被解释为 Differentiated Services 字段，其中的值叫 DSCP。低两位后来用于 ECN，不属于 DiffServ 的额外权限。

DSCP 只是选择器，不是行为本身。一台 DS 节点把代码点映射到某种 Per-Hop Behavior；多个代码点可以指向同一种行为，部分值甚至只有本地意义。PHB 描述的是一台节点对一组报文可外部观察的转发结果，通常由队列调度、缓存分配和丢弃策略实现。

“逐跳”不是措辞上的谦虚，而是责任边界。标准给出可检验的积木，没有声称一块积木就是端到端产品。

边缘变复杂，核心才有机会保持简单

DiffServ 把多字段分类、计量、监管、整形和标记集中到入口或出口。计量器检查一组流量是否符合画像；标记器决定 DSCP；整形器延迟超前到达的流量；监管器可丢弃超额部分。内部节点看到的是已经清理过的行为聚合，无须知道每位客户的合同。

一组采用共同服务配置与 PHB 定义的连续节点构成 DS domain。这个“域”首先是行政与策略范围，才是拓扑范围。域内节点需要以一致方式理解被接受的代码点，入口则决定哪些外部陈述有资格进入这个信任环境。

六个位之所以够用，正因为它们没有装下所有东西。客户是谁、购买了什么、额度多少、超额如何处理、相邻运营商怎样结算，都留在分类器、配置与协议外的约定里。薄字段依赖厚证据，却不冒充厚证据。

AF 的“保证”取决于谁真正分配资源

1999 年的 RFC 2597 定义 Assured Forwarding。它安排四个独立类别，每类又有三档丢弃优先级。网络拥塞时，同一类别中较高丢弃优先级的报文应更容易被丢弃；属于同一微流的报文不能仅因丢弃档位不同而被重排。

AF11、AF21 等名称很容易被看成一张全球套餐表，但规范没有规定某个类别必须比另一个类别多拿多少带宽或缓存。实际“保障”取决于运营者分配的资源、当时负载和报文的丢弃优先级。符合 DiffServ 的节点也不必实现 AF。

域边界还可以整形 AF 流量、丢弃超额报文、调整丢弃档位，甚至换到另一 AF 类别。只有入口画像与域内资源计划互相匹配时，标记才具有稳定意义。数字不能替配置完成分配。

EF 再快，也只定义一台节点

Expedited Forwarding 的名字更像硬承诺。RFC 3246 在 2002 年重写 EF 规范，要求声称实现 EF 的节点在受限条件下提供不低于配置值的服务速率，并给出衡量误差与时延的方法。

但它随即划线：规范定义的是单节点行为，多节点集合不在本文范围；一台 DS 节点也不因符合 DiffServ 就必须实现 EF。要让整条路径低丢包、低时延，每个相关节点都要分配资源，进入的流量也不能突破保持短队列所需的边界。

前一台路由器的诚实实现无法命令后一台；一个代码点也不能把不存在的互联协议或商业合同变成可用带宽。标准拒绝夸大自己，反而让 EF 成为能被测量的局部承诺。

合同留在字段之外

RFC 2475 使用 SLA 和 TCA 描述服务与流量条件。RFC 3260 后来说明，这些“协议”还会包含价格、可用性与商业责任，超出 DiffServ 技术规范的范围，于是用 SLS 与 TCS 指称较窄的技术参数集合。

词语调整背后是清晰分工。IETF 可以规定字段格式、PHB 的符合性和节点该怎样表现；它不能替客户购买服务，替运营商安装容量，或替两家网络确定违约责任。

因此，入口发现不可接受的 DSCP，可以丢弃或改成域内可接受的值。来自没有增强服务约定的网络，标记可以归零为 Default。完成入口清理后，如果内部节点仍遇到没有映射的代码点，通常应按默认行为转发，而不是擅自授予未知特权。

谁都能写的标记，不能自己证明资格

DSCP 没有认证能力。端系统可以填写高待遇代码点，攻击者也可能修改没有完整性保护的外层 IP 头。如果伪造流量耗尽增强类别的资源，“偷服务”就会升级为拒绝服务。

DiffServ 的防线不是相信字段，而是边界调节。入口检查标记是否符合流量与策略，内部节点再依赖已经归类的聚合。隧道解封装也是一条新边界：内层标记即使受到密码学保护，也只证明它没有被改，并不证明下一个域曾同意接受它。

一个共享报头里的声明是待核验证据，不是自动生效的命令。这条安全结论也是治理结论。

从有线到 Wi-Fi，复制位仍然不等于复制含义

2015 年的 RFC 7657 指出，端点无法知道某个 Class Selector 在一张具体网络里对应哪种 PHB，更不用说端到端。常被用于低努力服务的 CS1，在不提供该服务的网络里可能按默认或更高待遇转发，也可能被重标记或丢弃。

2018 年的 RFC 8325 又把问题带到 Wi-Fi 边界。IP 的 DSCP 与 IEEE 802.11 的 User Priority 是两套分类空间，接入点必须做映射；如果找不到相应服务，结果可能就是 Default。真正需要互操作的是政策与行为，不是表面相同的数字。

最小共同层不负责替他人作决定

DiffServ 没有让六个位统治互联网。它让六个位在不吞并本地决定权的条件下协调运行系统。标准提供共同词汇与可测试的节点行为；运营者提供队列、容量与准入规则；客户和相邻网络提供画像与约定；边界设备把这些事实汇合。

这套架构能够扩展，恰恰因为它拒绝把标记变成对他人资源的可携带权利。报文可以请求，配置过的节点可以回答。没有任何报头字段能自行成为下一张网络的主权者。

来源与证据边界

历史与 TOS 语义来自 RFC 791、RFC 1349；DS 字段和总体架构来自 RFC 2474、RFC 2475；AF 与 EF 来自 RFC 2597、RFC 3246；后续边界问题来自 RFC 3260、RFC 7657、RFC 8325。这些标准不能证明当代某家运营商的队列配置、客户资格、商业协议、部署比例或实际端到端性能。