RFC1350：THE TFTP PROTOCOL (REVISION 2)，July 1992
本备忘录的状态
此 RFC 为 Internet 社区指定了 IAB 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态及现状请参考现行版本的《IAB官方协议标准》。本备忘录的分发不受限制。
概括
TFTP 是一种用于传输文件的非常简单的协议。它的名字就是由此而来的，Trivial File Transfer Protocol 或 TFTP。每个非终端数据包都被单独确认。本文档描述了协议及其数据包类型。该文件还解释了一些设计决策背后的原因。
致谢
该协议最初由 Noel Chiappa 设计，并由他、Bob Baldwin 和 Dave Clark 重新设计，并由 Steve Szymanski 评论。该文件的当前版本包括与 Larry Allen、Noel Chiappa、Dave Clark、Geoff Cooper、Mike Greenwald、Liza Martin、David Reed、Craig Milo Rogers（USC-ISI）、Kathy Yellick 和作者。确认和重传方案受到 TCP 的启发，错误机制由 PARC 的 EFTP 中止消息提出。
Noel Chiappa 完成了 1992 年 5 月的修订，以修复“Sorcerer's Apprentice”协议错误 [4] 和其他小的文档问题。
这项研究得到了国防部高级研究计划局的支持，并由海军研究办公室根据合同编号 N00014-75-C-0661 进行监督。
1、 目的
TFTP 是一种简单的文件传输协议，因此被命名为普通文件传输协议或 TFTP。它已在 Internet 用户数据报协议（UDP 或数据报）[2] 之上实现，因此它可用于在不同网络上实现 UDP 的机器之间移动文件。（这不应排除在其他数据报协议之上实现 TFTP 的可能性。）它被设计为小而易于实现。因此，它缺乏常规 FTP 的大部分功能。它唯一能做的就是从/向远程服务器读取和写入文件（或邮件）。它不能列出目录，并且目前没有用户身份验证的规定。与其他 Internet 协议一样，它传递 8 位字节的数据。
当前支持三种传输模式：
netascii。（这是“美国信息交换标准代码”[1] 中定义的 ascii，并在“Telnet 协议规范”[3] 中指定了修改）请注意，它是 8 位 ascii。本文档中将使用术语“netascii”来表示此特定版本的 ascii。）；
octet，八位字节（这取代了本文档先前版本的“二进制”模式。）原始 8 位字节；
mail，邮件，netascii 字符发送给用户而不是文件。（邮件模式已过时，不应实施或使用。）其他模式可以由成对的协作主机定义。
有关 TFTP 的进一步有价值的指令和建议，应参考参考文献 [4]（第 4.2 节）。
2、 协议概述
任何传输都以读取或写入文件的请求开始，该文件也用于请求连接。如果服务器批准请求，则打开连接并以 512 字节的固定长度块发送文件。每个数据包包含一个数据块，在发送下一个数据包之前必须通过确认包确认。小于 512 字节的数据包表示传输终止。如果数据包在网络中丢失，预期接收者将超时并可能重新传输他的最后一个数据包（可能是数据或确认），从而导致丢失数据包的发送者重新传输丢失的数据包。发送方必须只保留一个数据包以进行重传，因为锁步确认可确保已收到所有旧数据包。请注意，传输中涉及的两台机器都被视为发送者和接收者。一个发送数据并接收确认，另一个发送确认并接收数据。
大多数错误会导致连接终止。通过发送错误数据包来指示错误。这个数据包没有被确认，也没有被重传（即，一个 TFTP 服务器或用户可能在发送错误消息后终止），因此连接的另一端可能无法得到它。因此，当错误数据包丢失时，超时用于检测这种终止。错误是由三种类型的事件引起的：无法满足请求（例如，找不到文件、访问冲突或没有此用户），接收到无法由网络中的延迟或重复解释的数据包（例如，格式不正确的数据包），并失去对必要资源的访问（例如，磁盘已满或在传输期间访问被拒绝）。
TFTP 只识别一种不会导致终止的错误情况，即接收到的数据包的源端口不正确。在这种情况下，错误数据包被发送到始发主机。
该协议非常严格，以简化实现。例如，固定长度的块可以直接进行分配，锁步确认提供流量控制并消除重新排序传入数据包的需要。
3、 与其他协议的关系
如前所述，TFTP 设计为在数据报协议 (UDP) 之上实现。由于数据报是在 Internet 协议上实现的，因此数据包将具有 Internet 报文头、数据报报文头和 TFTP 报文头。此外，数据包可能有一个报文头（LNI、ARPA 报文头等）以允许它们通过本地传输介质。如图 3-1 所示，数据包的内容顺序为：本地媒体头（如果使用）、Internet 头、数据报文头、TFTP 头，然后是 TFTP 数据包的其余部分。（这可能是也可能不是数据，具体取决于 TFTP 报文头中指定的数据包类型。） TFTP 没有指定 Internet 报文头中的任何值。另一方面，TFTP 使用数据报文头的源端口和目的端口字段（其格式在附录中给出），长度字段反映了 TFTP 数据包的大小。TFTP 使用的传输标识符（TID's）被传递到数据报层用作端口；因此它们必须在 0 到 65535 之间。TID 的初始化在初始连接协议部分讨论。
TFTP 报文头由一个 2 字节的操作码字段组成，指示数据包的类型（例如，DATA、ERROR 等）。这些操作码和各种类型的数据包的格式将在 TFTP 数据包一节中进一步讨论。
图 3-1：报文头顺序
4、 初始连接协议
通过发送请求（写入外部文件系统的 WRQ，或读取外部文件系统的 RRQ）并接收确定回复、写入确认包或读取的第一个数据包来建立传输。通常，确认包将包含被确认的数据包的块号。每个数据包都有一个与之关联的块号；块号是连续的并以 1 开头。由于对写入请求的确定响应是确认包，因此在这种特殊情况下，块号将为零。（通常，由于确认包是对数据包的确认，因此确认包将包含正在确认的数据包的块号。）如果回复是错误包，则请求已被拒绝。
为了创建连接，连接的每一端都为自己选择一个 TID，用于该连接的持续时间。为连接选择的 TID 应该是随机选择的，因此同一数字被立即连续选择两次的概率非常低。每个数据包都与连接两端的两个 TID 相关联，即源 TID 和目标 TID。这些 TID 被传递给支持的 UDP（或其他数据报协议）作为源端口和目标端口。请求主机如上所述选择其源 TID，并将其初始请求发送到服务主机上已知的 TID 69 十进制（八进制 105）。在正常操作下，对请求的响应使用服务器选择的 TID 作为其源 TID，并使用请求者为先前消息选择的 TID 作为其目标 TID。然后将两个选定的 TID 用于传输的其余部分。
例如，以下显示了用于建立连接以写入文件的步骤。请注意，WRQ、ACK 和 DATA 分别是数据包的写请求、确认和数据类型的名称。附录包含一个用于读取文件的类似示例。
1. 主机 A 向主机 B 发送一个“WRQ”，源 = A 的 TID，目的地 = 69。
2. 主机 B 向主机 A 发送“ACK”（块号 = 0），源 = B 的 TID，目的地 = A 的 TID。
此时连接已经建立，第一个数据包可以由主机 A 发送，序列号为 1。在下一步和所有后续步骤中，主机应确保源 TID 与在步骤 1 和 2 中达成一致。如果源 TID 不匹配，则应丢弃该数据包，因为该数据包是从其他地方错误发送的。错误数据包应该被发送到错误数据包的来源，同时不干扰传输。仅当 TFTP 实际上接收到具有不正确 TID 的数据包时，才能执行此操作。如果支持协议不允许，则不会出现此特定错误情况。
下面的示例演示了可能发生上述情况的协议的正确操作。主机 A 向主机 B 发送请求。在网络中的某处，请求数据包被复制，因此向主机 A 返回两个确认，在主机 B 上选择不同的 TID 以响应这两个请求。当第一个响应到达时，主机 A 继续连接。当请求的第二个响应到达时，它应该被拒绝，但没有理由终止第一个连接。因此，如果为主机 B 上的两个连接选择不同的 TID，并且主机 A 检查它接收到的消息的源 TID，则可以维持第一个连接，而通过返回错误数据包来拒绝第二个连接。
5、 TFTP 数据包
TFTP 支持五种类型的数据包，所有这些类型都在上面提到过：
数据包的 TFTP 报文头包含与该数据包关联的操作码。
图 5-1：RRQ/WRQ 数据包
RRQ 和 WRQ 数据包（分别为操作码 1 和 2）的格式如图 5-1 所示。文件名是 netascii 中以零字节结尾的字节序列。mode字段包含netascii中的字符串“netascii”、“octet”或“mail”（或大小写任意组合，如“NETASCII”、NetAscii等），表示协议中定义的三种模式。接收 netascii 模式数据的主机必须将数据转换为自己的格式。octet模式用于传输文件，该文件是正在传输文件的机器的 8 位格式。假设每种类型的机器都有一个更常见的 8 位格式，并且选择了该格式。例如，在DEC-20，36位机器上，这是四个8位字节到一个带有四位中断的字。如果主机收到八位字节文件然后返回，返回的文件必须与原始文件相同。mail模式使用邮件收件人的名称代替文件，并且必须以 WRQ 开头。否则与 netascii 相同模式。邮件收件人字符串应该是“用户名”或“用户名@主机名”的形式。如果使用第二种形式，它是允许中继计算机转发邮件的选项。
上面的讨论假设发送者和接收者都在相同的模式下运行，但没有理由必须是这种情况。例如，可以构建一个存储服务器。这样的机器没有理由需要将 netascii 翻译成它自己的文本形式。相反，发送者可能会以 netascii 格式发送文件，但存储服务器可能会简单地存储它们而不以 8 位格式进行转换。另一种这样的情况是目前存在于 DEC-20 系统上的问题。netascii 和 octet 都不能访问一个字中的所有位。人们可能会为这种机器创建一种特殊模式，它读取一个字中的所有位，但接收器以 8 位格式存储信息。当从存储站点检索到这样的文件时，必须将其恢复到其原始形式才能使用，因此也必须实现反向模式。用户站点必须记住一些信息才能实现这一点。在这两个示例中，请求数据包将指定外部主机的八位字节模式，但本地主机将处于其他模式。TFTP 中没有指定这样的机器或应用程序特定模式，但有一种与该规范兼容。
也可以定义其他模式来合作主机对，尽管这必须小心。不要求任何其他主机实现这些。没有中央机构可以定义这些模式或为其分配名称。
图 5-2：数据包
数据实际上以数据包的形式传输，如图 5-2 所示。数据包（操作码 = 3）具有块号和数据字段。数据包上的块号从 1 开始，每增加一个新的数据块就增加 1。此限制允许程序使用单个数字来区分新数据包和重复数据包。数据字段的长度为 0 到 512 个字节。如果是 512 字节长，则该块不是最后一个数据块；如果它的长度为 0 到 511 个字节，则表示传输结束。（有关详细信息，请参阅正常终止部分。）
除非发生超时 [4]，否则除了重复 ACK 和用于终止的数据包之外的所有数据包都会得到确认。发送 DATA 包是对前一个 DATA 包的第一个 ACK 包的确认。WRQ 和 DATA 包由 ACK 或 ERROR 包确认，而 RRQ 和 ACK 包由 DATA 或 ERROR 包确认。图 5-3 描述了一个 ACK 包；操作码是 4。ACK 中的块号与正在确认的 DATA 包的块号相呼应。WRQ 用块号为零的 ACK 包来确认。
图 5-3：ACK 包
图 5-4：ERROR 包
ERROR 数据包（操作码 5）采用图 5-4 中描述的形式。ERROR 数据包可以是任何其他类型数据包的确认。错误代码是一个整数，表示错误的性质。附录中给出了值和含义表。（请注意，本文档的此版本中添加了几个错误代码。）错误消息旨在供人使用，并且应该在 netascii 中。像所有其他字符串一样，它以零字节终止。
6、 正常终止
传输的结束由包含 0 到 511 个字节数据的 DATA 包标记（即，数据报长度 < 516）。与所有其他 DATA 数据包一样，该数据包由 ACK 数据包确认。确认最终 DATA 数据包的主机可以在发送最终 ACK 时终止其连接端。另一方面，鼓励赋闲。这意味着发送最终 ACK 的主机将在终止之前等待一段时间，以便在最终 ACK 丢失时重新传输它。如果确认器再次收到最终的 DATA 包，则确认器将知道 ACK 已丢失。发送最后一个 DATA 的主机必须重新传输它，直到数据包被确认或发送主机超时。如果响应是 ACK，则传输成功完成。如果数据的发送方超时并且不再准备重新传输，则传输可能仍然成功完成，之后确认方或网络可能出现问题。在这种情况下，传输也可能不成功。无论如何，连接已经关闭。
7、 提前终止
如果请求不能被批准，或者在传输过程中发生错误，则发送一个 ERROR 数据包（操作码 5）。这只是一种礼貌，因为它不会被重新传输或确认，因此它可能永远不会被接收到。超时也必须用于检测错误。
8、 附录
8.1、 报文头顺序
8.2、 TFTP 格式
8.3、 读取文件的初始连接协议
1. 主机 A 向主机 B 发送一个“RRQ”，源 = A 的 TID，目标 = 69。
2. 主机 B 向主机 A 发送一个“DATA”（块号 = 1），源 = B 的 TID，目的地 = A 的 TID。
8.4、 错误代码
互联网用户数据报文头 [2]。（这只是为了方便起见。TFTP 不需要在 Internet 用户数据报协议之上实现。）
格式
字段值
Source Port：源端口，由数据包的发起者选择。
Dest. Port：目的端口，由目标机器选择（RRQ 或 WRQ 为 69）。
Length：长度，UDP 数据包的字节数，包括 UDP 头。
Checksum：校验和，参考2描述了计算校验和的规则。（这个的实现者应该确保这里使用了正确的算法。）如果未使用，字段包含零。
注意：TFTP 将传输标识符 (transfer identifiers，TID) 传递给 Internet 用户数据报协议，以用作源端口和目标端口。
参考
[1] USA Standard Code for Information Interchange, USASI X3.4-1968. [2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information Sciences Institute, 28 August 1980. [3] Postel, J., "Telnet Protocol Specification," RFC 764, USC/Information Sciences Institute, June, 1980. [4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989.
安全注意事项
由于 TFTP 不包括登录或访问控制机制，因此必须注意授予 TFTP 服务器进程的权限，以免违反服务器主机文件系统的安全性。TFTP 通常与控件一起安装，这样只有具有公共读取访问权限的文件才能通过 TFTP 获得，并且不允许通过 TFTP 写入文件。
