要約

  • クライアントはRRQまたはWRQを既知のTID 69へ送るが、受理したサーバーは別に選んだTIDから応答し、二つの値が残りの転送のUDPポートになる。
  • 異なる送信元TIDはエラー5で排除して正しい転送を継続し、重複再送の修正や後年のオプションもこの一時的な境界を維持した。

終了にも猶予が必要だった

基本TFTPは512オクテットのDATAを一つ送り、対応するACKを待って次へ進む。短いDATAが終端であり、長さが512の整数倍なら空のDATAが最後を告げる。受信側は最終ACKの後に少し待つことを勧められた。同じ最終DATAが戻れば、相手がACKを受け取れなかったと分かり、もう一度返せる。

この「dally」は小さいが重要である。送った側の完了と受け取った側の完了は同じ瞬間ではない。TFTPは一つの未決ブロックだけを覚える代わりに、TID、ブロック番号、タイマーを組み合わせて、何が新しく、何が重複し、何が別の転送かを判断した。

69は受付番号だった

クライアントは自分のTIDを選び、読み出し要求または書き込み要求をサーバーの既知TID 69へ送る。読み出しなら、受理の証拠はサーバーが選んだTIDから来るDATA 1である。書き込みなら同じくACK 0である。その後はクライアントとサーバーの二つのTIDがUDPの送信元・宛先ポートとして使われる。

したがって69は、新しい依頼を見つける場所であって、ファイル全体の送信元ではない。受付は新しい要求を受け続け、個々の転送は別の端点で分離できる。69だけを許可した装置は入口を開けたまま、成立した会話を閉ざしてしまう。

TIDは短期の所属情報にすぎない。ランダムな選択は直前の転送との衝突を減らすが、暗号学的に相手を認証せず、ファイルの正しさや権限を証明しない。

二つ目の返事は別の会話だった

最初の要求がネットワーク内で複製されると、サーバーが別々のTIDから二つ応答する場合がある。クライアントは最初に受け入れた応答で端点を固定する。後から来た別TIDのパケットを混ぜず、破棄してエラー5「Unknown transfer ID」を返す。

それでも受け入れ済みの転送は止めない。RFC 1350が送信元ポート不一致を、接続を終了させない例外的なエラーとした理由である。ほかのERRORは多くの場合に終了を意味し、ACKも再送もされない。エラー5は正しい会話の失敗ではなく、その外から来たパケットへの境界通知である。

古いACKがDATAを二倍にした

RFC 783の初期規則には、古い重複データグラムを受けた側が現在のデータグラムを再送できるという問題があった。遅延したパケットとタイムアウトが重なると、DATAの重複がACKの重複を呼び、そのACKがまたDATAを呼ぶ。以後の各組が二重になる。

RFC 1123はこれを「魔法使いの弟子症候群」と呼んだ。ファイルの並びが壊れなくても、回復動作が輻輳を増やし、さらに遅延とタイムアウトを生んで転送を失敗させる。

修正は、重複ACKから再送の権限を取り上げた。DATAの送信側は、それだけを理由に現在のDATAを再送してはならない。適切なタイムアウトや状態だけが回復を開始する。RFC 1350はRFC 783を置き換え、この欠陥を修正した。

小さな状態には明確な権限が要る

停止してACKを待つ方式では、送信側は現在の一ブロックだけを保持すればよく、受信側は並べ替えを必要としない。だが帯域と遅延が大きくなると、一ブロックの窓は利用率を抑える。

RFC 2347のオプション交渉は、性能を上げながら提案者を明確にした。オプションを要求できるのはクライアントだけである。サーバーは要求されたものだけをOACKに含め、未対応のものは省略できる。読み出しではACK 0、書き込みではDATA 1がOACK受諾になる。認められなかった選択肢は存在しなかったものとして扱う。

RFC 2348はブロックサイズ、RFC 2349はタイムアウトと総サイズを扱った。RFC 7440は複数の連続DATAを一つの窓として送り、最後のブロックへのACKまで待てるようにした。窓が一なら元の停止待ちである。

これらは未確認の作業量を増やしたが、二つのTIDを消してはいない。処理量を増やすほど、どの値に合意したか、どのブロックまで確定したかを残す必要が大きくなる。

正しい転送と正しいファイルは別だった

TFTPには利用者認証がない。端点と番号が完全に一致しても、読めるべきでないファイルを配ることも、書かせるべきでない場所を上書きすることもできる。起動イメージの出所や署名もTIDからは分からない。

運用側は、到達可能なネットワーク、公開するルート、読み書き権限、成果物の来歴、動的なファイアウォール状態、最初の要求と選ばれたTIDを結ぶログを別に管理しなければならない。動的ポートへの対応としてUDP全体を開けば、転送を区別するための境界そのものを失う。

TFTPの歴史が残したのは、簡素さを無条件に賛美する話ではない。公開された受付と一時的な会話を分け、重複信号の権限を制限し、性能拡張にも明示的な合意を要求した例である。状態を少なくするほど、残った状態の意味を曖昧にできない。

出典と限界

初期仕様は RFC 783、ホスト要件と重複修正は RFC 1123、改訂仕様は RFC 1350 にある。オプションは RFC 2347、RFC 2348、RFC 2349、RFC 7440 が定め、IANA登録表が69を記録する。現在の普及率を示す資料ではなく、TIDを認証、許可、暗号化、内容検証に変えるものでもない。