摘要

  • RFC 3234 将中间盒故障视为不同于路由器故障的问题：另选 IP 路径可以绕开故障路由器，却无法重建中间盒持有的会话状态。
  • 在一份明确说明并非定论的 22 类目录中，作者把 16 类标为硬状态、21 类标为故障后需要重启会话。

路径恢复，不代表对话接上了

最熟悉的故障图景从路由开始：一台路由器失效，网络改走其他路径，数据包重新往返。两端仍在，连接也似乎回来了。

Brian Carpenter 与 Scott Brim 于 2002 年发布的 RFC 3234 是一份信息类备忘录。它指出，中间盒（middlebox）不只是独立机箱，也可能是嵌在其他设备里的虚拟功能。凡是在数据路径上做了普通 IP 路由以外工作的节点——例如地址转换、过滤或代理——都可能不在通信两端，却仍是会话运行所必需的部分。

一旦中间盒终止一个流、再发起另一个流，故障边界便不再只是路由图。路由协议可以让数据包重新可达，却未必能恢复那台设备记住的映射或会话状态。路径好了，原来的对话仍可能无法继续。

RFC 3234 区分了软状态与硬状态。软状态丢失后，会话仍能运行，只是性能下降；系统可以再生成必要信息。缓存是直观例子：缓存临时消失，理想情况下只会变慢。硬状态则意味着状态一旦丢失，所需功能也会失效。要快速切换，备用设备必须预先拥有可用的状态副本；另一种选择是让会话两端发现故障，并通过备用设备重新建立会话。

这不是给同一台盒子再配一台盒子那么简单。软状态要求信息可重建；故障切换要求备用副本足够新；重启则要求两端承认旧会话已结束，再建立一个新会话。三种方式的中断边界和协调责任并不相同。

22 是目录里的数，不是互联网的普查

作者在 22 类中间盒里标出 16 类具有硬状态、21 类故障后必须重启会话。这组数让架构问题一目了然，却只是作者对该目录的粗略分类，不是全球部署统计或故障频率测量。RFC 3234 明说其分类带有主观性，也不声称完整或定论。

它的建议倒很明确：中间盒设计必须包含清楚的故障处理机制。备忘录还指出，不能假定不同协议层之间会自动协调。底层设备可能不知道应用层中间盒已经失效，更无从知道该把会话迁移到哪个备用节点。

多年后的 RFC 8517 从运营角度讨论一部分以传输层为中心的中间盒功能，以及操作人员用流量可见性诊断应用故障的需要。它补充了问题背景，但不能证明 2002 年的目录准确预言了今天的部署。RFC 1958 提供互联网架构背景；RFC 1812 描述普通 IPv4 路由器的职责。

RFC 3234 并没有主张中间盒全都该消失；它刻意避开了“好或坏”的二分。更持久的提醒是：路由恢复与会话连续性是两种不同的证明。探测到数据包重新可达，并不能说明状态已恢复、已复制，或已由一个安全的新会话取代。

来源