摘要

  • RFC 2348 的原型测试中，传输 2.25 MB 文件、且路径上没有中间网关时，块长从 512 字节增至 8,192 字节，耗时从 23.85 秒降到 4.90 秒。
  • 数据块确实扩大了 16 倍，测得耗时却只减少约 80%。RFC 同时警告，块长超过路径 MTU 后，IP 分片和重组会带来额外开销。

早期 TFTP 把简单性放在首位：客户端收到一个数据块，回送确认，然后等待下一个。512 字节的默认块长适合资源有限的设备——例如从小型 ROM 启动的无盘机器——但每个块都要经历一次确认等待。在允许更大帧的局域网上，这些等待和逐包处理可能占去不少时间。

1998 年 5 月发布的 RFC 2348 并未取消这种交互，而是加入可协商的 blksize 选项。一般的选项协商方式由 RFC 2347 规定：客户端把选项放进读或写请求，服务器可以用 OACK 回答。对于块长，服务器接受的值不得高于客户端所提的数值；服务器不能主动提出客户端没请求的选项。客户端随后必须采用 OACK 中确认的值，或终止传输。如果旧服务器忽略这些选项，双方仍可按普通 TFTP 继续。这是兼容扩展，不是对所有端点强制更新。

新选项允许每块携带 8 至 65,464 字节数据，不包括 TFTP 的 4 字节头部。RFC 以 1,428 字节举例，说明如何从以太网 MTU 中扣除 TFTP、UDP 和 IP 头部；那是一个计算示例，不是适用于所有路径的固定值。两个 TFTP 端点谈妥块长，并不能证明途中每条链路、隧道和网关都能在不分片的情况下承载相应 IP 数据报。

RFC 把原型测试条件写得很具体：两台 HP-UX 9000 主机、轻载以太网、octet 模式、2.25 MB 文件，每种条件平均五次传输。作者分别测试了没有中间网关和经过一个中间网关的路径。512 字节块长下，两种路径耗时分别为 23.85 秒和 37.05 秒；8,192 字节时则为 4.90 秒和 6.15 秒。按耗时倒数计算，改善约为 4.87 倍和 6.02 倍；耗时分别下降约 79.5% 和 83.4%。

因此，RFC 比较表里的“16x”指的是块长比：8,192 除以 512。它不是“传输快了 16 倍”。约 80% 的耗时降幅与表中的五次平均值一致。块长比例、数据包数量和墙钟时间是不同指标，不能写成一个速度数字。结果仍然显著：块更大，数据包与确认包更少，等待次数减少，每个数据包的封装和处理开销也随之降低。

边界同样写在 RFC 中：如果块长超过路径 MTU，IP 分片和重组会增加开销；经过的网关越多，这项代价就越明显。测试以太网上合适的块长，遇到较小链路或额外封装后可能不再合适。实验没有覆盖多种互联网路径，没有给出统计离散度，也没有找出通用的最优块长。它证明的是一个原型在所述条件下的结果，而不是部署普查。

后来的 RFC 7440 引入另一个调节项 windowsize：发送若干连续数据块后再等待确认。窗口深度和每块大小都影响停等开销，但它们不是同一个旋钮。更晚的 RFC 8900 讨论了 IP 分片在实际运行中的脆弱性；这份后来的文档不能倒推为 1998 年测试失败的证据。原 RFC 已经点明核心限制：协商出一个值，不代表整条路径都适配。

RFC 2348 的历史意义，不是“越大越快”，而是让小协议可以按网络条件调整传输单位，在明确的试验条件下展示收益，并把可能削弱收益的 MTU 边界一并写出。块长不是魔法数字；它只是对实际路径进行测量的起点。

基线协议见 RFC 1350。同期的超时和传输大小选项见 RFC 2349，可帮助区分块长与其他可协商参数。