摘要

  • URG 与紧急指针不会创建第二条数据通道；紧急信息仍位于 TCP 的普通序列空间中。
  • RFC 793 包含两套冲突的边界规则。RFC 1122 选择“最后一个紧急字节”，RFC 6093 后来又使标准与广泛部署的“紧急数据之后的字节”做法一致。
  • RFC 9293 保留现行规则和实现义务，但没有把它变成优先通道，也不鼓励新应用建立依赖。

设置 URG 后，16 位紧急指针被解释为相对于报文段序列号的正偏移，因此它与普通数据属于同一个序列空间。只要标记点在序列空间中仍领先于 RCV.NXT，接收方就处于紧急模式；接收进度追上该点后便回到普通模式。字节始终留在数据流内。某些套接字 API 默认把一个字节呈现为“带外”，那是 API 约定，而不是第二种传输服务。

原始矛盾只差一个位置，却影响深远。RFC 793 的首部说明把指针放在紧急数据之后的字节上，而 SEND 处理又把 SND.UP 设为 SND.NXT-1，指向最后一个紧急字节。RFC 1122 选择后者，并要求支持任意长度的紧急序列以及向应用异步通知。然而 RFC 6093 发现，其调查的广泛部署实现采用的是“后续字节”解释，因此更新 RFC 793、RFC 1011 和 RFC 1122，将这一实践写入标准。RFC 9293 把它延续为当前的强制规则。

接收方已经处于紧急模式时，指针再次更新未必触发新的应用通知，所以发送方的紧急调用次数不必与接收方的通知次数一一对应。RFC 6093 还记录了部分中间设备会清除 URG 并把指针置零，但并未声称所有设备都如此。现有来源也不能证明今天的使用比例、操作系统默认值或攻击频率。

资料来源