要約

  • RFC 1025は、接続を開く、データを往復させる、正常に閉じる、再初期化せずに繰り返す、ゲートウェイ越しに別の実装と通信する、という観察可能な段階に互換性を分けた。
  • 採点表は試験の整理には役立ったが、合格点を普遍的な正しさや性能順位、実運用の証明に変えるものではなかった。

「正しさ」はまだ議論の対象だった

1987年9月、Jon Postelは、TCPとIPのソフトウェアや仕様がまだ発展途上だった時期の試験方法を、率直な短い文書にまとめた。RFC 1025によれば、実装がごく少なかったころ、ある実装が「正しい」かを知る現実的な方法は、別の実装と接続して、結果が何を示したのか議論することだった。試験の結果、実装が変わることもあれば、議論を通じて仕様が変わることもあった。

この一節を読むと、初期のベイクオフが現代の認証試験とは違う場所にあったことが分かる。完成済みの規則に照らして、封じ込められた製品を評価したわけではない。少数の実装者が共有する、作りかけのプロトコルが対象だった。文章として確定するより先に、異なる機械での振る舞いを見える形にしなければならなかった。通信に失敗しても、それだけで結論が出るわけではない。実装が規則を取り違えたのか、規則が足りなかったのか、試験の問い方が適切でなかったのかを見極める必要があった。

RFC 1025は、すべての集まりを逐一記録した議事録ではなく、後年の回顧である。初期の試験一覧は1978年10月のIEN 69に現れた。1978年12月4日にはRestonで4つのTCP実装がデモを行い、翌1979年1月27～28日にはUSCの情報科学研究所に6つの実装が集まった。1980年4月にはネットワーク経由の分散ベイクオフもあった。1987年のRFCは、この1980年の手順、試験、採点をほぼそのまま再掲している。完成したプロトコルに一度だけ課された公式試験ではなく、実装を持ち寄る機会を重ねながら試験文化が形づくられたことが、この時間軸から見える。RFC 1025、IEN 69、IEN 77

通信は一つの出来事ではない

最初の区分は、驚くほど基本的なところから始まる。自分自身に接続を開けば1点、データを送受信すればもう1点、クラッシュせずに接続を閉じればさらに1点。TCPを再初期化せず、同じ一連の動作を繰り返せれば2点。試験用ゲートウェイを通した完全な通信には5点が付いた。

「接続できた」という一言では潰れてしまう違いを、これらの段階は分けていた。接続開始は両端が状態を作れた証拠、データ交換はその状態が役に立つ証拠、正常終了は関係をどう閉じるかの証拠だ。再初期化なしの繰り返しは、初回のあとも実装が使えるかを問う。ゲートウェイを加えると、中継点とネットワーク境界が一つ増える。最初の握手だけでは、どれも分からない。

中級区分では、自分自身への試験から実装間の相互運用へ進む。別のTCPとの接続開始、データ交換、正常終了は各2点。再初期化せずに繰り返すと4点、試験用ゲートウェイ経由で一連の通信を完了すると10点だった。RFC 1025は、こうした試験が接続先となるTCPごとに適用されると説明し、他の各実装から最大20点を得る例を挙げている。目指したのはNの二乗にあたる接続性、つまり選んだ一組だけでなく、実装どうしの組み合わせの網を確かめることだった。

ここでは証拠の単位が変わる。結果は、ある二つの実装、ある経路、ある条件に結びつく。AとBが話せても、BがCと正しく話せるとは限らず、パケットの届け方を変えるゲートウェイ越しにAが動き続けるとも限らない。一度のデモなら隠れてしまう接続ごとの差を、試験の組み合わせが表に出した。

ゲートウェイで経路をわざと不安定にする

RFC 1025で印象に残る仕掛けが「flakeway」だ。稼働中に調整できる、わざと不安定にしたゲートウェイで、データグラムを落とす割合、壊してから転送する割合、到着順を入れ替える割合を変えられる。名前は軽妙でも、目的は明確だった。経路そのものを試験条件に加えるのだ。きれいな経路でだけ成立する接続より、パケットが消えたり、変化したり、順不同で届いたりしても通信を続けるほうが、確かめた範囲は広い。

チェックサムの条件は、見せかけの成功を防ぐ。チェックサム検査は有効にしておかなければならず、無効なら点は付かない。破損を見つけるための仕組みを止めて、試験を通ったことにはできなかった。

重量級のTCP試験は、通常の会話を越えていく。複数の相手と同時に接続する、緊急データを扱う、シーケンス番号の周回を越える、ヘッダー機能をいくつも同時に使う「Kamikaze」セグメントを処理するといった能力が採点された。仕様に合うセグメントによる「合法な攻撃」と、要件に反する「不正な攻撃」も区別された。仕様に従うセグメントで相手をクラッシュさせれば30点、規則に反するセグメントで倒せば20点という配点だった。競技のような表現は、敵対的な通信で実装の弱点を露わにする試験だったからだ。無効なセグメントが通常運用の一部になったわけでも、一度のクラッシュが普遍的な危険を証明したわけでもない。

ホストとゲートウェイを対象にしたIPの区分も別に設けられた。フラグメントの分割と再構成、ソースルート、リターンルート、ルーティング助言、Source Quench、サービス指定、各種オプションが対象だった。TTLを減らさないゲートウェイ、TTLがゼロのデータグラムを転送するゲートウェイ、チェックサムを正しく扱えないゲートウェイを見つける試験にも点が付く。TCPはホスト間の会話を担当し、IPは相互接続されたネットワークとゲートウェイを越えてデータグラムを運ぶ。その役割の違いが区分にも表れている。RFC 793、RFC 791

試験一覧はさらに、接続の生涯と端のケースを追っていく。何度も開閉する、複数を同時に開いてデータの混線を調べる、ローカルTCPをクラッシュさせた後に同じ接続を再度試す、拒否されるsocketを開く、ゼロウィンドウの受信側へ送信する、「Fire Hose」のようにデータを押し込む、緊急データを試す、シーケンス番号の周回をまたぐ。最後には、接続半開のままシーケンス番号が周回する直前に問題のあるセグメントを送り込む組み合わせもある。ネットワークは整った条件だけで動くわけではない。別々に見える規則がぶつかる場所をこそ調べる必要があった。

合計点が示せる範囲

採点表には、最長の通信、最多の同時接続、さらには「最良の言い訳」に対する賞もあった。こうした要素はベイクオフを印象深くする一方、総得点を単一の順位と見ることを難しくする。基本的な接続の生涯を測る点もあれば、機能の有無やゲートウェイ処理、同時に多くの会話を維持する能力を数える点もある。ひとつの性質を測る目盛りではない。

RFC 1025は最後の節で、その境界を認めている。ここまでの試験は基本動作と難しいケースを確かめるが、性能は考慮せず、近年登場した仕組みが実装されたかも調べない。John Nagleの手順、Van Jacobsonのスロースタートと往復時間測定、SQuIDの手順を別の検討対象として挙げている。性能試験の例としては、FTPまたはNETBLTでEthernetやARPANET上の近隣マシンへ1メガバイトを転送すること、TCP経由でEcho Serverに一文字を送り、往復時間を測ることが示された。そして、その結果は試験環境に大きく左右されると注意を促す。RFC 896、RFC 862

ここは読み違えてはならない。特定の相手との接続を開き、使い、閉じられたという点数は、別の経路や負荷での速度を示さない。試験対象外の仕組みを使う場合の結果も示さない。二つのシステム間で通信できても、全ホストが同じソフトウェアを使うこと、すべての環境で配備済みであること、あらゆる境界条件を試し尽くしたことの証明にはならない。何が分かり、何が分からないかを、RFC自身が記していた。

試験もプロトコルが動く現場の一部だった

初期インターネットの実装文化は、仕様と運用を完全に切り離すのを待たなかった。ベイクオフは、見解の違いを繰り返し観察できる場を作った。こちらは接続を開けるのに、あちらは開けない。この組み合わせは再起動後も通信できる。ゲートウェイがヘッダーを誤って扱う。破損したパケットを検出できる、またはできない。こうした観察はコードの修正にも、文章の明確化にも、書かれた規則の変更にもつながり得た。

採点方法の目新しさより、このフィードバックの輪のほうが歴史的には重要だ。合計点だけでネットワークが正しくなるわけではない。独立して作られた実装の具体的な振る舞いを、担当者どうしが議論できるようにしたのだ。共有規則は別々のシステムが使えると分かって初めて意味を持つ。試験も、結果がどこまでを示すのか技術者が議論できるほど限界を見定めてこそ役に立つ。

後年のRFCは、その実践の断面を残した。互換性は複数の会話がつくる網として、回復は異なる段階の連なりとして、障害対応は両端だけでなく経路を含めて試すものとして描かれている。性能や新しいTCP機能のすべてを測るわけではないという断り書きも、採点表の効力を限定する。RFC 1025は勝利宣言でも、現代の適合証明でもない。若いインターネットが「動く」という主張を、他の実装が問い直せる形にしようとした記録である。

参考資料