TCP/IP详解--第十五章

 第15章 TFTP：简单文件传送协议

15.1    引言

 

TFTP(Trivial File Transfer Protocol) 即简单文件传送协议，最初打算用于引导无盘系统

（通常是工作站或 X终端）。和将在第 27章介绍的使用TCP的文件传送协议（FTP）不同，为了 保持简单和短小，TFTP将使用UDP。TFTP的代码（和它所需要的UDP、IP和设备驱动程序） 都能适合只读存储器。

本章对TFTP只作一般介绍，因为在下一章引导程序协议（Bootstrap Protocol）中还会遇 到TFTP。在图5-1中，当从网络上引导sun主机时，也曾遇到过 TFTP，sun主机通过 RARP获 得它的 IP地址后，将发出一个TFTP请求。

RFC 1350 [Sollins 1992] 是第 2版TFTP的正式规范。第 12章 [Stevens 1990] 提供了实现

TFTP客户和服务器的全部源代码，并介绍了一些使用 TFTP的编程技术。

15.2   协议

 

在开始工作时，TFTP的客户与服务器交换信息，客户发送一个读请求或写请求给服务器。 在一个无盘系统进行系统引导的正常情况下，第一个请求是读请求（  RRQ）。图15-1显示了5 种TFTP报文格式（操作码为1和2的报文使用相同的格式）。

TFTP报文的头两个字节表示操作码。对于读请求和写请求（  WRQ），文件名字段说明客 户要读或写的位于服务器上的文件。这个文件字段以  0字节作为结束（见图 15-1）。模式字段 是一个ASCII码串netascii或octet（可大小写任意组合），同样以 0字节结束。netascii 表示数据是以成行的 ASCII码字符组成，以两个字节—回车字符后跟换行字符（称为CR/LF） 作为行结束符。这两个行结束字符在这种格式和本地主机使用的行定界符之间进行转化。octet则将数据看作 8bit 一组的字节流而不作任何解释。

每个数据分组包含一个块编号字段，它以后要在确认分组中使用。以读一个文件作为例子，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中。在20.3节 中将看到 TCP提供了不同形式的确认，能提供更高的系统吞吐量。TFTP的优点在于实现的简

160   TCP/IP详解，卷1：协议

下载

 

单而不是高的系统吞吐量。

IP数据报

UDP报文

TFTP数据报

 

IP首部      UDP首部

操作码

(1=RRQ)

(2=WRQ)

文件名                       模式

20字节           8字节

2字节

N字节

N字节

 

操作码 块编号                            数    据

(3=data)

2字节

2字节

0-512字节

 

操作码 块编号

(4=ACK)

2字节

2字节

 

 

操作码 差错码    差错信息

(5=error)

2字节    2字节 N字节

 

图15-1   5种TFTP报文格式

 

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

既然TFTP使用不可靠的UDP，TFTP就必须处理分组丢失和分组重复。分组丢失可通过发送方的超时与重传机制解决（注意存在一种称为“魔术新手综合症    ( s o r c e r e r ’s apprenticesyndrome)”的潜在问题，如果双方都超时与重传，就可能出现这个问题。  12.2节[Stevens

1990] 介绍了这个问题是如何发生的 )。和许多 UDP应用程序一样， TFTP报文中没有检验和， 它假定任何数据差错都将被 UDP的检验和检测到（参见 11.3节）。

15.3    一个例子

 

让我们通过观察协议的工作情况来了解TFTP。在bsdi主机上运行 TFTP  客户程序，并从 主机svr4读取一个文本文件：

启动TFTP客户进程 从服务器读取文件

 

结束

查看我们读取的文件大小

 

文件行数？

 

最先引起我们注意的是在Unix系统下接收的文件长度是914字节，而 TFTP则传送了 962个

字节。使用wc程序我们看到文件共有 48 行，因此48个Unix的换行符被转化成48个CR/CF对，

第15章   TFTP：简单文件传送协议     161

下载

 

因为默认情况下TFTP使用netascii模式传送。

图15-2显示了发生的分组交换过程。

图15-2   使用TFTP传输一个文件的分组交换过程

第1行显示了客户向服务器发送的读请求。由于目的  U D P 端口是TF T P熟知端口（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 行都不显示任何 TF T P 协议信息。这是因为服务器进程的端口在第  1 行和第2行发生了变化。 TFTP协议需要客户进程向服务器进程的UDP熟知端口（ 69）发送第一个分组（RRQ或WRQ）。 之后服务器进程便向服务器主机申请一个尚未使用的端口（ 1077，见图 15-2），服务器进程使 用这个端口来进行请求客户进程与服务器进程间的其他数据交换。客户进程的端口号（在这 个例子中为1106）没有变化。 tcpdump无法知道主机srv4上的1077端口是一个 TFTP服务器进 程。

服务器进程端口变化的原因是服务器进程不能占用这个熟知端口来完成需一些时间的文件传输（可能是几十秒甚至数分钟）。相反，在传输当前文件的过程中，这个熟知端口要留出来供其他的 TFTP客户进程发送它们的请求。

回顾图 10-6，当RIP服务器向客户发送的数据超过512字节，两个UDP数据报都使用服务 器的熟知端口。在那个例子中，即使服务器进程必须写多个数据报以便将所有数据发回，服务器进程也是先写一个，再写一个，它们都使用它的熟知端口。然而，  TFTP协议与它不同， 因为客户与服务器间的连接需要持续一个较长的时间（可能是数秒或数分钟）。如果一个服务 器进程使用熟知端口来进行文件传输，那么在文件传输期间，它要么拒绝任何来自其他客户的请求，要么一个服务器进程在同一端口（69）同时对多个客户进程进行多个文件传输。最简单的办法是让服务器进程在收到 RRQ或WRQ后，改用新的端口。当然，客户进程在收到第一个数据分组（图15-2的第2行）后必须探测到这个新的端口，并将之后的所有确认（第  3行 和第5行）发送到那个新的端口。

在16.3节我们将看到当 X终端在进行系统引导时将使用 TFTP。

15.4   安全性

 

注意在 TFTP分组（图 15-1）中并不提供用户名和口令。这是 TFTP的一个特征（即“安全 漏洞”）。由于TFTP是设计用于系统引导进程，它不可能提供用户名和口令。

TFTP的这一特性被许多解密高手用于获取 Unix口令文件的复制，然后来猜测用户口令。

162   TCP/IP详解，卷1：协议

下载

 

为防止这种类型的访问，目前大多数 TFTP服务器提供了一个选项来限制只能访问特定目录下

的文件（ Unix系统中通常是 /tftpboot）。这个目录中只包含无盘系统进行系统引导时所需的文件。

对其他的安全性， Unix系统下的 TFTP服务器通常将它的用户 ID和组ID设置为不会赋给任 何真正用户的值。这只允许访问具有读或写属性的文件。

15.5   小结

 

TFTP是一个简单的协议，适合于只读存储器，仅用于无盘系统进行系统引导。它只使用 几种报文格式，是一种停止等待协议。

为了允许多个客户端同时进行系统引导， TF T P服务器必须提供一定形式的并发。因为UDP在一个客户与一个服务器之间并不提供唯一连接（  TCP也一样），TFTP服务器通过为每 个客户提供一个新的UDP端口来提供并发。这允许不同的客户输入数据报，然后由服务器中的UDP模块根据目的端口号进行区分，而不是由服务器本身来进行区分。

TFTP协议没有提供安全特性。大多数执行指望TFTP服务器的系统管理员来限制客户的访问，只允许它们访问引导所必须的文件。

第27章介绍的文件传输协议（ FTP）是设计用于一般目的的、高吞吐量的文件传输。

习题

 

15.1   阅读HostRequirements RFC，了解如果一个 TFTP 服务器收到的请求的目的 IP地址是一个广播地址，它将做什么。

15.2   当TFTP块号由65535跳回到0时，你认为会发生什么？RFC 1350 提到了如何处理这一问 题吗？

15.3   TFTP发送方采用超时重发来处理分组丢失。当TFTP作为引导进程的一部分时，这种方 法对TFTP的使用有何影响？

15.4   使用TFTP时，影响传输文件所需时间的限制性因素是什么？