摘要

  • RDP 负责让一条连接里的消息最终可靠送达，却不强制所有应用按发送顺序接收；顺序模式在 Open 时选定，并贯穿该连接。
  • 累积 ACK 只越过连续到达的边界，EACK 则点名缺口之后已经正确收到的报文段，使发送端只补丢失部分。
  • 传输层收到、用户缓冲区可见和应用完成是三份不同证据；RST 关闭、NUL 响应或 IANA 的协议号 27 都不能替代应用回执。

一条缺口，两份真实记录

设想发送端依次发出 100、101、102、103。101 在途中丢失，102 和 103 完好到达。接收端此时不能说连续序列已经走到 103，因为 101 的缺口仍在；它也没有理由假装 102 和 103 不存在。

RFC 908 用两类确认同时保存这两件事。普通 ACK 指向最后一个连续正确收到的报文段。扩展确认 EACK 把已经正确收到但顺序超前的号码列出来。于是发送端知道 101 需要重传，也知道 102、103 不必跟着再发一遍。

EACK 没有把缺口抹掉。接收窗口的左边缘仍由连续序列决定。后续报文段即使不断获得 EACK，也会逐渐逼近右边缘；只要 101 没有补上，新发送最终就要停下来。这是一套节省无谓重传的证据机制，不是一条绕开丢失、无限前进的旁路。

可靠并不自动等于排队

RDP 面向远程装载、内存转储和调试这类以消息为单位的工作。把一幅内存镜像送到远端时，任何一块永久缺失都不可接受，因此序列号、校验、正向确认和超时重传属于共同需求。

但块的处理顺序未必总是共同需求。若每块自带目标位置，102 可以先放入自己的地址，等待 101 到达再检查整体完整性。让 102 因 101 的迟到而闲置，会增加缓冲和时延。调试命令却可能相反：先设置断点，再让程序继续，次序改变就改变结果。

RDP 没有让传输层替两种应用作同一个决定。Open 请求明确选择 sequenced 或 non-sequenced delivery。非按序模式下，接收端可在 102 完好到达时把它复制给用户；按序模式下，它仍可 EACK 102，但必须等 101 补齐后才向用户交付。

因此，“确认了 102”和“应用看见了 102”不是同一事件。确认策略记录网络事实，交付策略执行应用在建连时声明的依赖。

建连消息定义解释的时代

顺序模式不能在相邻消息之间随意改变。RFC 908 要求它在连接建立时声明，并在连接寿命内保持不变。SYN 同时携带初始序列号、允许未确认报文段的最大数量、最大报文段尺寸以及包含顺序模式的选项。

这使一次连接成为独立的解释时代。同样一份 EACK，在不同交付模式下可能对应“已经给应用”或“只在传输层记账”。如果抓包从中途开始、丢失了 SYN，它即使收齐后续 ACK，也不能完整证明用户层何时得到数据。

缓冲能力同样由两端各自声明。接收端告诉对方自己能容纳多少在途报文段和多大的报文段，发送端按共同规则遵守。协议没有把一个固定窗口写成普遍性能标准。共同层需要的是可验证的上限，不是替每台机器决定应该配置多少内存。

确认对象不是应用结果

RDP 的状态包括 CLOSED、LISTEN、SYN-SENT、SYN-RCVD、OPEN 和 CLOSE-WAIT。两个主动打开的 SYN 可以在途中交叉，协议规定双方如何用各自的初始序列号和对方 SYN 的确认建立同一连接语境。

它还用 NUL 探测部分半开连接。NUL 占用下一个序列号，远端确认它，只能说明远端 RDP 仍认得这条传输连接。它不能证明装载程序没有死锁，也不能证明一幅镜像已经可启动。

关闭边界更值得注意。用户请求关闭时，RDP 发送 RST，进入 CLOSE-WAIT，随后释放连接记录。RFC 908 明确把“关闭前确认全部所需数据已可靠送达”的责任交给用户。传输层没有用一次 RST 替应用生成最终完成凭证。

所以证据应逐层阅读：校验通过说明一个报文段通过了规定的损坏检测；ACK/EACK 说明目标 RDP 接受了哪些序列；非按序交付可能说明数据已经复制到用户缓冲区；装载完成、命令执行或交易落盘仍需要自己的确认。

运行经验改写了第二版

1990 年的 RFC 1151 记录了 1986 至 1987 年实验暴露的问题。第一版使用的 32 位非线性校验算法对主机数据表示过于敏感：可比硬件上的优化实现，计算成本相差五倍。第二版改用 16 位 TCP checksum。

第一版的 RDP 端口只有 8 位，也被扩大到 16 位。这些变化直接改变报头，版本号因此升到 2。文档还修正了 SND.UNA 的伪代码：确认 SEG.ACK 之后，最老的未确认序列应是 SEG.ACK + 1，而不是刚刚已经确认的号码。

这不是一个“发布新版，于是世界升级”的故事。RFC 1151 自己说明，有限的实现需求不足以支持一次完整重写，因而只发布集中修订。它证明运行实验曾迫使规范改正；它不证明谁实际采用了第二版。

IANA 协议号注册表 至今把 27 与 RDP、RFC 908 对应起来。注册表维持的是号码不冲突和名称可查。它不能证明一台主机实现 RDP，更不能证明版本、EACK 支持、在线流量或产品符合性。

老协议留下的四层证据

有效 SYN 证明一次连接及其模式和容量参数。有效校验只证明一个报文段通过对应算法。ACK 与 EACK 分别证明连续和选择性接收。应用效果另需回执。

RDP 的价值不在于它替所有应用找到了“更好的顺序”。它把真正必须共同的部分严格规定下来，再让承担后果的应用决定是否为顺序付出等待成本。可靠性没有因此变弱，传输层的权力范围反而更清楚。

来源