4、TFTP协议深度解析：TFTP报文格式（RRQ/WRQ/DATA/ACK/ERROR）、传输模式（octet/netascii）、超时重传机制
TFTP，全称Trivial File Transfer Protocol。名字里就带着“Trivial”，说明它天生就是个轻量级选手。跟它的老大哥FTP比起来，TFTP简单到几乎没有安全机制，连认证都没有。但正是这种简单，让它成了网络启动场景里的常青树。
我个人习惯把TFTP看作“裸奔的文件搬运工”。它只做一件事：从服务器读文件，或者往服务器写文件。别的什么都不管。你想想看，在PXE启动的环境里，客户端连操作系统都没有，哪来的复杂协议栈？TFTP这种极简设计，恰恰是它的核心竞争力。
核心要点：TFTP基于UDP，端口号69。没有认证、没有加密、没有目录列表。它只支持读和写两种操作，但足够完成网络启动的文件传输任务。
4.1 TFTP报文格式
TFTP的报文结构非常紧凑。每个报文都固定以2字节的操作码开头，后面跟着不同类型的负载。我刚开始调网络启动时，觉得这协议太“寒酸”了，后来才发现，正是这种紧凑设计让它在资源受限的环境里跑得飞快。
TFTP定义了5种报文类型：
| 操作码 | 报文类型 | 用途 |
|---|---|---|
| 1 | RRQ (Read Request) | 读请求，客户端请求从服务器下载文件 |
| 2 | WRQ (Write Request) | 写请求，客户端请求向服务器上传文件 |
| 3 | DATA (Data) | 数据报文，承载实际文件内容 |
| 4 | ACK (Acknowledgment) | 确认报文，确认收到数据块 |
| 5 | ERROR (Error) | 错误报文，报告传输异常 |
4.2 RRQ/WRQ报文
RRQ和WRQ的报文结构完全一样，只是操作码不同。它们都包含文件名和传输模式两个字段，以0字节作为分隔符。
RRQ/WRQ报文格式：
+-------+-------+-------+-------+-------+-------+-------+-------+
| Opcode | Filename (可变长) | 0 | Mode (可变长) | 0 |
+-------+-------+-------+-------+-------+-------+-------+-------+
Opcode: 2字节，RRQ为1，WRQ为2
Filename: 可变长字符串，以0字节结尾
Mode: 可变长字符串，以0字节结尾，值为"octet"或"netascii"嗯，这里要注意。文件名不能包含路径分隔符，比如“/”或“\”。为什么？因为TFTP的设计哲学就是简单，路径解析会增加复杂度。我在项目中遇到过有人试图传“/boot/vmlinuz”，结果服务器直接返回错误。正确的做法是只传文件名，路径由服务器端配置决定。
4.3 DATA/ACK报文
TFTP的数据传输采用“停等协议”。发送方发一个数据块，必须等到接收方确认，才能发下一个。数据块大小固定为512字节，除了最后一个块。
DATA报文格式：
+-------+-------+-------+-------+-------+-------+-------+-------+
| Opcode=3 | Block # (2字节) | Data (0-512字节) |
+-------+-------+-------+-------+-------+-------+-------+-------+
ACK报文格式：
+-------+-------+-------+-------+-------+-------+-------+-------+
| Opcode=4 | Block # (2字节) |
+-------+-------+-------+-------+-------+-------+-------+-------+块编号从1开始递增。如果数据块小于512字节，表示文件传输结束。这个机制很巧妙——不需要单独的“文件结束”标记，数据本身就能表达结束信号。
实战技巧：我曾经调试过一个PXE启动失败的问题，发现TFTP传输到某个特定文件时总是卡住。抓包一看，客户端发了DATA，服务器回了ACK，但客户端就是不继续发下一个块。最后发现是客户端实现的块编号溢出处理有bug——块编号达到65535后没有正确回绕。虽然理论上很少传这么大的文件，但网络启动的initrd文件有时确实会超过32MB。
4.4 ERROR报文
当传输出现异常时，发送方会发ERROR报文终止传输。错误码定义如下：
| 错误码 | 含义 | 典型场景 |
|---|---|---|
| 0 | 未定义错误 | 通用错误，具体看错误消息字符串 |
| 1 | 文件未找到 | 请求的文件在服务器上不存在 |
| 2 | 访问违规 | 权限不足，比如写文件时目录只读 |
| 3 | 磁盘满 | 服务器存储空间不足 |
| 4 | 非法操作 | 收到无法识别的操作码 |
| 5 | 未知传输ID | UDP端口不匹配，常见于穿越NAT时 |
| 6 | 文件已存在 | 写请求时目标文件已存在 |
| 7 | 无此用户 | 很少用到，保留字段 |
ERROR报文格式：
+-------+-------+-------+-------+-------+-------+-------+-------+
| Opcode=5 | ErrorCode (2字节) | ErrMsg (可变长) | 0 |
+-------+-------+-------+-------+-------+-------+-------+-------+4.5 传输模式：octet vs netascii
TFTP支持两种传输模式。这个选择直接影响文件内容的解释方式。
| 模式 | 说明 | 适用场景 |
|---|---|---|
| octet | 原始字节流，不做任何转换 | 二进制文件：内核、initrd、固件镜像 |
| netascii | 文本模式，进行换行符转换 | 纯文本配置文件 |
octet模式就是“原样传输”。服务器读到什么字节，客户端就收到什么字节。网络启动场景下，99%的情况都用octet模式。因为内核和initrd都是二进制文件，任何字节转换都会导致文件损坏。
netascii模式会把换行符转换成CRLF序列。这在跨平台传输文本文件时有用，但网络启动里几乎不用。我曾经见过一个案例，有人用netascii模式传内核，结果内核启动时直接panic——因为二进制数据里的某些字节被“智能”转换了。
避坑指南：网络启动时，永远使用octet模式。如果你在DHCP选项或启动配置里看到mode参数，务必确认它是octet。我曾经调试过一个启动失败的问题，折腾了两天才发现是tftp服务器默认配置成了netascii模式。
4.6 超时重传机制
TFTP的可靠性完全依赖超时重传。因为底层是UDP，不保证送达。TFTP自己实现了一套简单的重传逻辑。
基本流程是这样的：
- 发送方发出一个数据包（DATA或ACK）
- 启动一个定时器，初始超时值通常设为5秒
- 如果在超时前收到对应确认，取消定时器，继续下一块
- 如果超时未收到确认，重传相同的数据包
- 每次重传后，超时时间加倍（指数退避）
- 重传次数达到上限（通常3-5次），终止传输并报错
这个机制看着简单，但实际调优时坑不少。我个人的经验是：
- 初始超时值：局域网环境2-3秒就够了，广域网可能需要5-8秒。PXE启动时，如果DHCP和TFTP服务器在同一网段，2秒绰绰有余。
- 重传次数：3次是底线。有些实现只重传2次，在丢包率稍高的网络里就容易失败。我建议至少设4次。
- 指数退避：第一次超时等2秒，第二次等4秒，第三次等8秒。这样既不会过早放弃，也不会在丢包时疯狂重传浪费带宽。
关键机制：TFTP的“停等协议”意味着同一时刻只有一个数据包在传输。这限制了吞吐量，但也让实现变得极其简单。对于网络启动这种小文件传输场景，这个设计完全够用。
4.7 TFTP传输流程全景图
下面这张图展示了TFTP一次完整的读请求传输流程。从客户端发起RRQ开始，到服务器发送最后一个小于512字节的数据块结束。
这张图展示的是理想情况。实际网络里，丢包、乱序、超时都可能发生。但TFTP的设计足够健壮——只要重传机制正常工作，最终都能把文件传完。
4.8 超时重传的实战调优
我在实际项目中遇到过不少TFTP超时相关的问题。这里分享几个调优经验：
- 局域网环境：初始超时设2秒，重传3次。如果网络质量好，甚至可以降到1秒。PXE启动时，每次重传都会增加几秒延迟，3次重传就是6秒，用户还能接受。
- 跨网段环境：初始超时设5秒，重传5次。跨路由器时延迟和丢包率都会增加，需要更宽容的参数。我曾经调过一个跨三层交换机的PXE环境，初始超时设到8秒才稳定。
- 大文件传输：如果文件超过10MB，考虑启用TFTP的“块大小协商”扩展（RFC 2348）。默认512字节的块大小在传大文件时效率很低。我见过有人传一个50MB的initrd，默认配置下要传10万多个包，耗时超过2分钟。启用块大小协商后，把块大小提到1468字节（避免IP分片），时间缩短到40秒。
调试技巧：抓包是排查TFTP问题的最好方法。用tcpdump或Wireshark过滤udp port 69，你能清楚看到每个数据包的发送和确认。如果发现大量重传，要么是网络丢包，要么是服务器处理不过来。我曾经用这个方法定位过一个bug——某款交换机的UDP校验和计算有误，导致TFTP数据包被随机丢弃。
4.9 总结
TFTP虽然简单，但网络启动离不了它。它的报文格式清晰，传输模式明确，超时重传机制虽然原始但足够可靠。理解这些细节，能帮你快速定位PXE启动过程中的文件传输问题。
嗯，最后说一句。如果你在调网络启动时遇到“TFTP timeout”之类的错误，别慌。先检查网络连通性，再看服务器配置，最后抓包分析。大部分问题都出在超时参数或防火墙规则上，跟协议本身关系不大。