摘要

  • ALTO 成本日历为未来连续时段提供一组网络成本值，使应用不仅能选择把流量发往哪里，也能选择何时发送。
  • 这些数值是提供方发布的引导信息，不是转发命令，也不自动代表价格、时延、拥塞或可用容量。
  • 可靠部署必须校验成本类型、时间范围和所依赖的地图版本，接收最新变更，并在突发事件、更新中断或群体响应让预测失效时保留退路。

最便宜的时段是一项主张

设想一个必须在清晨前完成大规模复制的调度器。ALTO 响应显示，两个网络位置之间的成本在 02:00 后会更低，于是调度器等待。这个决定没有改变 BGP，没有预留链路，也没有要求任何路由器采用新路径。应用接受的是信息服务发布的一项主张：对这个源、这个目的地、这种成本类型和这个时间段而言，稍后优于现在。

RFC 7285 为能够从多个端点中作选择的应用定义了应用层流量优化协议。网络地图把端点归入提供方定义的标识符，也就是 PID；成本地图再发布各 PID 之间有方向的成本。

这种视图本来就是抽象的。运营方可以给出顺序排名，也可以给出并非真实计量单位的数字，从而不暴露内部拓扑、流量工程规则或商业条件。因此，数值 20 不必等于 20 毫秒、20 元或 20 条拥塞链路。若成本指标没有规定现实单位，有意义的是同一发布视图中不同选项的相对次序。

加入时间，并不会加入确定性

RFC 8896 在这一模型上增加了成本日历。服务器不再只为一对源和目的地返回单个值，而是返回覆盖连续时段的数值数组。元数据说明日历从何时开始、每段多长、共有多少段，应用因此可以决定延后型工作何时执行。

日历可能来自历史规律、计划维护或预期会重复的周期。这些是有价值的运营知识，却仍然面向未来。光纤中断、突发人流、缓存故障或路由变化，都可能把预告的低谷变成高峰。一个格式完全正确的重复日历，也可能描述一整天都已经过时的网络。

所以，时间元数据绝不是装饰。客户端要保留起始时间、时区、区间边界、成本类型，以及源和目的 PID 所依赖的网络地图版本。拿明天的数组套在今天的地图上，或因时区错误读错第三个区间，都会生成服务器从未提出过的决定。

“新鲜度”有自己的协议

基础 ALTO 允许客户端重新拉取完整资源。大地图只有少量单元发生变化时，这种做法浪费资源；需要立即调整时，它也可能太慢。RFC 8895 使用 Server-Sent Events 定义更新流，服务器可以推送完整替换，也可以用 JSON Merge Patch 或 JSON Patch 表达增量变化。

更新流是第二个控制面，而不是自动修复。客户端必须把每条事件绑定到正确资源和正确的基础版本，按顺序处理，并在连接中断时承认最后一份副本可能已经过期。一个小补丁若被套到错误日历上，可能比明确缺失的响应更危险，因为它会留下一个看似可信、实际从未被发布的计划。

因此，RFC 8896 建议成本日历配合增量更新服务。SSE 连接仍处于打开状态，并不能证明数据仍然新鲜。真正的证据是：发布方的一项改动，以相同内容、可追踪版本和有界延迟，进入调度器当前用于决策的状态。

建议会改变它所预测的对象

日历不只是描述需求，它也会搬动需求。许多客户端若同时看到同一个低成本时段，就可能一起把任务推迟过去。那个时段会因为被宣布“空闲”而变得拥挤。RFC 8896 明确要求发布方和使用方考虑这种反馈效应。

粒度因此成为治理选择。粗日历能更好地保护敏感网络信息，也不必频繁更新，却会把更多客户端赶进同一个时间桶。细日历可以更精确地分散选择，但会暴露更多运营状态，并提高更新负担。网络或许想避开昂贵链路，应用却要守住完成期限；协议能承载协调，不能消除双方目标的差异。

这些信息也可能被滥用。遭入侵的客户端可以借日历挑选看似适合发动攻击流量的时机。认证能证明建议由谁发布，却不能保证每个读取者都怀有善意。

RFC 能证明什么

固定的一手记录证明了数据模型：提供方定义的网络位置、有方向的成本、时间区间，以及完整替换或增量补丁。它也证明设计者考虑过预测过期、反馈效应、已认证但有害的引导、客户端不稳定和恶意使用。

这些 RFC 并不能证明某家运营商实际部署了 ALTO，也不能证明某个数值等于真实价格或拥塞，更不能保证某次传输一定改善。RFC 规定如何表达建议；只有具体服务与客户端的观测记录，才能证明建议当时是否新鲜、是否适用、是否有效。

来源