tftpd64 实战指南：TFTP 协议原理、服务端配置与排错技巧

1. 为什么还要折腾 TFTP 这种“古董”协议

第一次接触 TFTP 的人，多半是被它的“简陋”劝退的：没有目录列表、没有认证、没有断点续传，连传输层都直接架在 UDP 上，看起来像是网络协议课上的一个反面教材。但如果你在嵌入式开发、网络设备固件升级、无盘工作站启动、工业控制设备参数下发这些场景里摸爬滚打过，就会发现 TFTP 出现的频率高得离谱。原因很简单：它足够小、足够轻、足够好实现。很多设备的引导程序（Bootloader）里塞不下完整的 FTP 或 HTTP 协议栈，但塞一个 TFTP 客户端只需要几 KB 的代码空间，这就是它几十年不倒的根本原因。

tftpd64 是 Windows 平台上最常被拿来当 TFTP 服务端使用的工具之一，它其实是一个套件，除了 TFTP 服务端，还集成了 TFTP 客户端、DHCP 服务端、DNS 服务端、SNTP 服务端等功能。很多人只用到它的 TFTP Server 模块，用来给交换机刷固件、给开发板传内核镜像、给工控设备下发配置文件。这篇文章就围绕 tftpd64 这个工具，把 TFTP 协议原理、服务端配置、客户端操作、以及实际排错过程中踩过的坑，完整地梳理一遍。

这篇文章适合谁看？如果你正在做嵌入式开发、网络运维、设备调试，或者单纯想搞明白“为什么我的 TFTP 传输总是超时”，那这篇内容应该能帮你省下不少查资料的时间。我会尽量用从业者之间交流的方式来讲，不堆砌 RFC 原文，而是把实际配置和排错中真正有用的东西讲清楚。

2. TFTP 协议原理：简单到极致的设计哲学

2.1 TFTP 到底跑在什么之上

TFTP 全称 Trivial File Transfer Protocol，直译就是“琐碎的文件传输协议”。它跑在 UDP 之上，默认使用69 端口作为服务端的监听端口。这里有一个很多人第一次接触时会困惑的点：TFTP 的服务端监听 69 端口，但实际的数据传输并不走 69 端口。客户端首先向服务端的 69 端口发送一个请求包，服务端收到后，会从自己的端口池里随机分配一个新的端口来和客户端进行后续的数据交互。这个设计是为了让 69 端口可以继续接收其他客户端的初始请求，避免一个传输把服务端口占死。

这个机制带来的直接后果是：如果你在防火墙或 NAT 环境里做端口映射，只映射 69 端口是不够的。服务端后续使用的随机端口也需要能够被客户端访问到，否则就会出现“请求发出去了，但数据传不过来”的情况。这是 TFTP 排错里最常见的问题之一，后面会详细展开。

2.2 五种报文类型撑起整个协议

TFTP 的报文格式极其精简，总共只有五种操作码（Opcode）：

读文件的过程是这样的：客户端发 RRQ，服务端回 DATA（块号 1），客户端回 ACK（块号 1），服务端再发 DATA（块号 2），如此往复。写文件则是客户端发 WRQ，服务端回 ACK（块号 0），客户端发 DATA（块号 1），服务端回 ACK（块号 1），以此类推。每个 DATA 包默认携带512 字节的数据，如果某个 DATA 包的数据长度小于 512 字节，就表示文件传输结束。这个“小于 512 即结束”的约定是 TFTP 协议里一个很巧妙但也容易出问题的地方。

2.3 停止等待机制与它的代价

TFTP 采用的是停止等待（Stop-and-Wait）机制：每发一个数据块，必须等到对方的 ACK 才能发下一个。这意味着在同一个时刻，网络上只有一个数据包在飞。这种设计的优点是实现简单，不需要滑动窗口、不需要拥塞控制，但代价是传输效率极低。在局域网里，一个 10MB 的文件可能要传好几分钟，因为每个 512 字节的数据块都要经历一次完整的往返确认。

那为什么不用更大的块？TFTP 协议本身允许通过选项协商（Option Extension）来调整块大小，比如协商成 1024 或 1428 字节。tftpd64 支持这个选项，在配置里可以设置。但块大小也不是越大越好，因为 UDP 包在网络上传输时，如果超过 MTU（通常 1500 字节），就会被分片，分片会显著增加丢包和乱序的概率。所以实际使用中，块大小一般设置在 512 到 1428 之间比较稳妥。

2.4 超时与重传：TFTP 的可靠性保障

TFTP 虽然跑在 UDP 上，但它通过超时重传机制来保证可靠性。发送方发出一个数据包后，会启动一个定时器，如果在规定时间内没有收到对应的 ACK，就重传上一个数据包。tftpd64 默认的超时时间是3 秒，重传次数是5 次。如果 5 次重传都没有收到 ACK，传输就会失败并报错。

这个机制在局域网里通常没问题，但在网络质量较差或者设备响应较慢的场景下，3 秒的超时可能不够用。比如某些老旧的嵌入式设备，CPU 处理一个 TFTP 包可能需要几百毫秒甚至更久，如果再加上网络延迟，3 秒很容易被耗尽。这时候就需要调整超时时间，tftpd64 在设置里可以修改这个参数。

3. tftpd64 服务端配置：从下载到跑通

3.1 获取与安装的注意事项

tftpd64 的官方发布渠道是一个个人维护的网站，直接搜索“tftpd64”就能找到。下载的时候注意选择对应系统架构的版本，32 位和 64 位是分开的。安装过程没什么特别的，一路下一步就行。但有一个细节值得注意：tftpd64 有“安装版”和“便携版”两种，便携版解压即用，不需要写注册表，适合放在 U 盘里随身携带。如果你经常需要在不同机器上临时搭 TFTP 服务，便携版会方便很多。

安装完成后，第一次启动 tftpd64，它会默认打开 TFTP 服务端界面。界面上有几个关键区域需要配置：当前目录、服务端接口、端口、超时与重传参数。下面逐个说明。

3.2 当前目录与权限设置

“当前目录”是 TFTP 服务端的根目录，客户端只能访问这个目录下的文件。tftpd64 默认会使用程序所在目录，但强烈建议你手动指定一个专门的目录，比如D:\tftp_root。这样做的好处是隔离清晰，不会把程序目录里的配置文件误传出去。

这里有一个安全相关的点需要强调：TFTP 协议本身没有任何认证机制，任何能访问到服务端 69 端口的客户端都可以读取或写入当前目录下的文件。所以千万不要把 TFTP 服务端暴露在公网上，也不要把敏感文件放在 TFTP 根目录里。在实际项目中，我通常会把 TFTP 服务端绑定到特定的网卡接口上，只允许内网访问。

tftpd64 的“服务端接口”下拉框里会列出本机所有的网卡 IP 地址。如果你的机器有多张网卡（比如同时连着办公网和调试网），一定要选对接口。选错了接口，客户端就连不上。这个坑我踩过不止一次，明明服务端在跑，客户端就是超时，最后发现是绑到了错误的网卡上。

3.3 端口与超时参数的调整

端口默认是 69，一般不需要改。但如果你的机器上已经有别的 TFTP 服务在跑，或者 69 端口被占用，就需要换一个端口。换端口后，客户端连接时也要指定对应的端口号。

超时和重传参数在“设置”里可以找到。默认超时 3 秒、重传 5 次。如果你面对的是响应较慢的设备，可以把超时调到 5 秒甚至 10 秒。重传次数也可以适当增加，但不要设得太大，否则一个失败的传输会卡很久才报错。我的经验是：局域网环境保持默认即可，跨网段或设备性能较差时，超时调到 5 秒、重传 3 次，是一个比较平衡的配置。

还有一个选项叫“允许写入”，默认是不勾选的。如果你需要客户端向服务端上传文件，必须手动勾选这个选项。很多人配置完发现客户端写不进来，就是忘了勾这个。

3.4 日志窗口的正确用法

tftpd64 下方有一个日志窗口，会实时显示客户端的请求和传输状态。这个窗口在排错时非常有用。每次传输开始，日志里会显示客户端的 IP、请求的文件名、传输方向（读或写）、以及传输结果。如果传输失败，日志里也会有相应的错误提示。

我习惯在调试阶段把日志窗口一直开着，传输成功与否一眼就能看到。如果日志里显示“RRQ”但后面没有“DATA”，说明服务端收到了请求但没能发出数据，可能是文件不存在或者权限问题。如果显示“DATA”但没有“ACK”，说明客户端没有确认，可能是网络不通或者客户端配置有问题。通过日志的节奏，基本能判断问题出在哪一侧。

4. 客户端操作：从命令行到 tftpd64 自带客户端

4.1 Windows 命令行下的 TFTP 客户端

Windows 系统自带一个命令行 TFTP 客户端，在“启用或关闭 Windows 功能”里可以找到“TFTP 客户端”并勾选启用。启用后，在 cmd 或 PowerShell 里就可以直接用tftp命令。

读文件的基本语法是：

tftp -i 192.168.1.100 GET filename.bin

写文件的语法是：

tftp -i 192.168.1.100 PUT localfile.bin

其中-i表示以二进制模式传输。这个参数非常重要，如果不加-i，Windows 的 TFTP 客户端会以 ASCII 模式传输，对于二进制文件（比如固件、内核镜像）来说，ASCII 模式会破坏文件内容。我见过有人传完固件后设备起不来，排查半天才发现是忘了加-i。

Windows 自带的 TFTP 客户端有一个明显的限制：它不支持调整块大小和超时参数，也不支持选项协商。所以如果你需要更精细的控制，就得用 tftpd64 自带的客户端，或者用第三方工具。

4.2 tftpd64 自带客户端的用法

tftpd64 套件里包含一个 TFTP 客户端模块，在界面上方可以切换。客户端的配置比命令行直观得多：填上服务端 IP、端口、要传输的文件名，选择“获取”或“上传”，点“开始”就行。

tftpd64 客户端支持块大小协商，在设置里可以指定。如果你在传输大文件时觉得速度太慢，可以尝试把块大小从 512 调到 1024 或 1428。但要注意，服务端也必须支持这个选项协商，否则会回退到默认的 512。tftpd64 服务端是支持块大小协商的，所以两端都用 tftpd64 时，可以放心调整。

4.3 嵌入式设备上的 TFTP 客户端

在嵌入式 Linux 环境里，通常用 BusyBox 提供的tftp命令。BusyBox 的 tftp 用法和 Windows 的略有不同：

tftp -g -r filename.bin -l /tmp/filename.bin 192.168.1.100

其中-g表示获取（get），-r是远程文件名，-l是本地保存路径。上传则用-p表示 put。

在 U-Boot 等 Bootloader 环境下，TFTP 命令的用法又不一样：

tftp 0x80000000 uImage

这条命令会把服务端上的uImage文件下载到内存地址0x80000000。Bootloader 里的 TFTP 客户端通常非常精简，不支持选项协商，块大小固定 512 字节，超时时间也往往比较短。所以在给 Bootloader 传文件时，网络环境要尽量干净，避免丢包。

5. 实战排错：那些年我们踩过的 TFTP 坑

5.1 超时问题排查速查表

TFTP 传输失败最典型的表现就是超时。下面这张表整理了常见的超时原因和排查方法：

5.2 防火墙与端口映射的坑

前面提到过，TFTP 的数据传输不走 69 端口，而是服务端随机分配的新端口。这个机制在防火墙环境下会带来麻烦。如果你在服务端和客户端之间有一道防火墙，只放行 69 端口是不够的，还需要放行服务端用于数据传输的随机端口范围。

在 Windows 防火墙里，最简单的做法是给 tftpd64 程序本身放行，而不是只放行端口。这样无论它用哪个端口，防火墙都会允许。具体操作是：在“允许应用通过 Windows 防火墙”里添加 tftpd64 的可执行文件，并勾选“专用”和“公用”两个网络类型。

如果是在跨网段的环境里，中间有路由器做 NAT，那就需要在路由器上做端口映射。但 TFTP 的随机端口让映射变得很麻烦，因为你不知道服务端会用哪个端口。一种变通方案是在 tftpd64 的设置里指定一个固定的数据传输端口范围，然后在路由器上映射这个范围。不过 tftpd64 对固定端口范围的支持有限，更稳妥的做法是把 TFTP 服务端和客户端放在同一个网段里。

5.3 文件传输成功但设备无法启动

这是一个非常隐蔽的坑。文件传过去了，校验也通过了，但设备就是起不来。可能的原因有几个：

第一，传输模式不对。前面说过，ASCII 模式会破坏二进制文件。Windows 命令行客户端必须加-i，tftpd64 客户端默认就是二进制模式，一般不会有这个问题。

第二，文件本身有问题。比如从网上下载的固件不完整，或者版本不对。传输前最好核对一下文件的 MD5 或 SHA256 校验值。

第三，目标地址不对。在 Bootloader 里用 TFTP 下载文件时，需要指定内存地址。如果地址写错了，文件虽然下载成功，但设备从错误的内存地址启动，自然起不来。这个需要参考具体设备的文档来确定正确的加载地址。

5.4 大文件传输中断的处理

TFTP 传大文件时，中途中断是很常见的情况。由于 TFTP 没有断点续传功能，一旦中断就只能从头再来。为了减少这种情况的影响，可以采取几个措施：

把块大小调大。块大小从 512 调到 1428，传输同样大小的文件需要的包数量减少到原来的三分之一左右，中断的概率也会相应降低。

增加超时时间和重传次数。在网络不稳定的环境下，给每次重传留出更多时间，可以避免因为偶发丢包导致的传输失败。

尽量用有线连接。无线网络的丢包率通常比有线高，传大文件时更容易出问题。如果条件允许，服务端和客户端都用网线连接。

5.5 服务端日志显示乱码或异常

有时候 tftpd64 的日志窗口会出现乱码，或者显示一些看不懂的字符。这通常是因为客户端发送的请求包格式不规范，或者网络上有其他程序在向 69 端口发送数据。TFTP 协议本身很简单，但网络上总有一些扫描程序或者误配置的设备会向 69 端口发包，tftpd64 收到这些非标准包后，日志里就会出现异常内容。

这种情况一般不影响正常传输，但如果日志刷得太快，可以点击“清除”按钮清空日志。如果异常包特别多，说明你的机器可能暴露在了不安全的网络环境中，建议检查一下网络隔离措施。

6. 进阶技巧与替代方案

6.1 用脚本自动化 TFTP 传输

在批量给多台设备刷固件时，手动操作 tftpd64 界面效率太低。可以用批处理脚本调用 Windows 命令行 TFTP 客户端来实现自动化。比如：

@echo off set SERVER=192.168.1.100 set FILE=firmware_v2.3.bin tftp -i %SERVER% GET %FILE% if %errorlevel%==0 ( echo 传输成功 ) else ( echo 传输失败，错误码：%errorlevel% )

这个脚本可以进一步扩展，比如循环读取一个 IP 列表，依次给每台设备传输文件。但要注意，TFTP 本身没有认证，自动化脚本里不要把服务端地址写死成公网地址。

6.2 TFTP 与其他传输协议的对比

从表里可以看出，TFTP 的优势在于轻量和简单，劣势在于没有认证、没有断点续传、效率低。所以在选择传输协议时，如果目标设备支持 FTP 或 HTTP，优先用那些协议。只有在设备资源极其受限、只支持 TFTP 的情况下，才用 TFTP。

6.3 tftpd64 的其他模块简介

tftpd64 套件里除了 TFTP 服务端和客户端，还有 DHCP、DNS、SNTP 等模块。这些模块在特定场景下也很有用。比如 DHCP 模块可以给没有配置 IP 的嵌入式设备自动分配地址，配合 TFTP 实现“上电即传”的自动化流程。DNS 模块可以在没有 DNS 服务器的内网环境里提供域名解析。SNTP 模块可以给设备提供时间同步服务。

不过这些模块的功能都比较基础，如果项目里有更复杂的需求，还是建议用专业的服务端软件。tftpd64 的定位就是一个轻量级的工具集，适合调试和小规模部署。

7. 个人实操体会

我在实际项目里用 tftpd64 最多的场景是给嵌入式开发板传内核和设备树文件。刚开始用的时候，经常遇到传输超时的问题，后来发现大部分情况都是防火墙没放行或者服务端绑错了网卡。这两个问题看起来很简单，但在实际排查时，如果不知道 TFTP 的数据传输不走 69 端口这个机制，很容易在错误的方向上浪费时间。

另外一个体会是：TFTP 的日志窗口一定要善用。很多人遇到问题就急着去改配置，其实先看一眼日志，往往就能定位到问题。日志里显示客户端 IP 和请求文件名，如果这些信息都对，但传输就是失败，那问题多半在网络层面；如果日志里连请求都没收到，那问题就在客户端或者网络连通性上。

最后分享一个小技巧：如果你经常需要在多台机器之间传文件，可以做一个便携版的 tftpd64 放在 U 盘里，里面预置好常用的固件和配置文件。到了现场直接插上 U 盘，启动 tftpd64，设置好当前目录，就能开始传输。这个做法在出差调试时特别省事，不用每次都重新下载和配置。