提到 TFTP 这名字，老网络工程师会心一笑，新入行的朋友多半只在题库里见过。它是 Trivial File Transfer Protocol 的缩写，翻译过来就是“简单文件传输协议”，从 1980 年代活到今天，始终在网络设备的角落默默干活。很多人觉得它古老、简陋、没啥好讲的，但刷卡路由器固件、交换机升级、无盘工作站启动、PXE 批量装机、嵌入式板卡烧写，哪一样都绕不开它。
这篇文章我就把 TFTP 摊开讲清楚：它到底是个什么协议、帮你解决什么问题、怎么配置怎么用、实际项目里哪些场景非它不可。不管你是刚入行的运维、偶尔折腾路由器的玩家，还是做嵌入式开发的朋友，看完这篇基本就能上手操作，遇到问题也知道往哪个方向排查。
1. TFTP 到底是什么：一句话定义与协议背景
1.1 名字里的“Trivial”才是精髓
TFTP 全称 Trivial File Transfer Protocol，核心就在 Trivial 这个词上。它不是 FTP 的简配版，而是刻意做出的一台“傻瓜式传输机”。整个协议基于 UDP 实现，标准端口是 69，功能只有一个：把文件从一台机器搬到另一台机器。没有认证、没有目录浏览、没有权限体系、没有断点续传，甚至连“对方是否存在”这种基础校验都靠最原始的方式完成。
打个比方，FTP 像快递公司，有面单、有签收、有物流跟踪、有客服；TFTP 则像两个人隔着一扇窗户扔包裹，规则只有一条：扔过去一箱，对方喊一声“收到了”，确认后才扔下一箱。简单归简单，但在很多极端环境下，这种设计反而成了优点。
从协议栈位置看，TFTP 属于应用层协议，直接跑在 UDP 之上。早期设计目标是让最简单的设备也能实现文件收发的客户端，代码几千字节就能搞定，不需要复杂的 TCP 状态机。所以哪怕设备只有 8 位单片机、没有完整操作系统，也能轻松内置 TFTP 客户端。
1.2 和 FTP 的定位差异
很多人会问：既然有 FTP，为什么还要用 TFTP？两者的定位完全不同。
FTP 基于 TCP，提供用户名密码认证、目录列表、文件读写权限、断点续传、主动被动模式等完整功能。代价是实现复杂、依赖完整的 TCP/IP 协议栈，并且数据连接需要额外协商端口。TFTP 则砍掉了这一切，只保留最核心的“上传/下载文件”能力。
实际工程里，很多设备的 bootloader 阶段根本没有完整的 TCP/IP 协议栈，或者设备厂商不想为维护 FTP 客户端增加成本。比如路由器在 BootROM 模式、交换机进入 ROMmon 状态、嵌入式开发板的 U-Boot 环境，这些时候设备只能提供最小化的网络功能。TFTP 在这种环境下依然能工作，而 FTP 往往连跑都跑不起来。
另外，TFTP 的传输模型属于典型的“停止等待协议”：发送方发出一个数据块后必须停下来等待接收方确认，收到确认才继续发下一块。这种模型在低带宽、高延迟、易出错的早期网络环境中不够高效，但在局域网低延迟环境下完全够用，而且实现极简单，天然不容易出复杂状态问题。
2. TFTP 在解决什么问题：典型场景与价值定位
2.1 固件升级与恢复：网络设备的“急救通道”
TFTP 最大的“客户”就是网络设备本身。Cisco、华为、H3C、锐捷等品牌的路由器、交换机、无线控制器、防火墙，在系统完整运行的时候，固件备份升级大多可以用 FTP、HTTP、USB 等方式；可一旦系统损坏、配置清空、或者设备变砖，能用的往往只剩 TFTP。
以 Cisco 交换机为例，如果设备启动时进入 ROMmon 模式，只能敲少量命令。这时候最常见的恢复方法就是找一台 TFTP 服务器，把 IOS 镜像文件放进去，然后用类似tftpdnld或copy tftp: flash:的指令把固件拉回设备。华为的 VRP 系统、H3C 的 Comware 系统也有类似的 TFTP 加载命令。
这背后的原因很现实：设备出厂固件里的最小引导程序只需要内置 TFTP 客户端，因为它代码量小、状态简单、不需要维护账号体系，可靠性和兼容性都好控制。对一线运维来说，TFTP 服务器就是一套“设备急救箱”，平时不用，关键时刻能救命。
2.2 PXE 网络引导：装机界的老黄牛
如果说固件恢复是“急救”，那 PXE 网络引导就是 TFTP 最常见的“日常劳动”。PXE 全称 Preboot eXecution Environment，是 Intel 提出的网络启动标准。电脑从网卡启动时，首先通过 DHCP 获取 IP 地址和引导服务器信息，接着就会用内置的 TFTP 客户端去下载引导文件，比如pxelinux.0、bootx64.efi、wimboot等。
引导文件下载完成后，再由它加载内核、initrd 等文件，最终进入安装程序或无盘系统。也就是说，几乎所有现代批量装机流程的第一棒都是由 TFTP 完成的。
为什么引导阶段选 TFTP 而不是更快的方式？因为这时网卡的固件环境太简单了，只能实现最基础的网络协议，TFTP 就是这种“最小可用网络服务”的标准答案。操作系统起来之后，大文件镜像往往改用 HTTP、NFS 或 iSCSI 继续传输，但启动初期的“第一口奶”永远靠 TFTP。
2.3 嵌入式设备与配置下发
嵌入式开发是 TFTP 的另一个大本营。玩过 U-Boot 的朋友应该非常熟悉：开发板开机停在 U-Boot 提示符，用一条tftp 0x40000000 uImage的命令，就能把编译好的内核镜像从服务器拉到内存里启动。在调试阶段，这种“改一版烧一版”的流程比反复拆机烧写快太多。
量产阶段 TFTP 也用得很多。生产线上设备烧写系统镜像、写入序列号、下发配置文件，都是把 TFTP 服务架在本地局域网，设备通过脚本自动上传或下载文件。因为文件通常不大、网络环境封闭、操作流程固定，TFTP 的短板被完美绕开，剩下的全是低成本和高效率。
3. TFTP 协议机制：512 字节块与确认逻辑
3.1 通信流程：RRQ/WRQ/DATA/ACK
真正上手用 TFTP 之前，最好把它的报文交互逻辑理解清楚。TFTP 只有五种报文类型：读请求 RRQ、写请求 WRQ、数据 DATA、确认 ACK、错误 ERROR。
下载文件时，客户端发送 RRQ 报文，包含文件名和传输模式，模式分netascii、octet和已废弃的mail。上传文件时，客户端发的是 WRQ 报文。服务器收到请求后开始传数据，每块数据最多 512 字节，客户端收到一个 DATA 包后回一个对应块号的 ACK，服务器收到 ACK 才发下一个 DATA 包。
这里有个关键机制：文件结束靠“小于 512 字节的数据块”来标识。如果文件大小恰好是 512 的整数倍，最后会补发一个 0 字节的数据包，表示“传完了”。如果客户端发送请求后迟迟等不到数据，会超时重发请求；数据传输中超时，则重发上一次的 ACK 或 DATA。默认超时时间一般是 5 秒，但可以通过选项协商调整。
TFTP 走 UDP 69 端口，之后的交互都围绕这一组端口进行，不像 FTP 需要额外建立数据连接。这种单会话模型的好处是状态简单、防火墙策略容易理解；坏处是没有真正的“连接”，只能靠超时和确认来保证传输。
协议还定义了错误码，常见的有：0 未定义错误、1 文件未找到、2 访问违例、3 磁盘满、4 非法操作、5 未知传输 ID、6 文件已存在、7 用户不存在。排查问题时，看客户端报的“Error code”基本就能定位一大半。
3.2 常见选项：blksize、timeout、tsize 怎么用
老标准里固定 512 字节确实太慢。局域网传一个 100MB 固件，要拆成 20 多万个包，每个包都要等 ACK，速度惨不忍睹。为此后来有了 RFC 2347、2348、2349 定义的扩展选项：
blksize：把每块数据从 512 字节调大，比如 1468 或 65464。最常用的安全值是 1468，因为以太网 MTU 是 1500，减去 IP 头 20 字节、UDP 头 8 字节、TFTP 头 4 字节，剩下 1468 字节刚好不会触发 IP 分片。千兆局域网里用 1468 能把传输效率提升数倍。timeout：调整超时重传时间，默认 5 秒。在弱网环境或跨三层传输时，适当增大可以避免误判超时。tsize：传输前告知文件大小，方便接收方预分配空间，也能提前判断磁盘容量够不够。
Linux 下的 tftp-hpa 客户端用-b参数指定块大小，例如tftp -b 1468 192.168.1.10。图形化工具如 Tftpd64 则在界面里直接提供 Block Size 下拉框。需要提醒的是，这些选项必须客户端和服务器同时支持，如果服务器不支持，两边会自动回退到 512 字节模式，传输照常进行但速度会掉回去。
4. TFTP 实用配置与基本操作：Windows 和 Linux 都能跑
4.1 客户端安装与常用命令（get/put）
先聊客户端。Windows 系统其实自带 TFTP 客户端，但默认没启用，需要到“可选功能”里勾选“TFTP 客户端”。启用后在命令行里直接敲：tftp -i 192.168.1.10 GET firmware.bin。这里的-i表示二进制模式，下载的话源文件名是服务器上的固件名，目标文件名默认保存在当前目录。
Linux 下最常用的是 tftp-hpa 客户端，安装命令：
sudo apt update && sudo apt install tftp-hpa装完进入交互模式：
tftp 192.168.1.10交互模式下常用子命令有：connect指定服务器、mode binary切到二进制模式、verbose打开详细输出、trace显示每一个发出的包、get 文件名下载、put 文件名上传、quit退出。调试阶段我强烈建议打开 verbose 和 trace，操作过程会变成这样：
tftp> verbose Verbose mode on. tftp> trace Packet tracing on. tftp> get test.bin getting from 192.168.1.10 test.bin to test.bin sent RRQ <file=test.bin, mode=octet> received DATA <block=1, 512 bytes> sent ACK <block=1> ...看到 DATA 和 ACK 你来我往，才算真正理解 TFTP 的锁步传输逻辑。
4.2 服务端配置：Linux 上的 tftpd-hpa 与 dnsmasq
Linux 做 TFTP 服务器最简单的方式是 tftpd-hpa。安装：
sudo apt install tftpd-hpa它的配置在/etc/default/tftpd-hpa，典型内容如下：
TFTP_USERNAME="tftp" TFTP_DIRECTORY="/srv/tftp" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="--secure"--secure参数表示把 TFTP 根目录锁定到TFTP_DIRECTORY，客户端无法通过../跳出目录，这是必须开启的安全项。改完配置重启服务：
sudo systemctl restart tftpd-hpa还要注意目录权限。很多新手把文件拷进目录却下载失败，多半是 tftp 用户没有读权限。建议统一交给 tftp 用户管理：
sudo mkdir -p /srv/tftp sudo chown -R tftp:tftp /srv/tftp sudo chmod -R 755 /srv/tftp如果只是临时搭一个轻量 TFTP 服务，dnsmasq 也能一肩挑。在/etc/dnsmasq.conf里加两行：
enable-tftp tftp-root=/srv/tftp重启 dnsmasq 即可。这种方式特别适合做 PXE 环境，DHCP、TFTP、DNS 全挤在一个轻量服务里，省心。
Windows 下则常见 Tftpd64 这类图形化工具，设置好 Current Directory 和服务器监听地址，启动后就是现成的 TFTP 服务器。做实验和临时运维都方便，但生产环境我仍然建议用 Linux 版本。
4.3 安全边界：为什么 TFTP 不能乱开
TFTP 协议本身没有任何认证机制。任何人只要能访问你的 TFTP 端口，就能读取服务器上权限允许的文件；如果目录对写开放，甚至可以任意写入文件。再加上传输过程是明文，固件、配置文件的保密性、完整性都无从保证。
所以生产环境里 TFTP 有几条铁律：
- 只能跑在可信内网或专用管理网段，永远不要直接暴露到公网。
- 服务器上用
--secure锁死根目录，不要给 TFTP 服务高权限账号。 - 如果允许写操作，尽量用防火墙把来源 IP 限定为少数管理终端。
- 重要文件传输完成后立即核对哈希值，防止中途丢包或写坏。
我见过不少项目把 TFTP 服务架在通用业务服务器上，甚至用 NAT 映射到公网，这是典型的安全事故隐患。不是 TFTP 本身可怕，而是没有认证的文件读写能力暴露出去，等于把门钥匙挂在门口。
5. 实操案例：从零搭建设备固件备份与恢复环境
5.1 环境准备与参数选择
直接讲一个完整的实操场景：给一台局域网内的网络设备做固件备份和升级，服务器是一台 Ubuntu 系统。这个场景能覆盖 TFTP 最常见的读写需求，也可以原样迁移到交换机、路由器、嵌入式板卡上。
我的网络规划是：服务器 IP192.168.1.10，设备 IP192.168.1.1，服务器目录/srv/tftp只服务管理网段。为了提升传输速度，客户端用 tftp-hpa 的-b 1468参数指定块大小；如果遇到老设备不支持 blksize 协商，会自然回退到 512 字节，不影响功能。
防火墙方面，只对内网管理网段放行 UDP 69 端口：
sudo ufw allow from 192.168.1.0/24 to any port 69 proto udp5.2 完整操作步骤与验证过程
第一步，安装和配置服务端：
sudo apt install tftpd-hpa -y sudo mkdir -p /srv/tftp sudo chown -R tftp:tftp /srv/tftp编辑/etc/default/tftpd-hpa：
TFTP_USERNAME="tftp" TFTP_DIRECTORY="/srv/tftp" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="--secure"重启服务并检查状态：
sudo systemctl restart tftpd-hpa sudo systemctl status tftpd-hpa --no-pager第二步，把待升级固件router_fw.bin放到/srv/tftp目录，同时从设备上备份当前配置到本地。
第三步，在另一台 Linux 管理机上测试下载：
tftp -b 1468 192.168.1.10 -c get router_fw.bin如果交互模式下，可以这样验证上传：
tftp 192.168.1.10 tftp> mode binary tftp> put backup.cfg tftp> quit传完之后比对哈希：
md5sum router_fw.bin /srv/tftp/router_fw.bin两端一致就说明传输完整。这个步骤特别重要，固件文件坏一个字节，设备刷入后可能直接变砖。
第四步，在网络设备侧操作。不同厂商命令差别很大，但思路一致。Cisco 设备在特权模式下备份配置到 TFTP 服务器：
copy running-config tftp:按提示输入 TFTP 服务器地址和文件名。升级固件则用：
copy tftp: flash:输入服务器上固件文件名后，设备就开始通过 TFTP 下载并写入 flash。华为设备类似，常用tftp 192.168.1.10 get vrpfile.cc配合startup saved-configuration等命令。操作之前一定确认设备剩余 flash 空间足够，不然传到一半报 disk full，设备可能留下不完整镜像。
5.3 常见问题与排查技巧实录
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 客户端报 Timeout | 防火墙拦截 UDP 69，或服务端没监听 | ss -ulnp | grep 69看服务，抓包看有没有收到 RRQ |
| 能下载不能上传 | TFTP 目录对 tftp 用户不可写 | 检查/srv/tftp权限，chown tftp:tftp |
| 大文件传一半停住 | 磁盘满、目录权限中途变化、blksize 过大网络分片丢包 | 先查磁盘df -h，再试小 blksize |
| 传输速度远低于预期 | 默认 512 字节块，或协商失败回退 | 客户端加-b 1468，服务端确认支持 options |
| 文件传完了但大小不匹配 | 文件末尾数据块处理异常 | 明确octet二进制模式，别用 netascii |
| Windows 客户端连不上 | Windows 防火墙拦了出站 UDP，或服务端绑定了非本机地址 | 检查服务端TFTP_ADDRESS，临时放行测试 |
排查 TFTP 问题最实用的一招是抓包。在服务器上执行sudo tcpdump -i any udp port 69，立刻能看清客户端有没有发请求、服务器有没有回包、超时重传发生在哪个环节。很多“死活传不过去”的问题，抓包后一分钟就能定位。
还有一个经典坑：文件大小恰好是 512 的整数倍时，许多老设备或精简客户端不会发送最后的 0 字节包，导致接收方认为传输未完成。如果遇到“文件大小正确但软件提示失败”的情况，优先怀疑这一点。
6. TFTP 工具推荐与实际项目里的取舍
6.1 常用 TFTP 工具对比
| 工具 | 平台 | 特点 | 适合场景 |
|---|---|---|---|
| tftpd-hpa | Linux | 标准可靠，支持 blksize 扩展 | 生产环境、自动化脚本 |
| dnsmasq | Linux | 内置 TFTP，轻量，能和 DHCP 联动 | PXE 引导环境 |
| atftpd | Linux | 多线程实现，并发能力好 | 批量传输、负载较高场景 |
| Tftpd64 | Windows | 图形化，带 DHCP/TFTP 多种服务 | 临时环境、教学演示 |
| SolarWinds TFTP Server | Windows | 免费图形化，界面友好 | 桌面运维人员 |
| Windows 自带 tftp | Windows | 无需安装，功能弱 | 应急下载文件 |
我个人用得最多的是 tftpd-hpa 加 dnsmasq 的组合：一个负责文件传输，一个负责 PXE 引导联合分配。如果只是临时从 Windows 上给一台设备导配置，Tftpd64 也够用。
6.2 什么时候该选 TFTP，什么时候别用 TFTP
结合这些年的项目经验，我的判断标准很简单：文件小、网络可控、目标设备只有 TFTP 客户端，那就用它；文件大、网络不可信、要求认证或加密，就不要硬撑。
TFTP 适合的四类场景：
- 网络设备 bootloader 阶段的固件恢复和升级。
- PXE 引导初期下载引导文件。
- 嵌入式开发板和 U-Boot 调试下载镜像。
- 封闭内网里的小文件批量下发。
千万别用在以下场景：跨公网传输文件、传输 GB 级系统镜像、传输配置文件需要保密或防篡改、希望在传输中对文件做断点续传。这些需求请直接上 HTTP/SFTP/FTP/NFS，不要折磨 TFTP 也折磨自己。
最后分享一个小技巧：做 PXE 装机环境时，早期引导文件用 TFTP 没问题，但真实系统镜像文件我通常不直接丢给 TFTP 传。等内核起来后，用 HTTP 或者 NFS 挂载安装源，速度快得多。把 TFTP 当成“点火器”而不是“发动机”，选型就不会错。
