TFTP协议

TFTP协议

1. 目的

TFTP是一个传输文件的简单协议，它其于UDP协议而实现，但是我们也不能确定有些TFTP协议是基于其它传输协议完成的。此协议设计的时候是进行小文件传输的。因此它不具备通常的FTP的许多功能，它只能从文件服务器上获得或写入文件，不能列出目录，不进行认证，它传输8位数据。传输中有三种模式：netascii，这是8位的ASCII码形式，另一种是octet，这是8位源数据类型；最后一种mail已经不再支持，它将返回的数据直接返回给用户而不是保存为文件。

2. 概况

任何传输起自一个读取或写入文件的请求，这个请求也是连接请求。如果服务器批准此请求，则服务器打开连接，数据以定长512字节传输。每个数据包包括一块数据，服务器发出下一个数据包以前必须得到客户对上一个数据包的确认。如果一个数据包的大小小于512字节，则表示传输结构。如果数据包在传输过程中丢失，发出方会在超时后重新传输最后一个未被确认的数据包。通信的双方都是数据的发出者与接收者，一方传输数据接收应答，另一方发出应答接收数据。大部分的错误会导致连接中断，错误由一个错误的数据包引起。这个包不会被确认，也不会被重新发送，因此另一方无法接收到。如果错误包丢失，则使用超时机制。错误主要是由下面三种情况引起的：不能满足请求，收到的数据包内容错误，而这种错误不能由延时或重发解释，对需要资源的访问丢失（如硬盘满）。TFTP只在一种情况下不中断连接，这种情况是源端口不正确，在这种情况下，指示错误的包会被发送到源机。这个协议限制很多，这是都是为了实现起来比较方便而进行的。

3. 与其它协议的联系

因为TFTP使用UDP，而UDP使用IP，IP可以还使用其它本地通信方法。因此一个TFTP包中会有以下几段：本地媒介头，IP头，数据报头，TFTP头，剩下的就是TFTP数据了。TFTP在IP头中不指定任何数据，但是它使用UDP中的源和目标端口以及包长度域。由TFTP使用的包标记（TID）在这里被用做端口，因此TID必须介于0到65,535之间。对它的初始化我们在后面讨论。TFTP头中包括两上字节的操作码，这个码指出了包的类型下面我们看看大体上的TFTP包格式，相关的内容我们在后面的章节中进行讨论。

---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------
图3-1: 包头次序

4. 初始连接

初始连接时候需要发出WRQ（请求写入远程系统）或RRQ（请求读取远程系统），收到一个确定应答，一个确定可以写出的包或应该读取的第一块数据。通常确认包包括要确认的包的包号，每个数据包都与一个块号相对应，块号从1开始而且是连续的。因此对于写入请求的确定是一个比较特殊的情况，因此它的包的包号是0。如果收到的包是一个错误的包，则这个请求被拒绝。创建连接时，通信双方随机选择一个TID，因此是随机选择的，因此两次选择同一个ID的可能性就很小了。每个包包括两个TID，发送者ID和接收者ID。这些ID用于在UDP通信时选择端口，请求主机选择ID的方法上面已经说过了，在第一次请求的时候它会将请求发到TID 69，也就是服务器的69端口上。应答时，服务器使用一个选择好的TID作为源TID，并用上一个包中的TID作为目的ID进行发送。这两个被选择的ID在随后的通信中会被一直使用。下例是一个写入的例子，其中WRQ，ACK和DATA代表写入请求，确认和数据。

1. 主机A向主机B发出WRQ，其中端口为69
2. B机向A机发出ACK，块号为0，包括B和A的TID

此时连接建立，第一个数据包以序列号1从主机开始发出。以后两台主机要保证以开始时确定的TID进行通信。如果源ID与原来确定的ID不一样，这个包会被认识为发送到了错误的地址而被抛弃。错误的包是被发送到正确端口的，但是包本身有错误。设想发送方发出一个请求，这个请求在网络的那个设备中被复制成两个包，接收方先后接收到两个包。接收方会认为为这是两个独立的请求，会返回两个应答。当这两个应答其中之一被接收到时，连接已经建立。第二个应答再到达时，这个包会被抛弃，而不会因为接收到第二个应答包而导致第一个建立的连接失败。

5. TFTP包

TFTP支持五种类型的包，我们在以上已经说明这五种类型的包：

opcode operation
1 Read request (RRQ)
2 Write request (WRQ)
3 Data (DATA)
4 Acknowledgment (ACK)
5 Error (ERROR)

包头中包括了这个包所指定的操作码。

2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------

Figure 5-1: RRQ/WRQ包

RRQ和WRQ包（代码分别为1和2）的格式如上所示。文件名是NETASCII码字符，以0结束。 而MODE域包括了字符串"netascii"，"octet"或"mail"，名称不分大小写。接收到NETASCII格式数据的主机必须将数据转换为本地格式。OCTET模式用于传输文件，这种文件在源机上以8位格式存储。假设每个机器都存在一个8位的格式，这样的假设是最一般的。比如DEC-20，这是一种36位机，我们可以假设它是4个8位外加另外4位而构成。如果机器收到OCTET格式文件，返回时必须与原来文件完全一样。在使用MAIL模式时，用户可以在FILE处使用接收人地址，这个地址可以是用户名或用户名@主机的形式，如果是后一种形式，允许主机使用电子邮件传输此文件。如果使用MAIL类型，包必须以WRQ开始，否则它与NETASCII完全一样。我们的讨论建立在发送方和接收方都在相同模式的情况下，但是双方可以以不同的模式进行传输。例如一个机器可以是一台存储服务器，这样一台服务器需要将NETASCII格式转换为自己的格式。另外，我们可以设想DEC-20这种机器，它使用36位字长，用户这边可以使用特殊的机制一次读取36位，而服务器却可以仍然使用8位格式。在这两种情况下，我们看到了两台机器使用不同格式的情况。可以在两台主机间定义其它的传输方式，但是定义要小心，因为这种传输方式不为人知，而且也没有权威机构为其指定名称或定义它的模式。

2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有