传输层协议（9）：滑动窗口（3）——会呼吸的痛

5.3.1.4 Urgent（紧急数据）

紧急数据（Urgent Data），TCP 有时候也简称 Urgent。作为 TCP 的一个特性，由于它的单词含义（紧急的、急迫的），Urgent 似乎是给人一种一目了然的感觉，实际上它却比较容易引起困扰。这个困扰是什么，我们暂且按下不表，先看看 Urgent 在 TCP 里面的定义是什么。

 

1）紧急数据的基本定义

Urgent 在 TCP 里面的定义是什么，如图5-97所示： 

 

图5-97 TCP 报文结构

 

Urgent 在 TCP 中的定义，对应图5-97中的3个字段：

（1）Urgent 标签，简称 URG，也就是图5-97中的“U”，占位1个 bit。当 URG = 1 时，后面的两个字段才有意义。也就是说，URG = 1 时，这3个字段才能联合表达 TCP 的 Urgent 的含义，否则 TCP 认为 It’s not  Urgent（不紧急）！

（2）Urgent Pointer，占位 16 bits，它是一个无符号整数，指示数据字段（图5-97中的 Data）中哪个（些）数据是紧急数据。当然，只有 URG = 1 时，Urgent Window 这个字段才有意义。

（3）Data，TCP 报文中所包含的数据部分。当 URG = 1 时，这部分数据中有1个（或多个）字节的数据代表是紧急数据，而这个（些）紧急数据由 Urgent Pointer 指定，如图5-98所示：

 

 图5-98 紧急数据的分歧

 

图5-98 是一个 TCP 报文的数据片段，假设这个报文的 SEQ（Sequence Number） = 10，URG = 1，Urgent Pointer = 11。那么：

（1）RFC 793 认为：紧急数据序列号 = SEQ + Urgent Pointer - 1 = 20，也就是图5-97中第“20”个字节是紧急数据。

（2）RFC 1122 认为：紧急数据序列号 = SEQ + Urgent Pointer = 21，也就是图5-97中第“21”个字节是紧急数据。

实际上 RFC 793 是错误的，RFC 1122 是正确的，它对 RFC 793 做了修订：

The second sentence is in error: the urgent pointer points to the sequence number of the LAST octet (not LAST+1) in a sequence of urgent data.  The description on page 56 (last sentence) is correct.

但是，混乱已经酿成了，RFC 793 发布于1981年9月，RFC 1122 发布于1989年10月，这造成 TCP 协议栈具体的实现中，有的不得不两种都支持，让用户通过配置文件配置到底采用哪一种方案。本文采用 RFC 1122 的方案。

RFC 793 所犯的这种错误，从某种意义上可以理解，毕竟人无完人，一时疏忽总是难免的。但是紧急数据的长度是多少呢？它从哪里开始，哪里结束呢？关于这两个问题，RFC 793 和 RFC 1122 的描述是德行：模糊不清，故意制造混乱。

请原谅我对伟大的 RFC 出言不逊。我们还是来看看两个 RFC 是怎么说的。

RFC 793是这么说的：This mechanism permits a point in the data stream to be designated as the end of urgent information.

这句话的意思是“Urgent Pointer 指示了紧急数据的结尾”，但是它同时也暗示了紧急数据不只是1个字节。

RFC 1122 是这么说的：A TCP MUST support a sequence of urgent data of any length.

这就不是暗示了，而是明确说明：紧急数据是不止是1个字节，而是任意长度。

至此我们看到了，无论是 RFC 793 还是 RFC 1122 都认为两点：

（1）紧急数据不止1个字节

（2）紧急数据的最后一个字节由 Urgent Pointer 指定（如前文所述：RFC 793 的指定方法有点问题，RFC 1122 对其做了修正）。

但是，TCP 的数据结构（报文头）中，只有1个字段 Urgent Pointer 指定了紧急数据的结尾，却再也没有其他字段以能指定紧急数据的起始位置或者长度（通过长度能间接推导出起始位置）。

这可让人怎么办？ 

 

 

面对这种模糊，一般有两种方案：

第1种方案是认为该报文中，从第1个字节开始，到 Urgent Pointer 结束，这段数据通通都是紧急数据，如图5-99所示： 

 

图5-99 紧急数据的定义（1）

 

该方案认为，图5-99中的第10~21，这12个字节的数据，都是紧急数据。

第2种方案则不再纠结，根本不在意 RFC 是这么说的，就是认为紧急数据只有1个字节，如图5-100所示：

 

图5-100 紧急数据的定义（2）

 

业界普遍采用第2种方案，比如著名的 Linux 就是采用第2种方案。本文遵从 Linux，也采用第2种方案。

唉......Urgent 特性确实够混乱的。下面我们对 Urgent 的定义做一个简单的总结吧：

（1）URG = 1，紧急数据才有意义，否则报文中的数据没有紧急数据

（2）紧急数据只有1个字节。当 URG = 1 时，紧急数据位于报文中的数据的序号 = SEQ + Urgent Pointer。

 

2）紧急数据在接收方的行为

紧急数据在接收方的行为，指的是 TCP 接收方收到包含紧急数据的报文后，它该如何将这个报文中的数据提交给应用层，如图5-101所示：

 

图5-101 紧急数据在接收方的行为

 

图5-101中，我们假设 TCP 采用满泻提交模式（即使采用直流提交模式，TCP 对于紧急数据的提交方式也是一样的，只不过采用满泻提交模式，对比更加强烈，更容易理解）。

T0时刻，接收方缓存中有数据“xyz”。

T1时刻，接收方收到了“abcde”，其中“c”是紧急数据。此时接收方处理紧急数据的方案是：

（1）抢在其他所有数据之前（抢在本次接收的普通数据“abde”之前，也抢在已经存入接收缓存的普通数据“xyz”之前），提交给应用层

（2）而且是在第一时间提交，毫无停顿。

（3）更进一步，紧急数据（“c”）根本不会经过接收方缓存，而是直接提交给应用层。

（4）在紧急提交了紧急数据以后，对于本次接收的其他非紧急数据（“abde”），接收方按照正常流程处理：或者是满泻提交、或者是直流提交。

我们把以上1~3步所描述的提交方式称为紧急提交模式。

 

3）紧急数据在发送方的行为

总的来说，紧急数据在接收方的提交模式（紧急提交），比较清晰和简单。但是，紧急数据在发送方的行为，相对就比较令人困惑了。

在 TCP 的官方表达中，其把紧急数据称为带外数据（out-of-band,OOB），但是实际上TCP 的数据发送，根本就没有什么所谓的带外数据发送。

带外数据指的是发送采用与普通数据不一样的（逻辑）通道。而 TCP 发送紧急数据与普通数据，采用的是同一个通道。当然，这里需要稍微澄清一下：此时所说的通道，指的就是 TCP 连接，而不是 IP 层的路由。

由此我们知道，TCP 称紧急数据为带外数据，只是一个比方而已，或者只是为了一个形象地表达。但是，真的形象吗？

紧急数据在 TCP 的接收方，采用的是紧急提交模式。这种模式用大白话说，就是“插队”。那么，紧急数据在 TCP 的发送方，是否会插队发送呢？如图5-102所示：

 

5-102 紧急数据会插队发送吗

 

图5-102中，滑动窗口中5000个字节允许发送，另外还有10000个字节等待发送许可，也就是说一共有15000个字节有待发送。此时，用户调用 TCP 的 SEND 接口，期望发送1个紧急数据“n”，那么 TCP 发送的行为是：

（1）绝对不会插队发送，那个紧急数据“n”，老老实实地排在第15001位，等待 TCP 发送。

（2）TCP 发送方严格按照滑动窗口的滑动原则（叠加上 PUSH 行为，如果用户调用了 PUSH 发送的话），按部就班地发送数据。

也就是说，所谓紧急数据，在 TCP 发送方看来，一点都不“紧急”，该怎么就这么发送。那么，问题来了，紧急数据到底是什么含义呢？它到底要跟谁着急？

它到底要跟谁着急？这个问题问得好——哈哈，还有自己夸自己的——我们先看一个古老的笑话：

话说，有俩个人去非洲寻宝。不巧俩人遇到了狮子。这时，其中一个人放下手里的东西，把背后的包打开，迅速的换上了跑鞋。另一个人不解，说：“你难道跑得过狮子吗？”只听那个人说，“是啊！当然跑不过它，但只要比你跑得快就行啦。”

TCP 所谓的紧急数据，它的应用场景跟这个笑话的寓意一样：追求的不是绝对速度（紧急），而是相对速度（紧急）。

我们举一个例子。假设你是一名程序猿，但是你的工作却是天天写 PPT。有一天你终于厌烦了这种生活，你发誓一定要写代码（唉......多么屌丝的誓言）。于是你决定先登录到服务器，将上面的 PPT 先删除上面的 PPT——是的，你要跟昨天彻底告别。

本来，你删除 PPT 的命令是（伪码）：del *.pptx，但是你误敲成 del *.*。“del *.*”是什么意思？那是要删光服务器上所有的文件啊......上帝啊！下一步怎么办？

 

 

也许 TCP 能救你！你马山再发送1个紧急数据“n”——我们假设“n”代表不执行任何命令——这个时候，你所敲的这些命令，对于 TCP 来说，它的报文可能是这样的，如图5-103所示：

 

 图5-103 紧急数据的应用

 

图5-103只表达了 TCP 的数据部分，这个报文的 SEQ = 10，URG = 1，Urgent Pointer = 6，也就是序号为16的那个字节“n”是紧急数据。

对于这样一段数据，如前文所说，TCP 发送方并不着急，它按照滑动窗口的规则，该怎么发送就怎么发送。重点是这样一段数据到了接收方以后，TCP 接收方会在其他数据之前，将紧急数据“n”紧急提交给应用层。对应的应用层接到“n”这个字符以后，就不会执行后面接收到的命令。那么，“del *.*”这个命令就不会被执行——服务器上的文件完好无损——从此，你又可以安安静静地写你的 PPT 了。至于写代码的念头，唉......还是趁早打消吧，毕竟 TCP 也不是每次都能帮到你，如果你敲“n”的命令稍微慢一点的话......

以上所举的例子，从技术角度来讲，会有一些漏洞，你也不能完全当真，只是当作一个故事能帮助理解紧急数据的用途即可。

抽象地讲，紧急数据的应用场景是：如果发送客户端程序由于一些原因需要取消已经写入服务器的请求，那么它就需要向服务器紧急发送一个标识取消的请求。使用紧急数据的实际程序例子有telnet、rlogin、ftp 等命令。前两个程序（telnet和rlogin）会将中止字符作为紧急数据发送到远程端。这会允许远程端冲洗所有未处理的输入，并且丢弃所有未发送的终端输出。这会快速中断一个向客户端屏幕发送大量数据的运行进程。ftp命令也会使用紧急数据来中断一个文件的传输。

由此，我们知道了紧急数据的应用场景，但是它在 TCP 发送方的故事还没有结束。在“5.3.1.3 PUSH”小节中，我们讲述了 PSH 标签，可以由用户调用 SEND 接口时主动打上，也可以由 TCP 自动打上。而 URG 标签，只能由用户主动打上。也就是说，紧急数据只能由用户标识，TCP 不会自动标识某个数据是紧急数据。

不过，这不是最主要的，最主要的是 TCP 发送方打 UGR 标签的行为，虽然紧急数据的标识只能由用户主动标识。假设用户调用 TCP 接口发送一串字符，如下（伪码）：

SEND(“abcdefgh”，URG = 1)

根据前文描述我们知道，TCP 的具体实现（比如 linux）仅仅认为紧急数据只有1个字节，所以用户如果调用了上述接口，TCP 会认为只有最后1个字符“h”是紧急数据。

考虑一个极端一点的情况，假设滑动窗口的大小等于3，那么 TCP 会将“abcdefgh”分割成3个报文发送。现在问题来了：这3个报文的 URG 标签即 Urgent Pointer 该如何赋值呢？如图5-104所示：

 

图5-104 紧急数据的报文分割

 

图5-104，“abcdefgh”，由于发送窗口太小，这8个字符被分解为3个包，而且只有第3个包中的“h”才是紧急数据。

但是，我们看到，从报文1开始，URG 标签就被打上了（URG = 1），而且 Urgent Pointer 指向了未来。因为对于报文1来说，SEQ + Urgent Pointer = 1 + 7 = 8，然而第8个字节并不在报文1里，而是在第报文3里，所以说 Urgent Pointer 指向了未来。

报文2也是同理，早早地打上了 URG 标签，但是 Urgent Pointer 依然指向未来。

只有报文3算是真正完成了紧急数据的发送。

我们想象一下 TCP 报文的接收方，收到1个号称是紧急的报文，里面却没有紧急数据，又收到号称是紧急的报文，里面却没有紧急数据 ......

唉，TCP 发送方太皮——我怕来不及，就不告诉你！直到感觉你的皱纹，有了岁月的痕迹！ 

 

 

TCP 为什么要这么做呢？鄙人猜想，它是想做一个骑墙派。前文说过，RFC 认为：

（1）紧急数据不止1个字节

（2）紧急数据的最后一个字节由 Urgent Pointer 指定

但是 RFC 用 Urgent Pointer 定义了紧急数据的结尾，却没有定义紧急数据的开头（或者长度），弄得 TCP 具体实现者无所适从，最后要么是仅仅认为紧急数据只有1个字节（比如 Linux），要么是把该报文的第1个字节到 Urgent Pointer 所指定的字节，这之间全部的字节都认为是紧急数据。

当用户调用接口：SEND(“abcdefgh”，URG = 1)，TCP 该怎么办呢？这时候它就骑墙了：

（1）发送的时候，相关的报文，我都打上 URG 标签

（2）接收的时候，你看着办，你认为全都是，那就全都是紧急数据，你认为只有1个字节是紧急数据，那就1个字节。

（注：TCP 的发送和接收，可能不是同一个实现者。比如 TCP 发送是 Windows，TCP 接收是 Linux）。

骑墙派的哲学是两边都不得罪，既不得罪 RFC，也不得罪 TCP 的具体实现者。

但是，骑墙派期望是两边都不得罪，实际上却是两边都得罪，两边都讨好，如图5-105所示：

 

图5-105 骑墙派的忧愁

 

图5-105中，发送缓存中已经有了“hello”5个字符，此时用户调用了 TCP 接口：

SEND(“abcdefgh”，URG = 1)

然后 TCP 发送方将这13个字符拼成了1个报文发送出去，该报文的：SEQ = 1，URG = 1，Urgent Pointer = 12。

此时，如果认为从第1个字节（SEQ = 1）到第13个字节（Urgent Pointer = 12），也就是认为“helloabcdefgh”都是紧急数据，显然是不对的。所以骑墙派是不能让 RFC 满意的，而图5-104所描述的情形，也不能让 TCP 接收方满意。 

 

满脸的忧伤

 

TCP 的这种忧伤，忍一忍也能过去：得罪了 RFC，那就不伺候了，就认为只有1个字节是紧急数据；多发了几个无关的紧急报文（图5-104所描述的情形），那就多发了，唉咋地咋地。但是，TCP 还可能将紧急数据给发错了，如图5-106所示：

 

图5-106 紧急报文发错了

 

图5-106中，T1 时刻，用户调用 TCP 接口，发送了紧急数据“hello”（只有“o”是紧急数据），但是实际上 TCP 并没有发送该数据，而是将之存入了发送缓存。

T2 时刻,用户又调用 TCP 接口，发送了紧急数据“abcdefgh”（只有“h”是紧急数据）。

现在问题来了，TCP 实际上是接纳了两个紧急数据发送的任务，但是它在 T3 时刻却用1个报文给发出去了，正如图5-106所示，这个报文的 SEQ = 1、URG = 1、Urgent Pointer = 12，也就是说仅仅是“h”是紧急数据，而“o”变成了普通数据（非紧急数据）。

也就是 TCP 在紧急数据发送层面的一个问题：如果上一个紧急数据还没发送，有可能会被下一个紧急数据给“冲刷/替代”掉_——而且用户并不知道他的紧急数据何时能被正确发送，何时会被“冲刷/替代”。

回到本小节开头的那句话：作为 TCP 的一个特性，由于它的单词含义（紧急的、急迫的），Urgent 似乎是给人一种一目了然的感觉，实际上它却比较容易引起困扰。

我们来数数 Urgent 有多少让人迷惑的点吧：

（1）Urgent Pointer 关于紧急数据的指示，RFC 793 定义错了，RFC 1122 给纠正了过来，但是这中间经历了8年，混乱的种子就此埋下。

（2）RFC 一方面信誓旦旦地说“紧急数据是一串数据”，但是它只定义了紧急数据的结尾指示（Urgent Pointer），却没有定义紧急数据的起始位置，造成了具体实现者无所适从，最后绝大部分实现者只能选择“紧急数据其实就是1个字节”

（3）TCP 所发送的报文中，可能是 URG = 1，但是该报文并不包含紧急数据

（4）如果上一个紧急数据还没发送，有可能会被下一个紧急数据给“冲刷/替代”掉——而且用户并不知道他的紧急数据何时能被正确发送，何时会被“冲刷/替代”。 

 

Urgent 是一种会呼吸的痛

 

4）Urgent 与 PUSH 的比较

Urgent 与 PUSH 相比，有一定相似的地方，不过它们之间的差别实际上很大的。我们有一张表来总结两者之间的差别，如表5-28所示：

 

表5-28  Urgent 与 PUSH 的比较

发送/接收	比较项	PUSH	Urgent
全部	目标	减少时延： 1、发送缓存中的数据立刻发送 2、接收缓存中的数据立刻提交给应用层	提升相对速度： 1、紧急数据比普通数据更早地提交给应用层
发送方	是否插队发送	N	N
发送方	是否满足滑动窗口规则	Y	Y
发送方	发送行为	打破原来的原则（比如 Nagle 算法），发送缓存中的数据立刻发送	发送缓存中的数据按照原来的原则（比如 Nagle 算法）发送
发送方	用户是否可以指定	Y	Y
发送方	TCP 是否可以自动指定	Y	N
接收方	数据提交模式	接收缓存中的所有数据立刻提交给应用层	1、只有紧急数据立刻而且抢先提交给应用层，而且不经过接收缓存 2、其他数据（普通数据）按照原有的提交模式（比如满泻提交模式）提交
全部	概念清晰	Y	N