摘要

  • RFC 938 规定：若 DATA 包的序号处于确认窗口内、但目的端口未知，IRTP 接收方发送带有当前 rcv_nxt 的 PORT NAK，并丢弃该数据。
  • 该响应确认的是截至该序号边界的接收进展，拒绝的是端口号。它不能证明应用读到、解析、授权、保存或完成了这份负载。

今天，人们常把“已送达”当作一个无须拆解的结果。它可以出现在网络监控、产品日志、客服工单和事后报告中，仿佛一个词已经覆盖了数据包到达、服务接收、请求校验、权限判定和业务完成。1985 年的 RFC 938 却留下了一个很小、很克制的反例：PORT NAK。它让接收方承认包序列的接收，同时明确否认本地端口的归属。

这份 Internet Reliable Transaction Protocol 文档是实验性/提议性规范，RFC 信息页 清楚标明了这一点。因此，本文不能把规范写成部署史、流量史或成功率报告。它证明的是一项设计主张：一个共同的协议状态可以精确记录自己观察到的事实，却不替本地进程承担接收的责任。

IRTP 位于 IP 之上。RFC 791 说明，IP 的 Protocol 字段用于标识下一层协议；IANA 的 Internet Protocol Numbers 注册表 目前将编号 28 列为 IRTP，并引用 RFC 938。这是命名空间协调证据，不是某个系统安装、运行或仍在使用的证据。

八个八位组里放着两道问题

IRTP 的包头仅八个八位组，包含包类型、端口号、序号、长度和校验和。规范定义五种类型：SYNCH、SYNCH ACK、DATA、DATA ACK 和 PORT NAK。简短不等于含义单一。序号属于两个主机之间的可靠接收状态；端口则指向应当处理数据的上层协议或本地进程。

一个进程可以认领多个端口，但同一个端口号只能由一个进程认领。更关键的是，IRTP 的连接关系按远端 Internet 地址建立，是主机对主机的关系，而不是每一对“主机加端口”各有一条连接。模块的连接表保存 snd_nxt、rcv_nxt、snd_una 等变量；SYNCH 与 SYNCH ACK 用于建立或重新同步这份主机对主机的状态。

所以，端口不是可靠连接本身的名字。它是在一个已经存在的主机间状态中，数据试图寻找本地接收者时才出现的分派问题。把“序列进展”与“端口有人认领”写成同一个成功状态，正是 RFC 938 避开的偷换。

先判断序列，后查询端口

接收过程的顺序尤其重要。收到 DATA 包后，IRTP 模块先判断该包的序号是否落入确认窗口。对于落入窗口的包，它重新计算 rcv_nxt，然后才判定端口是否已知。

若端口已知，规范允许接收方在发送 DATA ACK 后把数据排入用户进程队列。若端口未知，则发送 PORT NAK，并丢弃数据。在这两类回应中，序号字段都带有当前的 rcv_nxt。同一份回应因此可以包含两项边界清晰的事实：主机间的接收累计到了哪里；本地端口查询的结果是什么。

RFC 938 并未把这件事留给读者猜测。它说，PORT NAK 确认接收到序号字段所列号码之前的所有包号；它 NAK 的是端口号，“不是包号”。这不是要求对端重发当前序号，也不是向某个应用授予处理该负载的资格。数据已经在分派边界被丢弃。

这句话允许我们作出一种有限却可靠的解释：接收模块可以报告连续接收的进度，却不承诺那个本地服务存在。它不能让“传输层看见了这个包”升级为“应用收到了这条消息”。

接收、分派与结果不是同一份证据

PORT NAK 的抓包记录最多支持两类结论。其一，IRTP 模块把传入 DATA 包视为处于相关的接收范围内，并报出了一个累计的 rcv_nxt 边界。其二，在那一刻，它不知道有进程认领了该端口。结论到此为止。

它不能证明应用读取字节、语法校验通过、远端身份可信、权限获得批准、记录被写入，或人员任务已经完成。它也不能证明服务永远不存在；端口认领是本地且可能随时间变化的状态，NAK 只记录了一次状态下的观察。

把证据拆成三层会更诚实。序号证据属于两个主机模块之间的传输关系。端口认领证据属于接收方的本地映射。若存在应用结论，它又属于另一个控制面：解析规则、身份、权限、事务与持久化各有自己的责任人。前两层都没有资格替最后一层说话。

这正契合 Heng Lu Note 64 所强调的界限：共同层可以采用最小、确定、可在本地验证的规则；后续选择仍是本地、自愿的选择。一个线上的确认可以说明该线自身的状态，却不能替未认领端口的进程作出承诺，也不能替组织决定一份负载的意义。

“可靠”没有规定一切运营策略

RFC 938 提供了校验、同步、确认和重传的框架，却没有规定唯一的计时器或重传策略。它要求实现必须有触发重传的机制，并重传 snd_una，但具体怎样计时、怎样评估性能，仍留给实现者。这是共同语法没有吞并本地操作决策的另一个例子。

该文还要求在获知远端地址时遵守两分钟静默期，并参照 RFC 793 的相关讨论。这是一项受限的设计参照；它不意味着 IRTP 就是 TCP，不意味着两者包语义相同，也不提供共同部署的证据。

因此，协议名中的 reliable 不等于应用端点必然存在，transaction 也不等于某项业务或人的事务已完成。规范所承诺的是受限的序列处理和受限的端口分派结果；它保留了两者之间的空隙。

让审计记录保留这条空隙

面对 PORT NAK，应记录远端地址、端口、收到的序号、返回的 rcv_nxt、适用窗口、连接状态世代、校验结果、包类型、同步往来和当时的端口认领状态。计时和重传策略也应单独保存，因为 RFC 938 有意没有把它们统一规定。

有了这些记录，调查才可区分：包是因为端口无人认领被拒，还是在端口查询之前已经因校验和或窗口条件失败；这是重新同步，还是服务缺席；对端的重传是协议反应，还是应用接受的迹象。把一切塞进“投递失败”计数器，会让不同控制面的线索一起消失。

来源与限制

RFC 938 支持本文关于包头、连接状态和 PORT NAK 的陈述；其信息页支持实验性/提议性状态；RFC 791 仅支持 IP Protocol 字段的角色；RFC 793 仅用于静默期的比较；IANA 支持编号 28 的注册事实。它们均不量化采用率、流量、性能或当今使用情况。

这些来源也不让 PORT NAK 成为安全结论或业务结论。一份确认可以在自己的层次完全真实，同时拒绝替下一层虚构一个接收者。