摘要

  • RFC 1257 认为，等时应用并不要求路径上的每一种网络都让数据包等间隔到达。只要容量足够，并且最大传输时延有已知边界，网络就能承担一个更窄的共同承诺。
  • 发送端记录生成时间，接收端先把数据放入缓存，到“生成时间加最大时延”时才处理。到达、缓存接纳、时钟一致性、进程唤醒和最终播放因此是五类不同证据。
  • 后来的综合服务架构仍要求交付时间可被约束；RFC 2212 更明确地保证最大时延而不追求最小化抖动，并要求播放应用把提前到达的数据留在接收端等待截止时刻。

用户感受到的节拍并不是链路上的到达间隔

电话按固定周期采样声音，定码率视频编解码器也按固定周期生成数据。最终设备若不能按规律输出，听众会听到失真，观众会看到闪烁。20 世纪 90 年代初的高速网络研究很容易由此推出一个要求：既然应用怕抖动，网络就必须同时控制带宽、时延和抖动。

RFC 1257 没有否认人的感受，也没有把交互时延说成无关紧要。它只把“数据包何时到达主机”与“应用何时处理数据”分开。前者可以有变化，后者仍可恢复为固定节拍。对于由不同技术拼接而成的互联网，这意味着不必让每个子网实现同一种抖动控制，仍有可能满足应用的规律输出。

这里的关键不是降低目标，而是重新划定承诺的主人。

网络交付的是上界，不是节拍器

RFC 1257 的构造先假定一条信道具有足够带宽，并能约束最大传输时延；至少接收端知道这个上界。一个数据单元可能很快到达，下一个则接近截止时刻。上界并不声称两者耗时相同，只规定在所声明条件下最晚应在何时抵达。

这项假设不能被数据库中的一个数值替代。若资源没有被配置或验证，标出的最大时延不等于路径属性。若实际路径改变，旧边界未必覆盖新路径。若发送流量超过可用容量，缓存不能制造缺失的带宽。若数据丢失，其他数据按时到达也不会把它补回来。

因此，这是一项在明确前提下的充分性论证，不是对 1991 年互联网普遍服务质量的测量。

提前到达被转换成缓存停留时间

发送端在每个数据单元生成时写入时间戳，并使用一个共同的时间基准。接收端收到数据后立即放进缓存。RFC 1257 设想的缓存容量等于信道带宽乘以最大到达间隔变化；在最保守的情况下，可以把这一变化取作最大时延。

数据不是一到就处理。应用等到“生成时间戳加最大传输时延”才取出它。早到的数据在缓存里停留得久，接近上界到达的数据停留得短。网络时延的变化由缓存停留时间吸收，输出仍可按生成节拍排列。

这个过程不能压成一个“已播放”状态。发送时间戳说明发送端声称何时生成。时钟来源、偏差和不确定性说明两端时间是否可比。到达时间描述实际观察到的路径。缓存接纳和占用说明数据是否被保留。调度记录说明应用何时真正获得 CPU。播放、丢弃或掩盖说明应用的选择。用户是否听清或看顺仍是另一条记录。

准时到主机的数据仍可能等不到进程

即使网络严格按等间隔把数据送到主机接口，操作系统若不能及时调度应用，最终设备仍可能成批输出。网络节拍在主机边界处就会失效。

RFC 1257 把这点用于端到端论证：接收系统无论如何都需要规律唤醒应用的能力。一个能在网络中断到来时唤醒进程的系统，也可以按时钟中断唤醒它。若端点最终还要重新保证节拍，就没有理由把相同功能强制塞进每一种网络。

这并不是“网络无须负责”。接收端设置处理时间仍依赖足够容量和可信的最大时延。端点责任与网络责任是相接的两段，不是互相取消。

缓存没有消灭成本，只是改变成本的位置

到达变化越大，接收端可能需要的内存越多，播放等待也可能越长。RFC 1257 明确承认当时一些电话没有内存。它设想终端会逐渐拥有缓存，或者在最后一个交换节点为不能缓存的设备恢复节拍。

抖动受控的网络把队列、定时和内存放在路径中。最大时延受控、由端点恢复节拍的设计则把更多内存、时钟和软件放在接收端。两者可能给用户相似的声音，却产生不同的故障边界、采购成本和运维责任。

文档还保留了抖动控制的价值：更紧的到达分布可以减少中间节点所需的内存。“不是应用支持的必要条件”并不等于“任何地方都没有用途”。

实时需求原本就不是一个质量标签

早一年的 RFC 1193 把实时通信需求拆成吞吐量、时延、时延变化和可靠性等边界。不同应用需要不同组合。交互式谈话难以容忍过长时延；大文件传输更关心最低吞吐量；有些音视频可承受有限丢失，却不能接受任意等待。

RFC 1257 没有删除时延变化这个维度，而是追问谁必须控制它。用户需要规则输出，并不能自动推出每台网络设备必须给出规则到达。网络边界与端点状态可以共同满足需求，但前提必须留在证据链上。

“实时”也不是一次结果观察。它是一组服务要求。具体流是否达到目标，仍要检查发送负载、资源接纳、路径、逐包到达、时钟、内存、调度和应用输出。

后来的保证服务仍保留同一条边界

RFC 1633 在 1994 年总结综合服务架构时指出，早期互联网音视频实验会受可变排队时延和拥塞丢失影响。应用适应能力不能消除交付时延边界，因为人的交互和可懂度有上限。它引入资源预留、接纳控制与每流软状态，同时把对外可见的服务模型同可更换的实现机制分开。

现有来源不足以断言 RFC 1257 直接导致了 RFC 1633。不过，两份文档允许同一种责任划分：网络管理资源以给出可信时延边界，端点仍对最终处理负责。

RFC 2212 在 1997 年把这个接口写得更清楚。保证服务为合规流量给出带宽和可证明的最大端到端时延；它不试图最小化最小时延、平均时延或抖动。播放应用必须预期许多数据会早于截止时刻抵达，并在接收端缓存到处理时间。

网络承诺回答“最晚何时到”。接收缓存回答“早到之后怎么办”。两项记录彼此依赖，却不能互相代替。

规则输出不能倒推出整条路径都规则

应用可以按时播放一段用于掩盖丢失的静音。所有数据都在时延边界内到达，缓存仍可能因容量不足而溢出。时钟偏差可能把测量错误伪装成单向时延超标。数据按时抵达后，进程仍可能错过 CPU 截止时间。路径切换后，应用也可能继续沿用已经失效的旧边界。

可审计记录应同时保留：发送与接纳速率、路径或预留身份、边界与有效条件、逐单元到达、时钟来源与不确定性、缓存接纳和占用、计划与实际唤醒、迟到/丢失/重复/乱序分类、处理决定，以及真实用户结果。最终播放平滑不能授权系统补写中间证据。

来源与证据边界

主要论证来自 RFC 1257。此前的客户需求框架来自 RFC 1193。后来的综合服务架构见 RFC 1633，不最小化抖动而约束最大时延的保证服务见 RFC 2212。

这些文档不证明当前产品、流量、预留、部署、时钟精度、缓存大小、调度行为或用户体验，也不证明文档间存在直接因果继承。RFC 1257 是信息性文件；其结论受声明前提约束。