【翻译】RFC1350-TFTP通讯协议

此份文档为RFC1350的翻译，由于翻译此份文档的初衷是笔者希望实现一个TFTP服务器用来作为UDP协议学习中的练手项目，因此笔者在翻译时省略了原文档开头与协议本身无关的一些声明类章节。TFTP是一个非常简单易用的文件传输协议，如果希望在单片机上实现一个简单的通过网口或者串口更新用户程序的bootloader，此协议应该十分适合用于传输升级用的hex/bin文件。

1. 协议用途

TFTP是一种简单的文件传输协议，因此其被命名为简单文件传输协议(Trivial File Transfer Protocol)或者称为TFTP。其实现于互联网用户数据报协议的上层(UDP或Datagram)，所以其可以在位于不同网络的计算机之间传输文件，只要这些计算机实现了互联网用户数据报协议。(此外，亦不排除在其他数据报协议之上实现TFTP协议的可能性。)此协议被设计成一种精简的、容易实现的协议。因此，与常规的FTP协议相比，TFTP协议缺少常规FTP协议中的大部分特性。TFTP唯一做的事就是从服务器读取文件或者写入文件到服务器。它不能列出目录，并且不支持用户身份认证。与其他的互联网协议一样，它传输8位长度的字节数据。

TFTP协议目前支持三种传输模式：

• netascii(这是一种由 “USA Standard Code for INformation Interchange” 定义，在 “Telnet Protocol Specification” 中修改了部分特性的ascii码，请牢记这是一种8位长度的ascii码。“netascii” 这个词将在此文档中通篇使用，用于指代这种特殊格式的ascii码。)；
• octet(这替代了此文档之前版本的“binary”一词)原始8位字节；
• mail，直接发送给用户的netascii字符，而不是存为一个文件。(mail模式已被废弃，并且不应该被实现和使用。)

其他模式可以通过主机之间自行协商来实现。可以参考章节4.2获知更多关于TFTP的有价值的指引和建议。

2. 协议概述

任何传输都开始于一个读文件请求或者写文件请求，读/写文件请求同时也用于建立连接。如果服务器同意连接，连接便处于打开状态，随后文件分隔为长度512字节的块进行传输。每个数据包包含一个数据块，并且每一个数据包必须被应答包应答，之后才能发送下一个数据包。一个低于512字节长度的数据包意味着一次完整传输的结束。如果一个包在网络中遗失了，这个包的接收方将会在接收超时后回发最后收到的包(可以为数据包或者应答包)，这会使得发送方重发这个遗失的包。发送者必须在手边保留一个包以便重传，这样一来，这种环环相扣的应答机制确保了所有更早的包(在新的包之前)被成功接收。牢记所有参与传输的机器均同时作为接收方和发送方。一方发送数据并接收应答，另一方发送应答并接收数据。

大部分的错误会导致连接的终止。一个错误会以发送一个差错包的方式被标识。这个包不会被应答或重发(比如，一个TFTP服务器或客户端会在发送一个错误信息之后断开连接，所以连接的另一方可能不会收到这个差错包。)因此，当差错包遗失时，超时机制被用于处理此类连接中断。有三种事件会导致错误：无法响应请求(比如：文件不存在、非法访问、或者用户不存在)，接受到由于网络传输延迟或者重复导致的无法识别的包(比如，一个格式错误的包)，以及丢失对必要资源的访问权限(比如，磁盘满或者传输过程中的拒绝访问)。

只有在一种错误情况下，TFTP不会终止连接，即接收包的源端口不正确。在这种情况下，一个差错包将被发送给源主机。(译者注： “接收数据包的源端口不正确” 这句话可以参考其后的章节4中的建立连接的例子理解。)

3. 协议的其他相关事宜

之