要約

  • 1984年のエンドツーエンド論は、ネットワーク内の機能を一律に排除する原則ではなく、完全な正しさを判断できる知識がどこにあるかを問う機能配置の基準だった。
  • 下位層の検査や再送は障害を安く減らせるが、慎重なファイル転送のような処理を完了と認定できるのは、最終成果物を比較できる実際の端点だけである。

受領通知を分解する

フレームが受理された。パケットが宛先ホストに着いた。バイト列がトランスポート層で確認された。書き込み要求が正常終了した。保存したファイルを読み戻し、送信元と同じ内容だと確かめた。日常会話では、これらをすべて「届いた」と呼びがちだが、それぞれの通知が見ている対象も時点も違う。

Jerome H. Saltzer、David P. Reed、David D. Clarkによる1984年の論文は、この違いを慎重なファイル転送で示した。送信側がファイルの値を計算し、受信側が保存後に読み戻して再計算する。両端の結果が一致して、初めてアプリケーションが求めた操作全体を検査できる。途中の通信機構がすべて正常でも、この最終比較を省略する理由にはならない。

なぜなら、故障は各機構の視野の外側に生じ得るからだ。送信元で読み取った後、インターフェースへ渡す前、ゲートウェイのバッファ、受信側メモリー、ディスクへの書き込み、あるいは読み戻しの過程で値が変わるかもしれない。リンク検査の後にゲートウェイ内で一組のバイトが入れ替われば、そのリンクの検査は正直に成功を報告しながら、最終ファイルは誤ったものになる。

ここで問われるのは機構の品質だけではない。ある機構が何を知り得るかである。ネットワーク装置はフレームやパケットの局所状態を詳しく知っていても、利用者が保存したかったファイルの意味までは知らない。完全な判定に必要な情報を持たない場所では、失敗の確率を下げることはできても、処理全体の正しさを保証し切れない。

配置を決めるための論証

エンドツーエンド論は、しばしば「賢い端、単純な網」という標語に置き換えられる。しかし原論文の価値は、網を単純化せよという美学よりも、機能を置く場所を選ぶ手順にある。ある機能がアプリケーション端点の知識なしには完全かつ正確に実現できないなら、その機能を下位層だけに置いても不十分である。端点での実装は結局必要になる。

その判断には四つの問いが役立つ。アプリケーションが約束する最終結果は何か。各層はどの状態を観察できるか。観察範囲の外にどんな故障が残るか。途中の実装は、性能や費用の面で重複に値するか。最後の問いがあるため、この論証はネットワーク内の機能を禁じてはいない。

下位層で頻発するエラーを素早く直せるなら、長い経路を端から再実行する回数を減らせる。リンクごとの検査、局所再送、トランスポート層の確認は、遅延や帯域利用を大きく改善し得る。それらは重要な仕事である。ただし役割は、最終判定を奪うことではなく、端点が最終判定に到達するまでの失敗と費用を減らすことだ。

誤りが二つの検査の間に潜むとき

慎重なファイル転送の反例が今も鮮明なのは、どの検査も嘘をつく必要がないからだ。送信側の検査は、その時点のファイルを正しく読んだ。リンク検査は、受け取ったフレームが送ったフレームと一致すると確認した。受信側のプロトコルも、渡されたバイト列を欠落なく受け取った。それでも、検査後に起きた破損は次の検査まで見つからない。

信頼性を一つの割合で表すと、この境界が見えにくくなる。実際には、各保証には主語と目的語がある。「誰が」「何について」「どの瞬間まで」保証したのか。Clarkらの議論は、成功という単語をこの三つに分解する。局所保証を強くすることと、保証の射程を広げることは同じではない。

エンドポイントという言葉も、単に二台のコンピューターを意味しない。処理によっては、ディスクから読み戻すプロセス、トランザクションを確定するデータベース、暗号学的完全性を検証する要素、利用者に結果を提示するサービスが実際の終点になる。分析はIPアドレスで止めず、約束した結果を判断できる場所まで続けなければならない。

Clarkが後に広げた境界

Clarkの後年の仕事は、1984年の結論を固定的な禁止事項として扱っていない。DARPA Internetの設計思想を振り返った論文では、生存性、複数種のサービス、分散管理といった目標の順位が具体的な設計をどう形づくったかを検討した。さらに将来のインターネットを再考した研究では、信頼、制御、説明責任、競合する利害関係者という問題が前面に出る。

アクティブネットワークをめぐる応答も重要である。ネットワーク内部が利用者指定の処理を実行する構想は、単純な「機能は端にだけ置く」という読み方を揺さぶった。Saltzerの後年のコメントは、エンドツーエンド論が透明性を絶対視する命令ではないことを明確にする。機能に必要な情報がどこにあり、途中で実装する利益が複雑性や信頼上の費用に見合うかを評価する論証なのである。

現在のプロキシ、CDN、セキュリティ検査、非同期キュー、プログラマブルな中間装置は、接続を終端したり、内容を変えたり、別の主体に代わって応答したりする。その存在自体が原則違反なのではない。危ういのは、途中の応答が最終結果の証明であるかのように扱われ、責任の所在が消えることだ。

成功経路を証拠の地図にする

実務では、一回の操作を複数の証拠に分けて描くとよい。各段階について、状態を作った主体、観察できる主体、成功通知が覆う範囲、その後に残る変化を記録する。そうすれば、200応答、キュー投入、レプリカ到着、ストレージ書き込み、利用者が読める最終状態が、互いに代替できないことが分かる。

この地図は、冗長な検査を減らす道具でもある。すべてを端点へ追いやるのではなく、よく起きる局所障害は低い層で安く処理し、意味を必要とする最終検査はその意味を持つ場所に残す。重複がどの故障を減らし、どの故障には届かないかが説明できれば、性能と正しさを同じ言葉で争わずに済む。

出典