成都高投建设开发有限公司网站网站开发PHP留言本电子版实验作品

TFTP最初打算用于引导无盘系统（通常是工作站或X终端）。为保持简单和短小，TFTP使用UDP。它适合只读存储器。

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

TFTP报文的前两个字节表示操作码，对于读请求和写请求，文件名字段说明客户要读或写的位于服务器上的文件，这个字段后跟0字节作为结束。模式字段是一个ASCII码串netascii或octet（指八个比特为一组的单位），同样后跟0字节作为结束，netascii表示数据是以成行的ASCII码字符组成，以\r\n作为行结束符，这两个行结束字符会在这种格式和本地主机使用的行定界符之间进行转化，octet将数据看作8bit一组的字节流而不做任何解释。

每个数据分组（操作码为data的分组）包含一个块编号字段，客户读一个文件时，服务器就返回一个块编号为1的数据分组，客户会发送一个块编号为1的ACK，随后服务器发送块编号为2的数据分组，客户收到后发回编号为2的ACK，重复以上过程直到文件传送完，除了最后一个数据分组可含有不足512字节的数据，其他每个数据分组均含512字节数据，当客户收到一个不足512字节的数据分组，它就知道收到了最后一个数据分组。

写请求时，客户发送的WRQ会指明文件名和模式，如果该文件能被客户写，服务器就返回块编号为0的ACK包，客户收到后就将文件的头512字节以块编号为1发出，服务器则返回块编号为1的ACK。

以上类型的数据传输称为停止等待协议，它只用在一些简单的协议中，优点是实现简单而非高吞吐量。

当服务器不能处理读请求或写请求时，或出现文件传输过程中的读和写差错时，会导致传送差错报文，之后停止传输。差错编号给出一个数字的差错码，之后跟ASCII表示的差错报文字段，其中可能包含额外的操作系统说明的信息。

和很多UDP应用一样，TFTP没有检验和，它假定任何数据差错都将被UDP的检验和检测到。

TFTP的分组丢失可通过发送方的应用层超时与重传机制解决。

使用TFTP获取文件：

由于获取的文件有48行，因此48个Unix换行符被转化为48个CR/LF对（\r\n），因为默认使用netascii模式传送。

第一行是客户向服务器发送的读请求，由于目的UDP端口是TFTP的熟知端口，tcpdump将解释TFTP分组，并显示RRQ和文件名。19字节中包括2字节的操作码，7字节的文件名，1字节的0，8字节的netascii模式以及1字节的0。

第二行是服务器发回的数据，516字节包括2字节的操作码，2字节的数据块号和512字节的数据。第三行是对这个数据块的确认，它的4字节包括2字节的操作码和2字节的块编号。

第四行是服务器发回的第二份数据，其中的数据是450字节，这450字节和上次发回的512字节加起来正好是962字节的数据。

tcpdump仅在第一行解释了TFTP报文，而后面没有显示TFTP信息，这是因为服务器进程的端口在第一行和第二行发生了变化，TFTP需要客户向服务器的UDP熟知端口（69）发送第一个分组，之后服务器进程向服务器主机申请一个尚未使用的端口（上例是1077），服务器进程使用这个端口与客户进程进行数据交换，客户进程的端口号在上例中没有变化（1106）。服务器进程端口变化的原因在于不能占用熟知端口完成需要可能几十秒甚至数分钟的文件传输，需要在传输当前文件的过程中留出熟知端口供其他TFTP客户进程发送请求。

RIP服务器（Routing Information Protocol，路由信息协议）使用RIP服务器的熟知端口发回数据。如果TFTP也使用熟知端口进行数据传输，要么一个服务器进程在同一端口同时对多个客户进程进行多个文件的传输，要么在传输文件期间拒绝任何来自其他客户的请求，最简单的方式是让服务器进程在收到RRQ或WRQ后改用新端口。

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

UNIX系统下的TFTP服务器通常将它的用户ID和组ID设置为不是任何真正用户的值，这样只能访问有其他用户读或写属性权限的文件。

送往广播地址的TFTP请求应该被忽略，但并不是所有实现和API都对接收一个UDP数据报的进程提供该数据报的目的地址，因此很多TFTP服务器没有严格遵守这个限制。

当TFTP的块号到达65535时，会发生什么RFC并没有提到，具体实现应该能传送最大为33553920（65535*512）字节的文件，但很多实现在文件长度超过16776704（32767*512）字节时会失败，因为它们将块数目错误地表示为一个有符号的16位整数，而非一个无符号数。

TFTP每次在客户与服务器间传送数据的大小最大是512字节，因此TFTP的最大吞吐量就是512字节除以客户与服务器之间的往返时间。