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

11.9 UDP和ARP之间的交互作用

使用U D P，可以看到U D P与A R P典型实现之间的有趣的（而常常未被人提及）交互作用。我们用s o c k程序来产生一个包含8 1 9 2字节数据的U D P数据报。预测这将会在以太网上产生6个数据报片（见习题 11 . 3）。同时也确保在运行该程序前， A R P缓存是清空的，这样，在发送第一个数据报片前必须交换 A R P请求和应答。

预计在发送第一个数据报片前会先发送一个 A R P请求。I P还会产生5个数据报片，这样就提出了我们必须用 t c p d u m p来回答的两个问题：在接收到 A R P回答前，其余数据报片是否已经做好了发送准备？如果是这样，那么在 A R P等待应答时，它会如何处理发往给定目的的多个报文？图11 - 1 7给出了t c p d u m p的输出结果。

在这个输出结果中有一些令人吃惊的结果。首先，在第一个 A R P应答返回以前，总共产生了6个A R P请求。我们认为其原因是 I P很快地产生了 6个数据报片，而每个数据报片都引发了一个A R P请求。

第二，在接收到第一个 A R P应答时（第7行），只发送最后一个数据报片（第 9行）！看来似乎将前5个数据报片全都丢弃了。实际上，这是 A R P的正常操作。在大多数的实现中，在等待一个A R P应答时，只将最后一个报文发送给特定目的主机。Host Requirements RFC要求实现中必须防止这种类型的A R P洪泛（ARP flooding，即以高速率重复发送到同一个I P地址的A R P请求）。建议最高速率是每秒一次。而这里却在4.3 ms内发出了6个ARP请求。

Host Requirements RFC规定，ARP应该保留至少一个报文，而这个报文必须是最后一个报文。这正是我们在这里所看到的结果。

另一个无法解释的不正常的现象是， s v r 4发回7个，而不是6个A R P应答。最后要指出的是，在最后一个 A R P应答返回后，继续运行 t c p d u m p程序5分钟，以看看s v r 4是否会返回 I C M P“组装超时”差错。并没有发送 I C M P差错（我们在图 8 - 2中给出了该消息的格式。c o d e字段为1表示在重新组装数据报时发生了超时）。

在第一个数据报片出现时， I P层必须启动一个定时器。这里“第一个”表示给定数据报的第一个到达数据报片，而不是第一个数据报片（数据报片偏移为 0）。正常的定时器值为 3 0或6 0秒。如果定时器超时而该数据报的所有数据报片未能全部到达，那么将这些数据报片丢弃。如果不这么做，那些永远不会到达的数据报片（正如我们在本例中所看到的那样）迟早会引起接收端缓存满。

这里我们没看到 I C M P消息的原因有两个。首先，大多数从 B e r k e l e y派生的实现从不产生该差错！这些实现会设置定时器，也会在定时器溢出时将数据报片丢弃，但是不生成 I C M P差错。第二，并未接收到包含 U D P首部的偏移量为 0的第一个数据报片（这是被 A R P所丢弃的5个报文的第1个）。除非接收到第一个数据报片，否则并不要求任何实现产生 I C M P差错。其原
因是因为没有运输层首部，I C M P差错的接收者无法区分出是哪个进程所发送的数据报被丢弃。这里假设上层（T C P或使用U D P的应用程序）最终会超时并重传。

在本节中，我们使用 I P数据报片来查看 U D P与A R P之间的交互作用。如果发送端迅速发送多个U D P数据报，也可以看到这个交互过程。我们选择采用分片的方法，是因为 I P可以生成报文的速度，比一个用户进程生成多个数据报的速度更快。

尽管本例看来不太可能，但它确实经常发生。 N F S发送的U D P数据报长度超过8 1 9 2字节。在以太网上，这些数据报以我们所指出的方式进行分片，如果适当的 A R P缓存入口发生超时，那么就可以看到这里所显示的现象。 N F S将超时并重传，但是由于A R P的有限队列，第一个I P数据报仍可能被丢弃。