要約

  • RFC 872は、短く高速で誤りの少ないLANならTCPは本質的に不向きだ、という1982年の恐れを検討した。判断の出発点はアプリケーションが必要とするサービスだった。
  • PadlipskyはUDPやLANの機能を直接使う道も認めた。一方、広域ネットワーク用のTCP/IPと並行して別の局所用プロトコル群を維持する費用を数えた。

隣の机までのケーブルにTCPを載せる。長旅用のトランクを持って廊下を歩くように見えた人がいた。Michael A. Padlipskyは1982年9月のRFC 872で、トランクの中身を確かめた。「LAN上のTCP」への恐れは、人が同じ話を繰り返すうちに大きくなっていた。彼はそれを、追いかけた足跡が自分のものだったという物語の怪物に重ねた。壁の中には本物のケーブルがある。怪物のほうは、役割を一つずつ調べると輪郭が変わる。

まずLANを定義する。Padlipskyが扱うのは短距離で高速、誤りの少ない通信網であり、異なる種類のホストが相互に情報を交換して資源を共有できる。媒体も接続の形も一つには限らない。大事なのはコンピューター同士の通信だ。複数の端末から別々のホストに入れるだけで、ホスト間には通信手順がない構成なら、彼の議論では別の種類の網となる。線を通るビットの速さだけで、アプリケーションの要求は決まらない。

TCPの役割は、必要なプログラムに信頼できる論理的な接続を提供し、流量を制御して順序どおりに届けることだった。相手が同じ建物にいても、ファイルは途中を飛ばして届けば困る。LANの誤り率が低いことは助けになる。それでもアプリケーションが期待する受け取り方を、近所という地理だけで変えることはできない。部屋が隣になったから書類のページ順を無視してよい、とは誰も考えない。

次にIPが登場する。PadlipskyはTCPとIPを塊として扱わなかった。IPは宛先が近くの網にいるかを判断し、遠くならゲートウェイへ渡す。異なる網のパケット長にも対処し、受信側でどの上位プロトコルへ届けるかを示す。IPを分けて設計したため、TCP以外のホスト間プロトコルもその働きを使える。同じホストがLAN内の相手と外の相手の両方に話すなら、速いLANは長い経路の最初の一区間となる。

選択肢はあった。RFCは、音声を小さな単位で送るような用途では、TCPの信頼性より素早さを優先してUDPを選ぶ例を挙げる。特定のLANだけで完結する仕事なら、その機能をより直接使う設計もできる。Padlipskyが気にしたのは、外部との通信にはTCP/IPを残したまま、局所通信用に別の一式を作る場合の負担だった。同じ機械で二組のコードを直し、試し、使い分ける必要がある。想像上の重荷を避けるために、保守担当者へ現実の荷物を二個渡すことになる。

性能については測ればよい。誤りが少ない線路では、TCPのチェックサムは余計な仕事に見える。Padlipskyは当時の研究環境で複数のホスト実装を測った結果を報告し、その計算が一回の送信処理全体の一部を占めると述べた。数字は1982年の実装に属する。判断には、ディスクからデータを読む時間、OSの処理、アプリケーションの仕事、代替方式の費用を一緒に見る必要がある。LANの速度計が威勢のよい数字を示しても、ホストの作業が遅ければ送る中身が間に合わない。

文書は既に動いていたTCP/IPの実装と応用プロトコルを挙げ、そのうえでLAN上の性能を慎重に測るよう求めた。局所的な代替案は、具体的な仕事で同等のサービスを比べ、利点を確かめて選べる。比較には運用と保守も入る。回線だけを眺めると、性能の制限がホスト側にあることを見落としやすい。

RFC 872は1982年の論争を残している。プログラムは信頼性と順序を要するか。同じ機械はLANの外へも通信するか。遅さはどこで測定されたか。怪物に名前をつけるより、この三つを調べるほうがネットワークはよく動く。