摘要

  • URG 只是让报头中的偏移量生效，所得位置仍属于普通 TCP 字节流；它既不另建通道，也不保证每次发送都产生一次独立通知。
  • Telnet 用紧急通知唤醒处理，再靠流内 DATA MARK 完成同步；FTP 的 ABOR 同样依赖应用命令，而不是把控制权交给一个“特殊字节”。
  • RFC 1122 的一字节修正没有成为普遍运行事实。RFC 6093 回到既有实现的解释，同时劝新应用停止使用；RFC 9293 延续了“必须兼容、不要新增依赖”的边界。

一条流里的提醒

RFC 793 规定，只有 URG 置位时，16 位紧急字段才有意义。它与段序号相加，得到紧急信息的边界。只要这个位置还在接收方已消费数据之前，TCP 就通知应用进入紧急模式；读指针追上边界后，再退出。

这套机制描述状态，而不是包裹。边界在紧急模式中继续前移，应用也未必再次得到通知。因此，URG 不能充当可靠计数器，更不会让字节越过 TCP 的有序交付。

唤醒靠 TCP，定界靠 Telnet

RFC 854 的 Synch 把两件事绑在一起：TCP 紧急通知负责引起注意，DATA MARK 则作为普通流内命令，告诉接收方特殊扫描何时结束。连续多个 Synch 的通知可以合并；即使 TCP 先宣布紧急数据结束，Telnet 仍须找到 DATA MARK。

RFC 959 把这一办法带进 FTP。传输进行时，客户端可以依次发 Telnet Interrupt Process、Synch 和 ABOR 等命令。真正决定“中止”的仍是 FTP 语义；TCP 只帮助忙碌的服务器注意到控制流。

规范自己差了一个字节

RFC 793 的报头说明把指针放在紧急数据之后的第一个字节，发送状态机却写成 SND.NXT-1，落在最后一个紧急字节。RFC 1011 判定前者错误；RFC 1122 随后要求使用 LAST 而不是 LAST+1，并要求实现支持任意长度的紧急序列。

纸面边界被修正了，已部署内核里的边界却没有随之整体移动。

API 造出一个“外部”字节

RFC 6093 调查发现，作者测试的流行实现几乎都沿用 RFC 793 第 17 页的“下一个字节”解释。许多套接字默认又把最后一个紧急字节从普通读取中拿走，通过 MSG_OOB 单独交付。

于是，一个本可覆盖任意长度的流内区间，被缩成一个容易覆盖的槽位。新通知到达而旧字节尚未读取时，旧值可能消失。SO_OOBINLINE 能让本机恢复流内交付，却无法替所有对端和路径统一解释。

中间设备可以把铃声关掉

部分安全设备会清除 URG 并把指针归零。字节仍继续前行，应用等候的异步提醒却不再出现。端点与检查设备若对“被抽走的字节”理解不同，还会看到不同的应用流，从而产生漏报或误报。

RFC 6093 因此作出看似矛盾、实则务实的选择：指针语义回到既有实现普遍采用的“紧急数据之后”，TCP 实现继续必须支持；新应用则不应再使用，遗留应用要启用流内交付，并能容忍 URG 被清除。RFC 9293 保留了这一安排。

来源与证据边界

这些 RFC 能证明设计意图、文本冲突、Telnet/FTP 用法、2011 年报告的实现与中间设备行为。它们不能证明所有系统完全一致，也不能给出全球统一切换时间。URG 不代表网络优先级、身份认证或可靠越权。

最终被废除的不是报头字段，而是它对新应用正确性的支配资格。