摘要

  • RFC 1306 记述 Cray 项目如何让一次路由查找产生对外部控制器的电路请求；控制器若有可能，再在两台主机之间的某处建立连接。
  • 电路未完成时，尝试传输数据不能自动激活电路，TCP 也不应通过该路由发送数据。
  • 最初实现曾让 TCP 重传定时器在尚未发送任何数据时就退避；后续版本为等待电路建立另设定时器，避免把控制等待误读为传输问题。

分析

路由表给出的只是下一步问题

把路由说成“通路”很方便，却会掩盖它常常只是一个选择。RFC 1306 中的源主机掌握特殊信息：它知道某个方向需要按请求方式使用电路交换网络，也知道应联系哪个交换控制器。内核在查表之后可产生控制消息，于是本地选择延伸成对另一个系统的请求。

这个顺序没有赋予本地主机更多权力。控制器在收到请求后，如果能够做到，才会建立连接。报告的条件语气保留了真实的责任边界：主机能证明自己发出了请求；控制器及其资源决定接下来能否完成；在完成信号出现前，任何“已有电路”的叙述都过早。

报告还提到路由别名。别名可把两个或多个替代路由以熟悉的路由接口呈现给源主机，但文档明确把其中的路由和政策问题留在范围外。可选项不是容量承诺，界面上的名称也不是外部资源已经分配的证明。它至多让源端知道可以向哪一种路径发起请求。

不完整不是一种可以试着用的完整

RFC 1306 给出的工程规则很严格：在不完整的连接上进行传输尝试，不得自动激活电路；电路完成之前，TCP 不得沿该路由传输数据。这里拒绝的是一种常见偷换——把应用的第一笔发送意图，转成对外部资源的默认授权。

若不保留这个边界，一连串不同的问题会被压成同一个“连接失败”。请求是否真的离开主机？控制器是否接纳？资源是否仍在建立？第一个字节是否曾进入一个完成的电路？这些问题需要不同的证据。报告用“先完成，再传输”让状态机能够被检查，而不是让重试机制和应用压力替控制器作决定。

它还描述了请求连接和中止连接两类消息。中止尤其提醒我们，已表达的意图仍可撤回。请求不是可用资源的替代品；即使请求被记录，也没有因此获得电路、带宽或传输结果。

在第一字节之前，计时器不该讲丢包故事

最有启发性的细节出现在首次数据之前。早期内核版本在交换连接建立期间会让通常的 TCP 重传定时器退避，即使尚无数据发送。后来，项目为这段建立期增加了独立定时器。

重传计时的意义本来依赖于它所测量的事件：已经发送的通信没有得到预期响应。若它在外部电路尚未完成时运行，就把“等待控制器建立路径”伪装成“已发送数据没有回应”。这不仅影响性能判断，也会污染故障记录和自动化策略。

独立定时器并不保证电路成功。它只诚实地记录一种等待中的状态。这个区分的价值正在于此：测量工具不应替没有发生的事件写结论。计时器可以报告建立期正在延长，却不应替 TCP 宣称发生了重传意义上的失败。

这是一份历史记录，不是一张当代承诺书

RFC 1306 是 1992 年 3 月的信息性项目报告，不是今天的部署普查，也不能证明现代运营商、产品或网络必然遵从同一做法。它所留下的可复用纪律更小也更坚实：路由选择、控制请求、电路完成、数据发送、传输观察和应用后果不能相互代替。

一条路线被选中，不证明电路存在；电路已完成，不证明数据送达；数据送达，也不证明某项服务、义务或商业结果已经达成。只有保留每个门槛，控制层的信息才不会越权成为现实层的结论。

来源

RFC 1306 记录的是 1992 年的项目经验；它不证明现时部署、路由权限、容量权利、电路完成、数据包送达或用户结果。