摘要

  • CATS 会结合计算资源与网络条件选择服务实例。RFC 10054 要求：客户端移动且服务有状态时，应用应明确表明是否允许路由系统启用 CATS。
  • 改变转发路径、维持流的实例亲和性、把应用上下文安全地移到另一站点，是三个不同结果。更低的时延不证明新站点能接上原会话。

站点有余量，不代表它拥有会话的上一页

设想一个为现场设计协作提供实时渲染的服务：工程师在平板上旋转模型、标注零件，边缘站点根据连续输入返回下一帧。工程师离开原来的接入区域后，另一站点也许更空闲，路径也更短。网络可以据此挑选目的地，但它看不见应用保存的操作上下文是否已经到位。

RFC 10054 讨论的正是这个边界。计算感知流量调度（CATS）把计算能力和资源状态与网络状况一起用于实例和站点选择。单看物理距离容易选错：最近的站点可能没有足够算力或所需的计算资源，负载也会变化。客户端移动后，原先合适的服务实例未必仍然合适。

从路由角度看，CATS 可以不要求应用参与每次路径选择，也能服务于有状态和无状态应用。这样的透明性有用，但它只说明网络如何挑选服务接入点，并没有让应用状态变得透明。RFC 10054 进一步指出，客户端移动且服务有状态时，应用必须明确表明是否允许路由系统启用 CATS。缺少这个表示，中途调度可能让不同服务站点的应用上下文互不一致，甚至中断服务。

这里的“允许”不能扩大解释。RFC 10054 没有规定统一的信令格式、应用接口、用户确认界面或法律授权流程，也没有说一个允许标记就能证明上下文已复制完成。它要求应用就这一类调度作出明确的运行层表示；状态传输和恢复是否正确，仍需服务本身给出证据。

三种连续性被一个词掩盖

运维中常把三件事都叫作“切换”。第一，路由把包送到另一个站点。第二，流继续归属于同一个服务接入实例和路径，避免包乱序或时延突然波动。第三，应用把会话上下文迁移并恢复，之后的交互仍建立在正确历史上。前两项属于网络转发与亲和性，最后一项属于服务状态转换。

RFC 10053 把服务接入实例亲和性描述为：同一流的包继续到达同一实例并沿一致路径转发；它同时指出，框架本身并未提出定义或强制该亲和性的机制。RFC 10054 的 R14 要求有状态会话和事务保持逐流实例亲和性；R15 要求网络节点不要为了亲和性保存应用特定的逐流状态；R16 则建议在终端或服务实例移动时支持连续性。

这组要求划出架构难题，却不是现成的迁移协议。网络需要足够的信息让流的处理保持一致，但不应因此变成应用状态仓库。应用必须说明某一类会话是否可移动，以及什么状态需要复制、重建或留在原地。RFC 10054 的 AR/VR 例子就把可复用的基础资源与依赖客户端输入的有状态处理区分开来。新站点收到下一批包，并不能单独证明下一帧使用了正确的历史输入。

因此，度量可以帮助筛选目的地，却不能证明应用上下文已就绪。路由表的变化不是状态恢复回执；新站点可达，也不代表长事务没有语义断裂。若系统仪表盘只记录“流量已切换”，它仍没有回答服务是否真正续上。

这是一份要求说明，不是部署证明

RFC 10054 是经 IESG 批准发布、代表 IETF 社区共识的 Informational 文档，但不属于 Internet Standards Track。它的问题陈述和要求面向单一管理域的场景。它明确了需要解决什么，并不能证明某个运营商已能安全迁移所有服务，也没有为跨供应商状态共享背书。

所以“支持 CATS”不应只是一个产品标签。运行合同应说明哪些服务和会话类别可迁移、什么事件让迁移成为候选、由谁给出允许表示，以及切换前需要哪类状态就绪证据。一次彼此独立的请求，不应自动套用依赖原站点上下文的长会话策略。

没有明确表示时，稳妥的运行选择是保留现有有状态流的亲和性，直到应用自己的迁移流程接手；也可以只对新请求作新的选址决定。这是运维建议，并非额外的 RFC 要求。它防止资源利用率改善被误报成服务连续性。

资料与状态