要約

  • RFC 2398 は十二のTCPテスト道具を、目的だけでなく構造、 自動化、入手方法、実行環境まで含めて記録した。
  • 障害注入、実スタック測定、キャプチャー、オフライン解析、グラフ化は別々の証拠を作る。曲線やスループット値だけでは、正しさ、安全性、サービス完了を証明できない。

1998年のTCPテストに万能計器はなかった。複数転送をまとめてログにする道具、稼働中のスタックへキューや帯域や遅延を入れる道具、Linux機を「選択的に悪い」ルーターへ変える道具があった。別の道具はパケットを作り、障害を注入し、トレースを読み、時間—シーケンス図を描いた。RFC 2398 は十二の異なる観測経路を同じ目録に置いた。

目録の書式が重要だった。各項目にはカテゴリー、仕組み、必要な人手、自動化、入手先、実行環境、参考文献が求められた。道具の名前だけで方法を語らせないためである。どのトラフィックを作り、どの実装を試し、解析に何を仮定したかがなければ、同じグラフでも意味は変わる。

分類は機能的正しさ、性能、ストレスの三つだった。高速な実装が必ず仕様に忠実とは限らない。簡単な接続で正しくても、高負荷で崩れることがある。ストレス結果が弱点を示しても、原因が実装、測定経路、テストハーネスのどこにあるかを自動では説明しない。

Dummynet、NIST Net、Orchestraは連鎖の前側で条件を変えた。帯域を絞り、キューを作り、パケットを遅延、破棄、複製、並べ替え、変更できた。Orchestraはスクリプトでメッセージまで新しく挿入できたが、最終的には利用者が生成されたトレースを見て正否を判断した。条件の生成と結論の生成は別の作業だった。

Tcpanalyはキャプチャーから始めた。多くの実装について組み込まれた知識とtcpdumpトレースを比べ、なぜ各パケットがその時点で送られたかを説明し、測定誤差らしいものと実装の逸脱を分けようとした。RFC自身、固定テストより挙動のプロファイルに近いため分類が難しいと認めた。Tcptraceは再送、RTT、ウィンドウ、スループットを計算し、TracelookとXplotはそれを見える形にした。可視化は観察を助けるが、表示された事象を作ったわけではない。

Netperf、TReno、Ttcpは数値の出所を問い直す。TRenoはUDPやICMPを、SACKと輻輳制御を守るTCPに似たタイミングで送り、端末のTCP実装から独立して経路性能を測ろうとした。それは別の問いに役立つ設計であり、あらゆるTCP判断に対する上位の答えではない。

RFCは自らの限界も明記した。TCP Implementer’s working groupを通じて作者へ報告された道具の一覧で、網羅的ではない。作者が確認したのは出版時の入手可能性であり、永続的な保守、現在の互換性、普遍的な適合性ではなかった。

セキュリティ節はさらに明快だった。道具によっては不正パケットやサービス妨害条件を作れ、外部から得たカーネルコードやroot権限を必要とした。キャプチャーは他人のメールやファイルも読める。それでも一覧の道具はどれもセキュリティを評価しない、とRFCは明記した。ネットワークを壊せる能力と、安全性を判定する能力は同じではない。

したがってグラフはテストそのものではない。道具、環境、与えた条件、実装版、トラフィック、キャプチャー、計算、表示、人の解釈という長い保管連鎖の末端である。連鎖を残せば結果は実験が知り得た範囲を正確に語れる。失えば、滑らかな線は魅力的な逸話になる。

情報源