要約

  • RFC 2348の試作実験では、2.25 MBのファイルを、途中にゲートウェイがない経路で転送する時間が、ブロック512オクテット時の23.85秒から、8,192オクテット時の4.90秒になった。
  • ブロックは16倍の大きさになったが、時間の短縮は約80%。RFC自身が、経路MTUを超えるとIPのフラグメント化と再構成が余分な負荷になると記している。

従来のTFTPは、単純さを保つ代わりに一件ずつ確認を待つ。クライアントはデータブロックを受け取ると確認応答を返し、次のブロックを待った。512オクテットという基本の大きさは、小さなROMから起動するディスクレス機器のような実装には扱いやすい。一方、より大きなフレームを運べるLANでは、各確認までの待ち時間やパケットごとの処理が相対的に目立つ。

1998年5月のRFC 2348は、この仕組みをなくすのではなく、blksizeを交渉できるようにした。オプションの交渉方法はRFC 2347にある。クライアントが読出し／書込み要求にオプションを付け、サーバーはOACKで応答できる。ブロックサイズについてサーバーが受け入れられるのは要求値以下であり、クライアントが提示していない選択肢をサーバーから始めることはできない。クライアントは確認された値を使うか、転送を終える。古いサーバーがオプションを無視しても、通常のTFTPを続けられる。全端末に一斉の変更を求めない拡張だった。

指定できるのは1ブロック当たり8〜65,464オクテットのデータで、TFTPの4オクテットヘッダーは含まない。RFCには、EthernetのMTUからTFTP、UDP、IPヘッダー分を差し引く例として1,428オクテットが出てくる。これは計算例であって、あらゆる経路の推奨値ではない。TFTPの両端が同じ値を合意しても、途中のリンク、トンネル、各ゲートウェイでフラグメント化せず運べる保証にはならない。

RFCは試作機の測定条件も公開した。HP-UX 9000を2台、負荷の軽いEthernet、octetモード、2.25 MBのファイルを使い、各条件で5回の転送時間を平均した。中間ゲートウェイなし／ありの順で、512オクテット時は23.85秒／37.05秒、8,192オクテット時は4.90秒／6.15秒だった。所要時間の比では約4.87倍／6.02倍、時間の減少率では約79.5%／83.4%となる。

比較表の「16x」は、8,192が512の16倍というブロックサイズの比だ。転送が16倍速くなったという意味ではない。およそ80%という時間短縮は、掲載された平均値と整合する。ブロックサイズ、パケット数、経過時間は別々の尺度であり、ひとつの速度倍率にまとめてはならない。それでも得られた改善は大きい。データブロックが大きいほどパケットと確認応答が減り、待つ回数やパケット単位の処理負荷も下がる。

同じ文書には限界も書かれている。ブロックが経路MTUを超えると、IPのフラグメント化と再構成が負荷を増やし、ゲートウェイが多いほど影響は目立つ。試験用Ethernetで効率のよい値が、細いリンクや追加のカプセル化の先でも適切とは限らない。さまざまなインターネット経路を試したわけでも、ばらつきや普遍的な最適サイズを示したわけでもない。条件の明記された試作結果であり、導入状況の調査ではなかった。

後のRFC 7440は、確認応答を待つ前に複数ブロックを送るwindowsizeを定義した。ブロックの大きさとウィンドウの深さは、停等の待ちを変える別々の調整軸である。さらに後年のRFC 8900は、IPフラグメントの運用上の脆さを論じた。これは1998年の試験が失敗した証拠ではない。元のRFCが示した注意点だけで十分だ。交渉値が決まっても、経路全体に適合したとは限らない。

RFC 2348の歴史的な教訓は「大きいほど速い」ではない。小さなプロトコルにネットワークに応じた転送単位を選ばせ、明記した条件で利得を測り、MTUがその利得を損なう境界も示した。万能な数値ではなく、実際に使う経路を測る出発点だった。

基礎となるTFTP仕様はRFC 1350、同時期のタイムアウトと転送サイズのオプションはRFC 2349に記されている。ブロックサイズと他の交渉項目を区別するための資料だ。