第11章 UDP：用户数据报协议

11.11 ICMP源站抑制差错

我们同样也可以使用 U D P产生I C M P“源站抑制(source quench)”差错。当一个系统（路由器或主机）接收数据报的速度比其处理速度快时，可能产生这个差错。注意限定词“可能”。

即使一个系统已经没有缓存并丢弃数据报，也不要求它一定要发送源站抑制报文。

图11 - 1 8给出了I C M P源站抑制差错报文的格式。有一个很好的方案可以在我们的测试网络里产生该差错报文。可以从 b s d i通过必须经过拨号 S L I P链路的以太网，将数据报发送给路由器s u n。由于S L I P链路的速度大约只有以太网的千分之一，因此，我们很容易就可以使其缓存用完。下面的命令行从主机 b s d i通过路由器s u n发送1 0 0个1 0 2 4字节长数据报给 s o l a r i s。
我们将数据报发送给标准的丢弃服务，这样，这些数据报将被忽略：

bsdi % sock -u -i -w1024 -n100 solaris discard

图11 - 1 9给出了与此命令行相对应的 t c p d u m p输出结果
在这个输出结果中，删除了很多行，这只是一个模型。接收前 2 6个数据报时未发生差错；我们只给出了第一个数据报的结果。然而，从第 2 7个数据报开始，每发送一份数据报，就会接收到一份源站抑制差错报文。总共有 26 +（7 4×2）= 1 7 4行输出结果。

从2 . 1 0节的并行线吞吐率计算结果可以知道，以 9600 b/s速率传送1 0 2 4字节数据报只需要1秒时间（由于从s u n到n e t b的S L I P链路的M T U为5 5 2字节，因此在我们的例子中， 20 + 8 +1 0 2 4字节数据报将进行分片，因此，其时间会稍长一些）。但是我们可以从图 11 - 1 9的时间中看出，s u n路由器在不到 1秒时间内就处理完所有的 1 0 0个数据报，而这时，第一份数据报还
未通过S L I P链路。因此我们用完其缓存就不足不奇了。

尽管RFC 1009 [Braden and Postel 1987] 要求路由器在没有缓存时产生源站抑制差错报文，但是新的Router Requirements RFC [Almquist 1993] 对此作了修改，提出路由器不应该产生源站抑制差错报文。由于源站抑制要消耗网络带宽，且对于拥塞来说是
一种无效而不公平的调整，因此现在人们对于源站抑制差错的态度是不支持的。

在本例中，还需要指出的是， s o c k程序要么没有接收到源站抑制差错报文，要么接收到却将它们忽略了。结果是如果采用 U D P协议，那么B S D实现通常忽略其接收到的源站抑制报文（正如我们在 2 1 . 1 0节所讨论的那样， T C P接受源站抑制差错报文，并将放慢在该连接上的数据传输速度）。其部分原因在于，在接收到源站抑制差错报文时，导致源站抑制的进程可能已经中止了。

实际上，如果使用 Unix 的t i m e程序来测定s o c k程序所运行的时间，其结果是它只运行了大约0 . 5秒时间。但是从图11 - 1 9中可以看到，在发送第一份数据报过后 0 . 7 1秒才接收到一些源站抑制，而此时该进程已经中止。其原因是我们的程序写入了 1 0 0个数据报然后中止了。但是所有的1 0 0个数据报都已发送出去—有一些数据报在输出队列中。这个例子重申了 U D P是一个非可靠的协议，它说明了端到端的流量控制。尽管 s o c k程序成功地将1 0 0个数据报写入其网络，但只有 2 6个数据报真正发送到了目的端。其他 7 4个数据报可能被中间路由器丢弃。除非在应用程序中建立一些应答机制，否则发送端并不知道接收端是否收到了这些数据。