TCP/IP协议详解卷一：Chapter15 Chapter16 笔记

Chapter 15 TFTP：简单文件传送协议

TFTP（Trivial File Transfer Protocol）即简单文件传送协议，最初打算用于引导无盘系统（通常是工作站或X终端）。为了保持简单和短小， TFTP将使用UDP。TFTP的代码（和它所需要的UDP、IP和设备驱动程序）都能适合只读存储器。RFC 1350是第2版TFTP的正式规范。

15.2 协议

在开始工作时，TFTP的客户与服务器交换信息，客户发送一个读请求或写请求给服务器。在一个无盘系统进行系统引导的正常情况下，第一个请求是读请求（RRQ）。下图显示了5种TFTP报文格式（操作码为1和2的报文使用相同的格式）。
TFTP报文的头两个字节表示操作码。对于读请求和写请求（WRQ），文件名字段说明客户要读或写的位于服务器上的文件。这个文件字段以0字节作为结束。模式字段是一个ASCII码串netascii或octet（可大小写任意组合），同样以0字节结束。netascii表示数据是以成行的ASCII码字符组成，以两个字节——回车字符后跟换行字符（称为CR/LF）作为行结束符。这两个行结束字符在这种格式和本地主机使用的行定界符之间进行转化。octet则将数据看作8 bit一组的字节流而不作任何解释。

每个数据（操作码为3）分组包含一个块编号字段，它以后要在确认分组中使用。以读一个文件作为例子，TFTP客户需要发送一个读请求说明要读的文件名和文件模式（mode）。如果这个文件能被这个客户读取， TFTP服务器就返回一个块编号为1的数据分组。TFTP客户又发送一个块编号为1的ACK。TFTP服务器随后发送块编号为2的数据。TFTP客户发回块编号为2的ACK。重复这个过程直到这个文件传送完。除了最后一个数据分组可含有不足512字节的数据，其他每个数据分组均含有512字节的数据。当TFTP客户收到一个不足512字节的数据分组，就知道它收到最后一个数据分组。
在写请求的情况下，TFTP 客户发送WRQ指明文件名和模式。如果该文件能被该客户写，TFTP 服务器就返回块编号为0的ACK包。该客户就将文件的头512字节以块编号为1发出。服务器则返回块编号为1的ACK。
这种类型的数据传输称为停止等待协议。它只用在一些简单的协议如TFTP中。TFTP的优点在于实现的简单而不是高的系统吞吐量。

最后一种TFTP报文类型是差错报文，它的操作码为5。它用于服务器不能处理读请求或写请求的情况。在文件传输过程中的读和写差错也会导致传送这种报文，接着停止传输。差错编号字段给出一个数字的差错码，跟着是一个ASCII表示的差错报文字段，可能包含额外的操作系统说明的信息。

既然TFTP使用不可靠的UDP，TFTP就必须处理分组丢失和分组重复。分组丢失可通过发送方的超时与重传机制解决。和许多UDP应用程序一样， TFTP报文中没有检验和，它假定任何数据差错都将被UDP的检验和检测到。

15.3 一个例子

在bsdi主机上运行TFTP客户程序，并从主机svr4读取一个文本文件：
注意的是在Unix系统下接收的文件长度是914字节，而TFTP则传送了962个字节。使用wc程序我们看到文件共有48行，因此48个Unix的换行符被转化成48个CR/CF对，因为默认情况下TFTP使用netascii模式传送。

下图显示了发生的分组交换过程。
第1行显示了客户向服务器发送的读请求。由于目的UDP端口是TFTP知名端口（69），tcpdump将解释TFTP分组，并显示RRQ和文件名。19字节的UDP数据包括2字节的操作码，7字节的的文件名，1字节的0，8字节的netascii模式以及另1字节的0结束。
下一个分组由服务器发回（第2行），共包含516字节：2字节的操作码， 2字节的数据块号和512字节的数据。第3行是这个数据块的确认，它包括2字节的操作码和2字节的数据块号。
最后的数据分组（第4行）包含450字节的数据。这450字节的数据加上第2行的512字节的数据就是向该客户传送的962字节的数据。

注意tcpdump仅在第1行解释TFTP报文，而在2～5行都不显示任何TFTP协议信息。这是因为服务器进程的端口在第1行和第2行发生了变化。TFTP协议需要客户进程向服务器进程的UDP知名端口（69）发送第一个分组（RRQ或WRQ）。之后服务器进程便向服务器主机申请一个尚未使用的端口（图中为1077），服务器进程使用这个端口来进行请求客户进程与服务器进程间的其他数据交换。其原因是服务器进程不能占用知名端口69来完成需一些时间的文件传输（可能是几十秒甚至数分钟）。在传输当前文件的过程中，该知名端口要留出来供其他的TFTP客户进程发送它们的请求。

15.4 安全性

注意在TFTP分组中并不提供用户名和口令。由于TFTP是设计用于系统引导进程，它不可能提供用户名和口令。TFTP的这一特性被许多解密高手用于获取Unix口令文件的复制，然后来猜测用户口令。为防止这种类型的访问，目前大多数TFTP服务器提供了一个选项来限制只能访问特定目录下的文件（Unix系统中通常是/tftpboot）。这个目录中只包含无盘系统进行系统引导时所需的文件。

Chapter 16 BOOTP：引导程序协议

第5章介绍了一个无盘系统在不知道自身IP地址的情况下，在进行系统引导时能够通过RARP来获取它的I P地址。然而使用RARP有两个问题：（1）IP地址是返回的唯一结果；（ 2）RARP使用链路层广播，RARP请求就不会被路由器转发（迫使每个实际网络设置一个RARP服务器）。本章将介绍一种用于无盘系统进行系统引导的替代方法，又称为引导程序协议（Bootstrap Protocol），或BOOTP。BOOTP使用UDP，且通常需与TFTP协同工作。

16.2 BOOTP的分组格式

BOOTP请求和应答均被封装在UDP数据报中。长度为300字节的BOOTP请求和应答的格式如下：

300字节的BOOTP报文 = 1字节操作码 + 1字节硬件类型 + 1字节硬件地址长度 + 1字节跳数 + 4字节事务标识 + 2字节秒数 + 2字节未使用 + 4字节客户IP地址 + 4字节你的IP地址 + 4字节服务器IP地址 + 4字节网关IP地址 + 16字节客户主机硬件地址 + 64字节服务器主机名 + 128字节引导文件名 + 64字节特定厂商信息

其中：

• 操作码字段为1表示请求，为2表示应答。
• 硬件类型字段为1表示以太网，硬件地址长度字段为6字节。
• 跳数字段由客户设置为0，但也能被一个代理服务器设置。
• 事务标识字段是一个由客户设置并由服务器返回的32 bit整数。客户用它对请求和应答进行匹配。对每个请求，客户应该将该字段设置为一个随机数。
• 客户开始进行引导时，将“秒数”字段设置为一个时间值。备用服务器在等待时间超过这个时间值后才会响应客户的请求，这意味着主服务器没有启动。
• 如果该客户已经知道自身的IP地址，它将写入“客户IP地址”字段。否则，它将该字段设置为0。对于后面这种情况，服务器用该客户的IP地址写入“你的IP地址”字段。“服务器IP地址”字段则由服务器填写。如果使用了某个代理服务器，则该代理服务器就填写“网关IP地址”字段。
• 客户必须设置它的“客户硬件地址”字段。尽管这个值与以太网数据帧头中的值相同，UDP数据报中也设置这个字段，但任何接收这个数据报的用户进程能很容易地获得它。
• 服务器主机名字段是一个空值终止串，由服务器填写。
• 服务器在“引导文件名字段”填入包括用于系统引导的文件名及其所在位置的路径全名。
• 特定厂商区域字段用于对BOOTP进行不同的扩展。

当一个客户使用BOOTP（操作码为1）进行系统引导时，引导请求通常是采用链路层广播， IP首部中的目的IP地址为255.255.255.255（受限的广播）。源IP地址通常是0.0.0.0，因为此时客户还不知道它本身的IP地址。

BOOTP有两个知名端口：BOOTP服务器为67，BOOTP客户为68。这意味着BOOTP客户不会选择未用的临时端口，而只用端口68。选择两个端口而不是仅选择一个端口为BOOTP服务器用的原因是：服务器的应答可以进行广播（但通常是不用广播的）。如果服务器的应答是通过广播传送的，同时客户又选择未用的临时端口，那么这些广播也能被其他的主机中碰巧使用相同临时端口的应用进程接收到。

如果多个客户同时进行系统引导，并且服务器广播所有应答，这样每个客户都会收到其他客户的应答。客户可以通过BOOTP首部中的事务标识字段来确认应答是否与请求匹配，或者可以通过检查返回的客户硬件地址加以区分。

16.4 BOOTP服务器的设计

BOOTP客户通常固化在无盘系统只读存储器中，因此了解BOOTP服务器的实现将更有意义。
首先，BOOTP服务器将从它的知名端口（67）读取UDP数据报。不同于RARP服务器，它必须读取类型字段为“RARP请求”的以太网帧。BOOTP协议通过将客户的硬件地址放入BOOTP分组中，使得服务器很容易获取客户的硬件地址。

TFTP服务器如何能将一个响应直接送回BOOTP客户？
有两种解决办法：第一种，通常被Unix服务器采用，是服务器发一个ioctl(2)请求给内核，为该客户在ARP高速缓存中设置一个条目（这就是命令arp -s所做的工作）。服务器能一直这么做直到它知道客户的硬件地址和IP地址。这意味着当服务器发送UDP数据报（即BOOTP应答）时，服务器的ARP将在ARP高速缓存中找到该客户的IP地址。
另一种可选的解决办法是服务器广播这个BOOTP应答而不直接将应答发回该客户。既然通常期望网络广播越少越好，因此这种解决方案应该只在服务器无法在它的ARP高速缓存设置一个条目的情况下使用。

16.5 BOOTP穿越路由器

RARP的一个缺点就是它使用链路层广播，这种广播通常不会由路由
器转发。这就需要在每个物理网络内设置一个RARP服务器。如果路由器支持BOOTP协议，那么BOOTP能够由路由器转发。

这个功能主要用于无盘路由器，因为如果在磁盘的多用户系统被用作路由器，它就能够自己运行BOOTP服务器。此外，常用的Unix BOOTP服务器支持这种中继模式（relay mode）。但如果在这个物理网络内运行一个BOOTP服务器，通常没有必要将BOOTP请求转发到在另外网络中的另一个服务器。

16.6 特定厂商信息

RFC 1533定义了16.2节中特定厂商信息区域的格式。这个区域含有服务器返回客户的可选信息。如果有信息要提供，这个区域的前4个字节被设置为IP地址99.130.83.99。称作魔术甜饼（magic cookie），表示该区域内包含信息。
这个区域的其余部分是一个条目表。每个条目的开始是1字节标志字段。其中的两个条目仅有标志字段：标志为0的条目作为填充字节（为使后面的条目有更好的字节边界），标志为255的条目表示结尾条目。第一个结尾条目后剩余的字节都应设置为这个数值（255）。除了这两个1字节的条目，其他的条目还包含一个单字节的长度字段，后面是相应的信息。

子网掩码条目和时间值条目都是定长条目，因为它们的值总是占4个字节。时间偏移值是从1900年1月1日0时以来的秒数（UTC）。
网关条目是变长条目。长度通常是4 的倍数，这个值是一个或多个供客户使用的网关（路由器）的IP地址。返回的第一个必须是首选的网关。
RFC 1533还定义了其他14个条目。其中最重要的可能是DNS名字服务器的IP地址条目，条目的志为6。其他的条目包括打印服务器、时间服务器等的IP地址。