要約

  • 初期のTFTP仕様は、古い重複データグラムを受け取った双方に現在のデータグラムを再送させ得たため、一つの遅延ACKから残りの全DATAとACKが二重化する循環が生まれた。
  • RFC 1123は、DATA送信側が重複ACKだけを理由に現在のDATAを再送することを禁じた。Karen Sollins著のRFC 1350は修正版を継承し、1992年5月の修正をNoel Chiappaの仕事として明記した。

障害は、ACKが消えたときではなく、遅すぎて戻ってきたときに始まる。送信側AがDATA Xを送り、受信側BがACK Xを返す。そのACKがネットワーク内で滞留する。Aはタイムアウトし、DATA Xを再送する。Bは重複を認識して、もう一度ACK Xを返す。

先に送られたACK XがAへ届くと、Aは正しく次のDATA X+1へ進む。そこへ二つ目のACK Xが到着する。旧ルールでは、古い重複ACKを受けたAが「現在の」データグラムを再送できた。現在のデータグラムは既にX+1なので、X+1が二つになる。Bも二つのACK X+1を返し、片方がX+2へ進め、もう片方がX+2を複製する。この拍子は、都合よくパケットが失われない限り続く。

RFC 1123は、これを深刻な仕様上の欠陥とした。ただし、転送が完了すればファイル自体は正しくなるとも説明している。ここに運用上の落とし穴がある。結果の整合性だけでは、途中で生じた増幅を観測できない。重複通信はタイムアウトを招き得るうえ、最初の遅延が輻輳によるものなら、その原因へさらに負荷を足す。

「魔法使いの弟子」という呼び名が示すのは、一度の誤操作よりも止め方の欠如である。双方は相手を助けるつもりで同じ応答を繰り返す。ところが、過去の状態に対する応答が現在の送信を発生させるため、慎重さそのものが連鎖の燃料になる。

修正は、再送を一律に減らすことではなかった

RFC 1123が要求したのは、DATAを生成する側が、重複ACKを受けただけで現在のDATAを再送してはならないという条件である。送信側の再送タイマーは残る。期待するACKが来ないまま時間が過ぎれば、未確認のDATAを再試行できる。失われるのは、古いACKが今のブロックを動かす権限だけだ。

受信側は、重複DATAへACKを再送してよい。最初のACKが本当に失われた場合、その応答には意味がある。しかし送信側が既に進んでいれば、古いACKは何も起こさない。この非対称性によって、情報の反復と仕事の再生成が切り離された。

同じ節でRFC 1123は、適応型タイムアウトと最低限の指数バックオフも必須としている。これらは早すぎる再送を抑え、問題のある経路にかける圧力を下げる。ただし、状態遷移の欠陥そのものを直すわけではない。良いタイマーは循環の発生確率を下げるが、古い入力を無害にするのは状態の判定である。

この違いは、現代の分散処理でも重要だ。一方の処理が冪等でも、その応答が相手側で非冪等な処理を起動すれば、系全体は安全ではない。「同じ要求を二度処理できるか」だけでなく、「同じ返答を二度受けた相手が何をするか」を試す必要がある。

小ささは、用途から導かれた設計だった

RFC 1350はTFTPを、ごく単純なファイル転送プロトコルと説明する。ファイルの読み書きはできるが、ディレクトリ一覧を取得できず、基本仕様にユーザー認証もない。「Trivial」は、仕事が重要でないという意味ではなく、実装面を狭く保つという選択だった。

RFC 1123によれば、基本のTFTPは実効ウィンドウが512オクテットの一セグメントだけのstop-and-wait方式である。RFC 906が想定した代表的用途は、ネットワーク経由のブートだった。ROMやEPROMに収まる小さなクライアントで最初のコードを取得し、その後をより高機能なソフトウェアへ渡す。高帯域を使い切ることより、限られた環境で確実に次段階へ届くことが優先された。

その小さなコードは長く残りやすい。ファームウェアへ埋め込まれた実装は、一般のアプリより所在が分かりにくく、交換も難しい。曖昧な一文が複数ベンダーに実装され、互換性の名で世代をまたぐこともある。単純なプロトコルほど、各入力がどの状態を変えてよいかを厳密に残す必要がある。

後のRFCはオプション交渉、ブロックサイズ、タイムアウトなどを追加した。RFC 2347はOACKを独立したパケットとして定め、未対応オプションを黙って別解釈せず、応答から外すようにした。拡張経路でも、交渉が拒否されて基本経路へ戻る場合でも、重複ACKの不変条件は同じでなければならない。

セキュリティ面の境界も明確だ。RFC 1350はユーザー認証がないことを記し、RFC 1123は許可するパス名の制限と、ブロードキャスト宛て要求の無視を推奨している。閉じたブート用セグメントに適する最小機構が、そのまま一般公開のファイルサービスに適するわけではない。

Sollinsの署名は、共同作業の履歴を消していない

Sollinsは1981年のRFC 783と1992年のRFC 1350の著者である。一方、RFC 1350はTFTPの元設計をNoel Chiappaに帰し、Chiappa、Bob Baldwin、Dave Clarkが再設計し、Steve Szymanskiがコメントしたと記録する。さらに多数の提案者を挙げ、1992年5月に「魔法使いの弟子」欠陥と文書上の問題を直した改訂をChiappaが行ったと明記している。

したがって、Sollinsが一人でTFTPを発明し、一人で欠陥を直したという人物像は成立しない。彼女の役割は、意図的に小さなプロトコルの境界と理由を文書に保ち、実装経験から得た訂正を取り込み、共同設計を相互運用可能な標準として存続させたことにある。Robert Bradenが編集したRFC 1123は、別の形で一連のパケットを可視化し、修正をホスト要件にした。

MIT CSAILの公開略歴は、Sollinsの関心をネットワーク上のシステム、分散名前管理、認証、グローバルな命名、極めて長寿命の情報基盤、巨大規模の問題へ広げている。Swarthmoreで数学を学び、MITで計算機科学の修士号と博士号を取得し、1999年から2000年には米National Science Foundationでネットワーク研究の上級プログラムディレクターを務めた。

これらの研究とTFTPの小さな修正に共通するのは、時間がずれたときに意味をどう守るかという問いである。遅延ACKは偽物ではない。ただし、それが語っているのは過去のブロックであり、現在のブロックへの命令ではない。

出典と役割を残すことは、将来の保守にも効く。新しいブート環境へ書き直す開発者は、重複ACKを無視する分岐を「不要な古い処理」と見るかもしれない。失敗の連鎖が併記されていれば、その一行は儀式ではなく、再発を防ぐ因果関係として読める。

正しいファイルだけを合否判定にしない

実装試験では、ACK Xを送信側のタイムアウト後まで遅らせ、DATA Xの再送後に二つのACKを届ける。送信側がX+1へ進んだ後、古い二つ目のACKでDATA X+1が再送されてはならない。真の損失、順序入れ替え、DATA側の重複、ブロック番号の境界、オプションの成立と拒否も別々に重ねる。

確認する値は、完成ファイルのハッシュだけではない。各ブロックのパケット数、所要時間、タイマーの変化、状態遷移を保存する。ソースを監査できない機器では、正確なファームウェア版と結び付いたパケットキャプチャが重要な証拠になる。

現在どの機器がTFTPを使うかは製品ごとに確認すべきである。工場、通常の設定配布、ネットワークブート、緊急復旧では露出も代替可能性も異なる。Sollinsらの文書が残した問いは、そのまま検査項目になる。過去から戻ったメッセージは過去の情報として処理されるのか。それとも現在にもう一度仕事を作らせるのか。

出典