3. TFTP 传输性能调优：块大小协商、窗口大小调整、超时重传机制、并发连接限制
TFTP 这玩意儿，看着简单，调起来门道不少。很多刚入行的朋友觉得它就是个传文件的小工具，没啥好折腾的。其实不然。我在项目里见过太多因为 TFTP 没配好，导致网络启动卡在 99% 的案例了。说白了，TFTP 的传输效率，直接决定了你的终端设备能不能快速上线。
今天咱们就掰开揉碎，聊聊 TFTP 传输性能调优的四个核心点：块大小、窗口、超时重传、并发连接。嗯，每个点都有坑，咱们一个个填。
3.1 块大小协商：别让默认值坑了你
TFTP 默认的块大小是 512 字节。这个值在 1980 年代挺合理，那时候网络带宽小，丢包率高。但现在呢？千兆网络遍地都是，512 字节的块大小就成了瓶颈。
块大小对传输效率的影响：
- 块越小，ACK 交互次数越多，延迟开销越大
- 块越大，单次传输数据量越大，但丢包后重传代价也高
- 需要根据网络质量动态调整
我记得有一次帮客户排查 PXE 启动慢的问题。他们的网络环境很好，全是千兆交换机，但 TFTP 传输速度只有 1MB/s 左右。查了半天，发现块大小还是 512 字节。改成 1468 字节后，速度直接飙到 20MB/s。你想想看，差了 20 倍。
块大小推荐值：
- 局域网（低延迟、低丢包）：1428 - 1468 字节（避免 IP 分片）
- 广域网（高延迟）：512 - 1024 字节
- 无线网络（高丢包）：256 - 512 字节
块大小协商的过程其实挺有意思。客户端在 RRQ（读请求）或 WRQ（写请求）中，可以通过 option extension 字段携带 blksize 选项。服务器如果支持，就会在 OACK 中确认。如果不支持，就按 512 字节走。
# tftp 客户端设置块大小示例
tftp> mode octet
tftp> blksize 1468
tftp> get firmware.bin小技巧：块大小不要超过网络路径的 MTU 减去 UDP 和 IP 头部开销。以太网 MTU 通常是 1500 字节，减去 20 字节 IP 头、8 字节 UDP 头，有效载荷最大 1472 字节。我习惯留点余量，设 1468 字节。
3.2 窗口大小调整：从停等协议到流水线
标准 TFTP 用的是停等协议——发一个块，等一个 ACK，再发下一个。这效率太低了。尤其是高延迟链路，大部分时间都在等 ACK。
后来有了 TFTP 窗口扩展（Windowsize Option），允许一次发送多个数据块，然后统一收 ACK。这就像从单车道变成了多车道并行。
窗口大小对性能的影响：
| 窗口大小 | 适用场景 | 优势 | 风险 |
|---|---|---|---|
| 1（默认） | 高丢包、不稳定网络 | 重传代价低 | 吞吐量极低 |
| 4 - 8 | 普通局域网 | 吞吐量提升 4-8 倍 | 丢包时重传较多 |
| 16 - 32 | 低延迟、低丢包数据中心 | 接近带宽极限 | 单包丢失影响大 |
我个人习惯在局域网环境中把窗口大小设为 8。这个值比较平衡，既不会因为窗口太大导致重传风暴，又能充分利用带宽。我曾经在一个项目中试过窗口大小设为 32，结果网络稍微有点抖动，整个传输就卡住了。嗯，后来老老实实改回 8。
# 设置窗口大小为 8
tftp> windowsize 8
tftp> get large_firmware.bin注意：窗口大小和块大小是联动的。窗口大小 × 块大小 = 飞行中的数据量。如果这个值超过接收端缓冲区，就会导致丢包。我曾经遇到过客户端缓冲区只有 64KB，窗口大小设了 16，块大小 1468，飞行数据 23KB 没问题。但如果块大小改成 8192，飞行数据就变成 128KB，直接撑爆缓冲区。
3.3 超时重传机制：别让重传变成雪崩
TFTP 的超时重传机制，说白了就是发一个包，等 ACK，等不到就重发。但怎么等、等多久、重发几次，这里面学问大了。
超时时间设置：
- 默认超时：5 秒（太长了，局域网内 100ms 都嫌多）
- 局域网推荐：1 - 2 秒
- 广域网推荐：3 - 5 秒
- 卫星链路：10 秒以上
为什么超时时间这么重要？我举个例子。有一次客户反馈，他们的网络启动偶尔会失败，而且总是在传输大文件时出问题。我抓包一看，发现超时时间设的是 5 秒，但网络偶尔有 3 秒的延迟抖动。客户端等 5 秒没收到 ACK，重传。但重传的包和延迟到达的原始包混在一起，导致接收端乱序，最终传输失败。
重传策略：
- 指数退避：第一次超时 1 秒，第二次 2 秒，第三次 4 秒... 避免网络拥堵时雪上加霜
- 最大重试次数：通常 3-5 次，超过就放弃
- 快速重传：收到重复 ACK 时立即重传，不等超时
我的经验值：
- 初始超时：1 秒
- 最大超时：8 秒
- 重试次数：4 次
- 启用指数退避
这套参数在大多数网络环境下表现稳定。如果网络特别差，可以适当增加重试次数，但不要超过 8 次，否则客户端会卡死很久。
3.4 并发连接限制：别让服务器被撑爆
TFTP 服务器默认是单线程的，一个连接一个连接地处理。如果同时有几十台设备启动，后面的设备就得排队等着。这在大规模部署时是个大问题。
并发连接数的影响：
| 并发连接数 | 服务器负载 | 客户端等待时间 | 适用场景 |
|---|---|---|---|
| 1（默认） | 极低 | 线性增长 | 单设备调试 |
| 10 - 20 | 中等 | 几秒到几十秒 | 小型办公室 |
| 50 - 100 | 较高 | 秒级 | 大型机房 |
| 200+ | 极高 | 毫秒级 | 数据中心批量部署 |
我曾经在一个数据中心项目中，需要同时部署 200 台服务器。默认的 TFTP 服务器只能处理 10 个并发连接，结果后面 190 台设备都在等，部署时间从预期的 30 分钟变成了 3 小时。后来换了支持高并发的 TFTP 服务器（比如 tftpd-hpa），把并发数调到 100，问题就解决了。
调优建议：
- 使用多线程或事件驱动型 TFTP 服务器
- 设置合理的最大并发数，避免服务器内存耗尽
- 配合负载均衡，多台 TFTP 服务器分担压力
- 监控服务器 CPU、内存、网络连接数，及时调整
3.5 综合调优：四个参数的协同
这四个参数不是孤立的。它们之间相互影响，需要一起调。我画了一张图，帮你理清它们的关系。
调优的顺序也很重要。我一般先调块大小和窗口大小，这两个决定了理论最大吞吐。然后根据实际网络质量调超时重传，避免丢包导致性能下降。最后才是并发连接数，这个受服务器硬件限制比较大。
避坑指南：我曾经在一个项目中，先调了并发连接数到 200，结果服务器 CPU 直接飙到 100%，所有连接都超时了。后来才发现，块大小和窗口大小没调，单连接吞吐太低，服务器把大量资源花在了上下文切换上。先调基础参数，再调并发，这个顺序不能乱。
3.6 实战案例：从 2MB/s 到 50MB/s
最后分享一个真实案例。某公司需要批量部署 500 台瘦客户机，每台需要传输 200MB 的系统镜像。默认配置下，单台传输速度只有 2MB/s，500 台全部部署完需要 14 个小时。
调优步骤：
- 确认网络环境：千兆局域网，延迟 <1ms，丢包率 <0.01%
- 块大小从 512 改为 1468 字节
- 窗口大小从 1 改为 8
- 超时时间从 5 秒改为 1 秒，重试次数 3 次
- 并发连接数从 10 改为 50
调优后，单台传输速度达到 50MB/s，50 台并发部署，总吞吐 2.5GB/s。500 台设备分 10 批部署，每批 50 台，总耗时从 14 小时缩短到 40 分钟。嗯，客户当场就竖了大拇指。
调优前后对比：
| 指标 | 调优前 | 调优后 | 提升 |
|---|---|---|---|
| 单台传输速度 | 2 MB/s | 50 MB/s | 25 倍 |
| 并发连接数 | 10 | 50 | 5 倍 |
| 500 台部署时间 | 14 小时 | 40 分钟 | 21 倍 |
TFTP 调优，说白了就是找到网络环境和服务器能力的平衡点。没有一套参数能通吃所有场景，但掌握了块大小、窗口大小、超时重传、并发连接这四个维度的调优方法，你就能应对绝大多数情况了。