TFTP报文格式及数据长度

TFTP提供功能单一、开销较小的文件传输服务，针对无需复杂交互的文件传输而设计，缺少标准FTP协议的多项特征，因此比FTP要简单。其主要特性有：基于UDP协议，使用超时重传方式保证数据到达；只提供文件的下载与上传功能，不提供获取文件和目录列表功能；不通过存取授权与用户认证机制。

TFTP多用于局域网或远程UNIX主机中，而互联网络中多用FTP。

TFTP初衷为引导无盘系统而提出，使无盘计算机启动时能从服务器上下载自举文件，在一些网络设备及嵌入式系统中应用广泛，如网络交换机在启动时从服务器上下载固件等。

1.TFTP协议

该协议基于UDP协议，而UDP是在IP协议上实现的，TFTP在IP报头中不指定任何数据，但需要使用UDP报头中的源和目的端口以及包长度字段。图8-4是TFTP报文封装格式。

图8-4 TFTP报文封装格式

TFTP共有5种类型的报文，所有TFTP报文都包含一个2B操作码（Opcode）字段，用于指示TFTP报文类型：读请求报文（RRQ）、写请求报文（WRQ）、数据报文（DATA）、响应报文（ACK）和差错报文（ERROR）。图8-5为5种TFTP报文具体格式。

读请求报文与写请求报文使用相同的格式。其中，“文件名”字段指明客户要读或写的文件在服务器上的位置，“模式”字段指明数据传输的模式，其取值可为字符串netascii或octet（不区分大小写），netascii表示数据是由多行ASCII字符组成的文本文件，octet表示将数据看做8位一组的字节流，并不做任何解释，用于传输二进制文件。图中“文件名”和“模式”字段的后面，都紧随着一个用于表示结束的“0”字节。

图8-55 种TFTP报文的格式(www.xing528.com)

数据报文：数据报文中包含一个2B的“块号”字段，块号从1开始编码，每传输一个数据则块号加1，这样接收方可以确定这个包是新数据还是已经接收过的数据。数据的长度从0～512B，除了最后一个数据分组可含有不足512B的数据，其他每个数据分组均含有512B的数据。

响应报文：在TFTP中，所有类型报文均可确认，但却不一定要使用响应报文。差错报文可被其他任何类型的报文确认，读请求报文和响应报文则由数据报文或差错报文来确认，响应报文用于确认写请求报文和数据报文。响应报文包含一个“块号”字段，用于确认已正确接收的数据，对于写请求的确认，“块号”取值为0。

差错报文：差错报文用于服务器不能处理读请求或写请求的情况，在文件传输过程中的读和写出错也会导致传送差错报文，随后停止传输。“差错码”字段指定错误的类型，“错误信息”是一个以“0”字节结束的ASCII字符串，包含额外的出错说明信息。

TFTP文件传输过程：客户端向服务器的69端口发送一个读请求或者写请求分组，同时建立一个连接，客户端使用端口随机产生。如服务器同意请求，则连接成功，接着是文件数据传输过程。除最后一个TFTP数据分组，每个数据分组包含固定512B长度文件数据。在发送下一个数据分组前，必须得到确认响应，如未收到确认，则必须一直等待，这种数据传输方式称停止等待方式，可确保所有过去的分组都已正确接收，但效率不高，一般只在较简单传输中使用。TFTP用超时重传机制保证数据的正确到达，如分组在网络中丢失，接收端在计时器超时之后重新发送分组。如传输中出现错误，通过差错报文分组通告错误发生。

2.TFTP规范中的问题

TFTP使用不可靠的UDP进行数据传输，并采用超时与重传机制来解决分组丢失的问题，这使得文件传输过程很简单。但当收发双方都使用超时与重传时，可能会出现一种称为“魔法”（Sorcerer's Apprentice Bug）的问题。这是一种因确认的延迟而导致的增量传输漏洞（图8-6）。当来自服务器的确认ACK（k）由于网络延时，没有在客户端定时器规定的时限内到达，客户端认为发生了分组丢失，将会重传分组k，服务器收到分组k后，再次发送确认ACK（k）。但因服务器发出的第一个ACK（k）并未丢失，若客户端先后收到两次ACK（k），会将分组k+l发送两次，服务器对每次收到的分组都发出一个确认，所以ACK（k+l）也会发送两次。如此下去，所有分组都将发送两次，造成重复传输。为解决这个问题，可关闭客户端定时器，以保证确认延迟时不会出现重传现象。

图8-6 TFTP中的Sorcerer's Apprntice Bug示意图

除该漏洞之外，由于TFTP实现简单，不涉及身份验证，不需提供用户名与密码，所以TFTP安全性也是一个问题。这一漏洞容易被黑客利用，为避免此问题，应保证用于无盘系统引导或设备固件相关的文件单独存放在服务器上或限制只能访问特定目录的文件。