第16章 BOOTP：引导程序协议
16.3 一个例子
让我们看一个用 B O O T P引导一个X终端的例子。图 1 6 - 3显示了t c p d u m p的输出结果（例中客户名为p r o t e u s，服务器名为m e r c u r y。这个t c p d u m p的输出是在不同的网络上获得的，这个应用程序是其他例子中一直使用的）。
在第1行中，我们看到客户请求来自 0 . 0 . 0 . 0 . 6 8，发送目的站是 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 . 6 7。该客户已经填写的字段是秒数和自身的以太网地址。我们看到客户通常将秒数设置为 1 0 0。
t c p d u m p没有显示跳数和事务标识，因为它们均为 0 (事务标识为 0表示该客户忽略这个字段，因为如果打算对返回响应进行验证，它将把这个字段设置为一个随机数值 )。 第2行是服务器返回的应答。由服务器填写的字段是该客户的 I P地址（t c p d u m p显示为名字p r o t e u s）、服务器的 I P地址（显示为名字 m e r c u r y）、网关的 I P地址（显示为名字m e r c u r y）和引导文件名。
在收到B O O T P应答后，该客户立即发送一个A R P请求来了解网络中其他主机是否有I P地址。跟在w h o - h a s后的名字p r o t e u s对应目的I P地址（图4 - 3），发送者的I P地址被设置为0 . 0 . 0 . 0。它在0 . 5秒后再发一个相同的A R P请求，之后再过0 . 5秒又发一个。在第3个A R P请求（第5行）中，它将发送者的I P地址改变为它自己的I P地址。这是一个没有意义的A R P请求（见4 . 7节）。 第6行显示该客户在等待另一个 0 . 5秒后，广播另一个B O O T P请求。这个请求与第1行的唯一不同是此时客户将它的I P地址写入I P首部中。它收到来自同一个服务器的相同应答（第7行）。
该客户在等待 2秒后，又广播一个 B O O T P请求（第8行），同样收到来自同一服务器的相同应答。
该客户等待2秒后，向它的服务器 m e r c u r y发送一个A R P请求（第1 0行）。收到这个A R P应答后，它立即发送一个 T F T P读请求，请求读取它的引导文件（第 1 2行）。文件传送过程包括2 4 6 4个T F T P数据分组和确认，传送的数据量为 5 1 2×2463 224 = 1 261 280字节。这将操作系统调入X终端。我们已在图1 6 - 3中删除了大多数T F T P行。
当和图1 5 - 2比较T F T P的数据交换过程时，要注意的是这儿的客户在整个传输过程中使用T F T P的知名端口（6 9）。既然通信双方中的一方使用了端口 6 9，t c p d u m p就知道这些分组是T F T P报文，因此它能用T F T P协议来解释每个分组。这就是为什么图 1 6 - 3能指明哪些包含有数据，哪些包含有确认，以及每个分组的块编号。在图 1 5 - 2中我们并不能获得这些额外的信息，因为通信双方均没有使用 T F T P的知名端口进行数据传送。由于 TFTP 服务器作为一个多用户系统，且使用T F T P的知名端口，因此通常T F T P客户不能使用那个端口。但这里的系统处于正被引导的过程中，无法提供一个 T F T P服务器，因此允许该客户在传输期间使用 T F T P的知名端口。这也暗示在m e r c u r y上的T F T P服务器并不关心客户的端口号是什么—它只将数据传送到客户的端口上，而不管发生了什么。
从图1 6 - 3可以看出在9秒内共传送了1 261 280字节。数据速率大约为140 000 bps。这比大多数以F T P文件传送形式访问一个以太网要慢，但对于一个简单的停止等待协议如 T F T P来说已经很好了。
X终端系统引导后，还需使用 T F T P传送终端的字体文件、某些 D N S名字服务器查询，然后进行X协议的初始化。图 1 6 - 3中的所有步骤大概需要 1 5秒钟，其余的步骤需要 6秒钟，这样无盘X终端系统引导的总时间是2 1秒。
