速读原著-TCP/IP(PUSH标志)

第20章 TCP的成块数据流

20.5 PUSH标志

在每一个T C P例子中，我们都看到了 P U S H标志，但一直没有介绍它的用途。发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括与 P U S H一起传送的数据以及接收方T C P已经为接收进程收到的其他数据。

在最初的T C P规范中，一般假定编程接口允许发送进程告诉它的 T C P何时设置P U S H标志。例如，在一个交互程序中，当客户发送一个命令给服务器时，它设置 P U S H标志并停下来等待服务器的响应（在习题 1 9 . 1中我们假定当发送 1 2字节的请求时客户设置 P U S H标志）。通过允许客户应用程序通知其 T C P设置P U S H标志，客户进程通知 T C P在向服务器发送一个报文段时不要因等待额外数据而使已提交数据在缓存中滞留。类似地，当服务器的 T C P接收到一个设置了P U S H标志的报文段时，它需要立即将这些数据递交给服务器进程而不能等待判断是否还会有额外的数据到达。

然而，目前大多数的 A P I没有向应用程序提供通知其 T C P设置P U S H标志的方法。的确，许多实现程序认为P U S H标志已经过时，一个好的T C P实现能够自行决定何时设置这个标志。

如果待发送数据将清空发送缓存，则大多数的源于伯克利的实现能够自动设置 P U S H标志。这意味着我们能够观察到每个应用程序写的数据均被设置了 P U S H标志，因为数据在写的时候就立即被发送。

代码中的注释表明该算法对那些只有在缓存被填满或收到一个P U S H标志时才向应用程序提交数据的TCP实现有效。

使用插口A P I通知T C P设置正在接收数据的 P U S H标志或得到该数据是否被设置PUSH标志的信息是不可能的。

由于源于伯克利的实现一般从不将接收到的数据推迟交付给应用程序，因此它们忽略所接收的P U S H标志。

举例 在图2 0 - 1中我们观察到所有8个数据报文段（4 ~ 6、9、11 ~ 1 3和1 5）的P U S H标志均被置1，这是因为客户进行了8次1 0 2 4字节数据的写操作，并且每次写操作均清空了发送缓存。

再次观察图 2 0 - 7，我们预计报文段 1 2中的P U S H标志被置1，因为它是最后一个报文段。为什么发送方知道有更多的数据需要发送还设置报文段 7中的P U S H标志呢？这是因为虽然我们指定写的是8 1 9 2个字节的数据，但发送方的发送缓存却是 4 0 9 6个字节。

值得注意的另外一点是在图 2 0 - 7中的第1 4、1 5和1 6这三个连续的确认报文段。在图 2 0 - 3中我们也观察到了两个连续的 A C K，但那是因为接收方已经通告其窗口为 0（使发送方停止）。

当窗口张开时，需要发送另一个窗口非 0的A C K来使发送方重新启动。可是，在图 2 0 - 7中，窗口的大小从来没有达到过 0。然而，当窗口大小增加了 2 0 4 8个字节的时候，另一个 A C K (报文段1 5和1 6 )被发送以通知对方窗口被更新（在报文段 1 5和1 6中，这两个窗口更新是不需要的，因为已经收到了对方的 F I N，表明它不会再发送任何数据）。许多T C P实现在窗口大小增加了两个最大报文段长度（本例中为 2 0 4 8字节，因为M S S为1 0 2 4字节）或者最大可能窗口的 5 0 %（本例中为2 0 4 8字节，因为最大窗口大小为 4 0 9 6字节）时发送这个窗口更新。在第 2 2 . 3节详细考察糊涂窗口综合症的时候，我们还会看到这种现象。

作为P U S H标志的另一个例子，再次回到图 2 0 - 3。我们之所以看到前4个报文段（4 ~ 7）的标志被设置，是因为它们每一个均使 T C P产生了一个报文段并提交给 I P层。但是随后，T C P停下来等待一个确认来移动 4 0 9 6字节的窗口。在此期间， T C P又得到了应用程序的最后 4 0 9 6个字节的数据。当窗口张开时（报文段 9），发送方T C P知道它有4个可立即发送的报文段，因此它只设置了最后一个报文段（ 1 3）的P U S H标志。