※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
> 前提=情報系統 五部 ネットワーク 第1巻(BOOK-0070) / この後=分散システム・大規模設計
---
# BOOK-0119 ネットワーク 第2巻 — 信頼性と規模の設計（情報派生 第2巻）
> 前提=情報系統 五部 ネットワーク 第1巻(BOOK-0070) / この後=分散システム・大規模設計
---
## 第一章: 第1巻の地図 — パケット・階層・IP/TCPの要約と本巻の見取り図
前巻(BOOK-0070)では、「遠くの相手に記号を届ける」という通信の願いが、どのような発想の積み重ねで実現されてきたかを歴史からたどった。要点だけを簡潔に振り返っておこう。**回線交換**(通話ごとに専用の回線を独占する古い電話方式)の無駄を解消するために**パケット交換**(データを小さな単位=パケットに分割し、共有された道を流す方式)という発想が1960年代に生まれ、**ARPANET**(1969年)によって実際に動く網として実証された。異なる通信網どうしをつなぐ共通言語として**TCP/IP**が1974年に提案され、1983年にARPANETが正式に移行した。通信という複雑な仕事を役割ごとに積み木のように分ける**階層モデル**の考え方も確認した。**IP(Internet Protocol、水準二の再確認)**が宛先の管理と配送を担当し、**TCP(Transmission Control Protocol、水準二の再確認)**が正確な組み立て直しを担当するという役割分担、**IPアドレス**という通信網内の住所、**DNS**という名前から住所を引く電話帳の仕組みも見た。
この第2巻(BOOK-0119)では、その土台の上に立って、次の問いを掘り下げる。**「パケットが失われたり順番が入れ替わったりする不確実な世界で、どうやって正確な通信を実現するのか」「みんなが同じ道を使うとき、混雑をどう管理すれば全体が速く保てるのか」「無数の中継点の中から、どうやって最適な道を選ぶのか」「なりすましや盗聴を防ぎ、どうやって相手を信頼するのか」「世界規模に広がった通信網を、どう分散させて支えるのか」**。前巻が通信網の「骨格」を描いたとすれば、この巻はその骨格の上に「信頼性」と「規模」という二つの筋肉を付けていく作業にあたる。
見取り図として、本巻の流れを一言でまとめておく。第二章では**TCPがどうやって信頼性を作り出すか**(再送・順序制御・フロー制御)を見る。第三章ではその信頼性の裏側にある**混雑の管理**(輻輳制御)を見る。第四章では**道を選ぶ仕組み**(ルーティング)を、第五章では**名前を引く仕組み**の内部(DNSの階層構造)を、第六章では**信頼の土台**(暗号とTLS)を、第七章では**規模と分散**(CAP定理・負荷分散・CDN)を扱う。最後の第八章でこの巻全体を振り返り、次に待つ分散システムの世界への橋渡しをする。
---
## 第二章: 信頼性の設計 — TCPの再送・順序制御・フロー制御
### なぜ「信頼性」が必要なのか
前巻で見たように、パケット交換の世界では、送り出したパケットは共有された道を個別に流れていく。ここで一つ、都合の悪いことが起こりうる。**パケットは届く保証がない**のである。途中の中継点が混雑していれば、あふれたパケットは捨てられてしまうことがある。複数の経路を通ったパケットは、送った順番とは違う順番で届いてしまうこともある。IP自体は「宛先を見て、できるだけ届ける」という**ベストエフォート(最善努力、水準五: 到達を保証はしないが、できる範囲で最善を尽くして配送する通信の性質)**の仕組みであり、届いたかどうかの確認や、抜け落ちた分の再送までは面倒を見ない。
この「届く保証がない」土台の上に、「確実に、しかも正しい順番で届く」という体験を作り出す役目を担っているのが、前巻でも触れたTCPである。この章では、TCPが具体的にどんな仕組みでこの信頼性を実現しているのかを見ていく。
### 三ウェイハンドシェイク — 会話を始める前の挨拶
TCPによる通信は、いきなりデータを送りつけるところから始まるわけではない。まず、通信を始める二者(多くの場合、サービスを求める**クライアント**と、サービスを提供する**サーバー**)が、お互いに「これから通信を始める準備ができているか」を確認し合う手順を踏む。この手順を**三ウェイハンドシェイク(さんウェイハンドシェイク、水準五: TCP通信を開始する前に、SYN・SYN-ACK・ACKという3回のやり取りによって、双方が通信の準備が整っていることを確認し合う手順)**と呼ぶ。
具体的な流れは次のようになる。まずクライアントが「通信を始めたい」という意思を示す**SYN(シン、synchronizeの略、水準五: 接続の開始を要求する信号)**というパケットをサーバーに送る。次にサーバーが「その要求を受け取った、こちらも通信の準備ができている」ことを示す**SYN-ACK(シン・アック、水準五: SYNへの応答と、サーバー自身の接続開始要求を同時に示す信号)**というパケットを返す。最後にクライアントが「了解した、これから通信を始める」ことを示す**ACK(アック、acknowledgeの略、水準五: 受け取ったことを相手に伝える確認信号)**というパケットを送り返す。この3回のやり取り(SYN → SYN-ACK → ACK)が完了して初めて、実際のデータのやり取りが始まる。
なぜこんな手間をかけるのか。手紙の比喩で考えてみよう。前巻でパケット交換を「便箋を小分けにして送る」ことにたとえたが、TCPの三ウェイハンドシェイクは、いきなり本題の便箋を送りつける前に、「これから手紙のやり取りを始めますが、よろしいですか」「はい、こちらも準備できています」「では始めます」という短い挨拶を交わすことに近い。この挨拶によって、双方が「相手が確かに存在し、通信を受け付ける状態にある」ことを事前に確認できる。もし挨拶なしにいきなり大量のデータを送りつけてしまうと、相手が準備できていない場合や、そもそも存在しない宛先だった場合に、無駄な送信が発生してしまう。三ウェイハンドシェイクは、この無駄を防ぐための、通信開始時の小さいが重要な儀式なのである。
### 再送 — 届かなかった便箋をもう一度送る
三ウェイハンドシェイクによって通信が始まった後も、個々のパケットが届く保証がないという事情は変わらない。そこでTCPは、送ったパケットが確かに届いたかどうかを、受信側からの**確認応答(ACK)**によって把握する仕組みを持っている。送信側は、送ったパケットに対応するACKが一定時間内に返ってこなければ、「そのパケットは失われた」と判断し、同じパケットをもう一度送り直す。この仕組みを**再送(さいそう、水準五: 送ったパケットの到達が確認できない場合に、同じデータをもう一度送り直す仕組み)**と呼ぶ。
これも手紙の比喩でつかんでおこう。前巻では「便箋に『何枚中の何枚目か』を書き込む」という話をしたが、ここに「受け取ったら返事のはがきを出す」というルールを加える。送り主は、出した便箋それぞれについて、受け取ったという返事のはがきが一定期間内に届かなければ、「あの便箋は届かなかったのだろう」と判断し、同じ便箋を書き直してもう一度送る。この「返事がなければもう一度送る」という単純な繰り返しのルールが、届く保証のない共有の道の上に、「最終的には必ず届く」という信頼性を作り出している。
### 順序制御 — バラバラに届いた便箋を並べ直す
パケット交換の世界では、パケットが送った順番通りに届くとは限らない。複数の経路を通ったパケットが、途中の混雑具合によっては、後から送ったパケットが先に届いてしまうことすらある。この問題に対処するのが**順序制御(じゅんじょせいぎょ、水準五: 送信側がパケットに順番の番号を付け、受信側がその番号をもとに、バラバラに届いたパケットを元の正しい順番に並べ直す仕組み)**である。
これはまさに前巻の郵便の比喩そのものである。「何枚中の何枚目か」という番号を各便箋に書いておけば、届いた順番がバラバラでも、受け取った側は番号を見て正しい順番に並べ直すことができる。TCPでは、この番号を**シーケンス番号(順序番号)**と呼ぶ形で管理しており、受信側はこの番号を頼りに、届いたデータを送信側が意図した通りの正しい順序で組み立て直す。
### フロー制御 — 受け手の処理速度に合わせて送る量を加減する
再送と順序制御によって「正確に、正しい順番で届く」ことは実現できるが、もう一つ考えるべき問題がある。それは**送り手と受け手の処理速度の違い**である。もし送信側が受信側の処理能力を無視して大量のデータを一方的に送り続けたら、受信側の受け皿(バッファと呼ばれる、届いたデータを一時的に蓄えておく領域)があふれてしまい、せっかく届いたデータを取りこぼしてしまう。
この問題を防ぐのが**フロー制御(ふろーせいぎょ、水準五: 受信側が自分の受け入れ能力〈受け皿の空き容量〉を送信側に伝え、送信側がその範囲内に送る量を抑える仕組み)**である。TCPでは、受信側が「今、これだけの量ならまだ受け取れる」という空き容量の情報を、**ウィンドウ(窓、水準五: 受信側が一度に受け取れるデータの量を示す、フロー制御の基準となる値)**という形で送信側に伝える。送信側はこのウィンドウの大きさを超えない範囲でデータを送り、受信側の受け皿があふれることを防ぐ。
もう一度、手紙の比喩を借りよう。受け取る側の郵便受けの大きさには限りがある。もし送り主が郵便受けの容量を無視して便箋を送り続けたら、郵便受けからあふれた便箋は失われてしまう。フロー制御とは、受け取る側が「うちの郵便受けには、今これくらいの余裕がありますよ」と送り主にあらかじめ伝え、送り主がその余裕の範囲内でだけ便箋を送るようにする、受け手主導の調整の仕組みなのである。このウィンドウという考え方は、次の第三章で見る「混雑の管理」とも深く関わってくる。
再送・順序制御・フロー制御という三つの仕組みが組み合わさることで、TCPは「届く保証のない共有の道」の上に、「確実に、正しい順番で、受け手が処理しきれる速さで届く」という信頼性を作り出している。これが、この章の中心にある発想である。
---
## 第三章: 混雑をさばく — 輻輳制御とAIMD
### 輻輳とは何か
前章のフロー制御は、あくまで「受け手の処理能力」に合わせて送る量を調整する仕組みだった。しかし通信網には、受け手の事情とは別に、もう一つ考えなければならない混雑の原因がある。それは**通信網そのものの混雑**である。多数の送信者が同じ共有の道(回線や中継点)を同時に使おうとすると、道の容量を超えるパケットが押し寄せ、中継点で処理しきれずにパケットが捨てられてしまう。この、通信網内部で起きる混雑の状態を**輻輳(ふくそう、水準五: 通信網内の道や中継点の処理能力を超えるパケットが集中し、遅延の増大やパケットの喪失が起きている状態)**と呼ぶ。
輻輳は、フロー制御だけでは防げない。なぜなら、フロー制御はあくまで「送信側と受信側、二者間の処理能力の釣り合い」を見ているだけであり、その二者の間に横たわる道の途中に、他の無数の送信者たちが同時に押し寄せてくる状況までは考慮していないからである。道路の比喩で言えば、フロー制御が「受け取る側の駐車場の空き台数」を見ているのに対し、輻輳制御が見ているのは「その駐車場に至るまでの道路そのものの渋滞状況」にあたる。この二つは似ているようで、対象にしている問題がまったく違う。
### スロースタート — 恐る恐る速度を上げる
輻輳という問題に対処するためにTCPが採用している仕組みの一つが**輻輳制御(ふくそうせいぎょ、水準五: 通信網内部の混雑状況を推測しながら、送信側が送る量を調整することで、道全体の詰まりを緩和しようとする仕組み)**である。輻輳制御の出発点となる考え方が**スロースタート(slow start、水準五: 通信の開始直後は控えめな量からデータを送り始め、途中でパケットの喪失が起きなければ、送る量を段階的に、しかも急速に増やしていく仕組み)**である。
なぜ「スロー」なのに「急速に増やす」のか、一見矛盾しているように聞こえるかもしれないが、ここには理由がある。通信を始めた直後は、その道の途中にどれくらいの混雑があるのか、送信側にはまったくわからない。いきなり大量のデータを送りつけてしまうと、もし道が混んでいた場合、大量のパケットが一気に失われてしまう。そこでスロースタートでは、まず控えめな量から送り始め、パケットが無事に届いたことが確認できるたびに、送る量を倍々に近い勢いで増やしていく。「様子見から始めて、うまくいっている間はどんどん加速する」という戦略である。ちょうど、初めて訪れる暗い道を歩くとき、最初はゆっくり足元を確かめながら進み、障害物がないとわかった区間からは歩幅を大きくしていくことに近い。
### AIMD — 加算増加・乗算減少という「譲り合い」の設計
スロースタートによって送る量が増えていくと、いずれはどこかで輻輳が発生し、パケットの喪失が検出される段階が来る。ここで登場するのが**AIMD(エーアイエムディー、Additive Increase Multiplicative Decrease、加算増加・乗算減少、水準六: 輻輳が起きていない間は送る量を少しずつ〈加算的に〉増やし、輻輳を検出したら送る量を大きく〈乗算的に〉減らす、という非対称な調整のルール)**という仕組みである。
AIMDの動きを具体的に見てみよう。**加算増加(Additive Increase)**の段階では、パケットが無事に届き続けている限り、送信側は送る量を一定の少しずつの幅で、着実に増やし続ける。順調な間はじわじわとアクセルを踏み込んでいくイメージである。ところが、いったん輻輳(パケットの喪失)を検出すると、**乗算減少(Multiplicative Decrease)**の段階に切り替わる。ここでは送る量を、それまでの量に対してある割合を掛け合わせる形で、一気に大きく減らす。たとえば「送る量を半分にする」といった具合に、増やすときとは比べ物にならない速さで、急ブレーキをかけるように送信量を絞り込む。
このAIMDという「増やすときはゆっくり、減らすときは一気に」という非対称なルールは、なぜそんな形をしているのだろうか。ここに、この章の中心にある、実に面白い設計思想が隠れている。**輻輳とは、自分一人だけの問題ではなく、同じ道を共有している無数の送信者全員が引き起こしている、共同の問題である**という点を思い出してほしい。もし輻輳を検出したときの減らし方が緩やかだったら、混雑が解消されるまでに時間がかかり、その間、道はずっと詰まったままになってしまう。乗算的に一気に減らすことで、混雑の芽が大きくなる前に、すばやく道を空ける方向に動ける。
一方で、増やすときを加算的に緩やかにしているのは、「みんなが同時に、恐る恐る少しずつ量を増やしていく」ことで、特定の一人だけが急に量を増やして道を独占してしまう事態を避けるためである。もし全員が「輻輳が解消されたら、いきなり全力で送り始める」というルールで動いていたら、道が空いた瞬間に全員が一斉に押し寄せ、あっという間にまた輻輳が再発してしまう。加算的にゆっくり増やすというルールのおかげで、道の空き具合を探りながら、全員が少しずつ譲り合うようにして送信量を調整していくことになる。
この「増やすときは慎重に、減らすときは思い切って」という設計が、なぜ**「みんなが譲り合う」ことで全体が速くなる**のか、道路の比喩で最後にもう一度整理しておこう。もし一人のドライバーが「自分だけは絶対に速度を落とさない」という戦略を取ったとしても、他の全員が同じ道を使っている以上、誰か一人が無理をすれば道全体が詰まり、結局は全員が速度を落とさざるを得ない状況に追い込まれる。逆に、全員が「混雑の兆しを感じたら、まず自分から速度を大きく落とす」というルールに従えば、混雑の芽は早い段階で摘み取られ、道全体としての流れる速さ(スループット、単位時間あたりに実際に運べるデータの量)は結果的に高く保たれる。AIMDは、個々の送信者が全体最適を意識して動くわけではなく、単純な「加算で増やし、乗算で減らす」というルールに従って利己的に動いているだけなのに、その積み重ねの結果として、道を共有する全員にとって都合の良い、公平で安定した混雑の緩和が実現される、という点に、この設計の巧妙さがある。これは、次の第七章で見る「規模の設計」全般に通じる、分散した多数の主体が単純なルールに従うだけで全体として秩序が生まれる、という発想の一つの原型でもある。
---
## 第四章: 道を選ぶ — ルーティングのアルゴリズムと自律システム
### 前巻の復習 — 経路の冗長性
前巻の第六章で、ルーティング(経路選択)とは「通信網の中の多数の中継点(ルーター)が、パケットの宛先を見て、次にどの中継点へ転送すればよいかをそのつど判断していく仕組み」であり、同じ宛先までの道が複数存在する「経路の冗長性」こそが通信網の強靭さの秘密である、という話をした。この章では、ルーターが実際に「次にどこへ転送するか」をどうやって決めているのか、その具体的な考え方を掘り下げる。
### 距離ベクトル型 RIP — 隣同士で噂話を伝える
ルーティングの方式の一つに、**距離ベクトル型(きょりベクトルがた、水準五: 各ルーターが、隣接するルーターとの間だけで「どの宛先まで、あと何ステップ〈ホップ〉かかるか」という情報を交換し合い、その情報を積み重ねて経路を決めていく方式)**という考え方がある。この方式を採用した初期の代表的な仕組みが**RIP(リップ、Routing Information Protocol、水準五)**である。
距離ベクトル型の動き方を、噂話が広まる様子にたとえてみよう。あるルーターが「宛先Aまでは、私から2ステップです」という情報を隣のルーターに伝えると、隣のルーターは「では私からは3ステップだな」と自分の情報を更新し、さらにその隣へ伝えていく。この噂話がバケツリレーのように広まることで、遠く離れた宛先までの大まかな距離(ホップ数)の情報が、通信網全体に少しずつ行き渡っていく。RIPの仕組みは単純でわかりやすい反面、遠くの状況の変化が伝わるまでに時間がかかる(噂話が広まるのに時間がかかるのと同じ理屈である)という弱点も持っている。
### リンク状態型 OSPF — 全員が地図そのものを共有する
距離ベクトル型とは異なる発想を採るのが**リンク状態型(リンクじょうたいがた、水準五: 各ルーターが、通信網全体のつながり方〈地図〉そのものの情報を交換し合い、各ルーター自身がその地図全体をもとに最短経路を計算する方式)**という考え方である。この方式を採用した代表的な仕組みが**OSPF(オーエスピーエフ、Open Shortest Path First、水準五)**である。
距離ベクトル型が「隣同士で噂話を伝える」やり方だとすれば、リンク状態型は「全員が同じ地図のコピーを持ち、自分の目でその地図を見て最短経路を判断する」やり方に近い。各ルーターは、自分の隣接関係の情報を通信網全体に広く知らせ(この配布の仕組みをフラッディングと呼ぶことがある)、結果として全てのルーターが、通信網全体の接続関係を表す地図をそれぞれ手元に持つことになる。この地図さえ手元にあれば、あとは各ルーターが自分自身で最短経路を計算すればよい。
### ダイクストラ法再訪 — 最短経路を計算する定番の手順
ここで、リンク状態型のルーターが手元の地図から最短経路を計算するために使う、代表的な計算手順に触れておきたい。それが**ダイクストラ法(ダイクストラほう、水準五: 出発点から、通信網の地図上のすべての地点までの最短距離を、確定済みの地点を少しずつ広げていくことで求める計算手順)**である。
ダイクストラ法の考え方を簡単に整理すると、次のような手順になる。まず出発点からの距離が確定している地点の集合を用意し、最初は出発点そのものだけをこの集合に入れる。次に、まだ確定していない地点の中から、確定済みの集合を経由して到達できる距離が最も小さい地点を選び、その距離を確定させて集合に加える。この「一番近い未確定の地点を確定させ、集合を少しずつ広げていく」という操作を、すべての地点の距離が確定するまで繰り返す。この手順によって、出発点からすべての地点までの最短経路が、最終的にもれなく求まる。OSPFのようなリンク状態型のルーティングでは、各ルーターがこのダイクストラ法(あるいはこれに類する最短経路計算の手順)を、自分の手元にある地図全体に対して実行することで、宛先ごとの最適な次の転送先を導き出している。
### BGP — 自律システムどうしをつなぐ、もう一段上の交渉
RIPやOSPFは、比較的まとまった一つの組織(たとえば一つの企業や大学)が管理する範囲の中でのルーティングを扱う仕組みである。この、一つの管理主体がまとまって運用する通信網の範囲のことを**自律システム(じりつシステム、AS、Autonomous System、水準五: インターネットを構成する、一つの組織が独立して管理・運用する通信網のひとまとまり)**と呼ぶ。インターネット全体は、無数の自律システムが互いに接続し合うことで成り立っている巨大な集合体である。
では、この無数の自律システムどうしを、どうやってつなぎ、どうやって経路を決めているのだろうか。ここで登場するのが**BGP(ビージーピー、Border Gateway Protocol、水準五: 異なる自律システムどうしの間で、どの宛先へどう経路を通すべきかという情報を交換し合う、インターネット全体の骨格を支えるルーティングの仕組み)**である。
BGPの役割は、RIPやOSPFが「一つの組織の中の道の選び方」を扱うのに対し、「組織と組織の間の道の選び方」を扱う、もう一段上の交渉の仕組みだと理解するとよい。自律システムどうしは、BGPを通じて「うちの自律システムを経由すれば、この宛先群に届けられますよ」という情報を隣接する自律システムに伝え合い、この情報の交換がインターネット全体に広がっていくことで、世界中のどの自律システムからでも、目的の宛先まで到達するための経路が組み上がっていく。BGPは単なる技術的な最短経路の計算だけでなく、各組織間の契約や商業的な取り決め(どの相手の通信を優先的に中継するかなど)も経路選択に影響する、技術と組織運営が交差する仕組みでもある。この「技術的な合理性だけでなく、組織間の合意や取り決めも経路に影響する」という点は、RIPやOSPFのような一組織内のルーティングにはない、BGP特有の性質である。
---
## 第五章: 名前を引く — DNSの階層とキャッシュ
### 前巻の復習 — DNSは電話帳である
前巻では、DNSを「人間にとって覚えやすい名前と、機械が使う数字のIPアドレスとを対応づけて調べる仕組み」であり、その働きを「電話帳」にたとえて紹介した。この章では、その電話帳が実際にはどのような構造で運用されているのかを見ていく。
### ルート→TLD→権威サーバという階層構造
DNSは、一冊の巨大な電話帳をどこか一箇所にまとめて置いているわけではない。世界中のあらゆる名前とアドレスの対応を一箇所で管理しようとすれば、その一箇所への問い合わせが集中しすぎて破綻してしまう。そこでDNSは、**階層構造(かいそうこうぞう、水準五: 名前の管理を、頂点から末端へと段階的に分担していく、木の枝のような構造)**を採用している。
この階層の頂点に位置するのが**ルート(root、水準五: DNSの階層構造の最上位に位置する、すべての名前解決の出発点となるサーバー群)**である。ルートは、それ自体が個々のドメイン名の細かい情報を持っているわけではないが、「.com」や「.jp」といった、名前の末尾部分(これを**TLD、トップレベルドメイン**と呼ぶ)ごとの管理をどこに問い合わせればよいかという情報を持っている。次の階層にあたる**TLDサーバ**は、「example.com」のような、そのTLDに属する個々のドメイン名の管理を、さらにどこに問い合わせればよいかという情報を持っている。そして最終的にたどり着くのが**権威サーバ(けんいサーバ、authoritative server、水準五: 特定のドメイン名について、実際のIPアドレスの対応関係を正式に管理し、答えを返す責任を持つサーバー)**であり、ここで初めて「example.comのIPアドレスは何番か」という具体的な答えが得られる。
この階層構造を電話帳の比喩でもう一度整理すると、次のようになる。分厚い一冊の電話帳をいきなり最初のページから最後まで探すのではなく、まず「この地域の電話帳はどの支局が管理しているか」を案内所(ルート)で尋ね、案内された支局(TLDサーバ)でさらに「この会社の電話番号を管理しているのはどの部署か」を尋ね、最後にその部署(権威サーバ)で実際の電話番号を教えてもらう、という段階を踏んだ問い合わせのリレーである。この段階的な分担のおかげで、世界中の膨大な数のドメイン名の管理を、どこか一箇所に集中させることなく、多数のサーバーに分散して支えることができている。
### キャッシュとTTL — 同じ答えを何度も探しに行かない工夫
ルートからTLD、権威サーバへと段階を踏んで名前を調べる作業は、確実である反面、毎回すべての段階を律儀に踏んでいたのでは時間がかかってしまう。そこでDNSには**キャッシュ(cache、水準五: 一度調べた名前とIPアドレスの対応関係を、一定期間だけ手元に保存しておき、次に同じ名前を調べる必要が生じたときに、階層をたどり直さずその保存内容を使い回す仕組み)**という工夫が組み込まれている。
一度「example.comのIPアドレスは何番か」を調べてその答えを得たら、その答えをすぐに忘れてしまうのではなく、しばらくの間は手元に控えておく。次に同じ名前を調べる必要が生じたときは、ルートからたどり直すのではなく、控えておいた答えをそのまま使う。これによって、同じ名前が何度も問い合わせられる場合の負担が大きく軽減される。
ただし、ここで一つ注意が必要になる。IPアドレスの対応関係は、未来永劫変わらないものではない。サービスの引っ越しなどの事情で、ある名前に対応するIPアドレスが変更されることもある。もしキャッシュした答えをいつまでも使い続けてしまうと、変更後の新しい対応関係に気づけないまま、古い答えを使い続けてしまう恐れがある。この問題に対処するのが**TTL(ティーティーエル、Time To Live、水準五: キャッシュに保存した答えを、どれくらいの時間まで有効なものとして使い続けてよいかを示す、寿命の値)**である。それぞれの対応関係にはTTLという寿命が設定されており、この時間を過ぎたキャッシュは無効になったものとして扱われ、次に同じ名前が問い合わせられたときには、あらためて階層をたどって最新の答えを取り直す。TTLは「使い回しの効率」と「情報の鮮度」という、相反する二つの要求のバランスを取るための仕組みだと理解しておくとよい。
---
## 第六章: 信頼の土台 — 公開鍵暗号とTLS、証明書
### なぜ通信網に「信頼」が必要なのか
ここまでの章で見てきた仕組み(TCPの信頼性、輻輳制御、ルーティング、DNS)は、いずれも「正しく、効率よく届ける」ための工夫だった。しかしこれらの仕組みは、途中の道を流れる中身そのものが誰かに盗み見られたり、書き換えられたりすることまでは防いでくれない。共有の道をみんなで使うという発想は、パケット交換の効率の良さの源泉であったのと同時に、「共有の道の途中で、悪意ある第三者がこっそり中身をのぞき見たり、通信相手になりすましたりできてしまうのではないか」という、信頼にまつわる新しい課題も生み出す。この章では、その課題にどう対処しているのかを見ていく。なお本冊子では、暗号の原理と役割にとどめ、具体的な攻撃の手法には立ち入らない。
### 公開鍵暗号 — 鍵を二つに分けるという発想
暗号の伝統的な発想は、「送り手と受け手だけが知っている、同じ一つの秘密の鍵」を使って、内容を読めない形に変換したり(暗号化)、元に戻したり(復号)するというものだった。しかしこの発想には、「その秘密の鍵そのものを、どうやって安全に相手と共有するか」という、鶏と卵のような問題が付きまとう。
この問題に対する画期的な答えとして生まれたのが**公開鍵暗号(こうかいけんあんごう、水準六: 「公開鍵」と「秘密鍵」という、対になった二種類の異なる鍵を用意し、片方の鍵で暗号化した内容は、対になっているもう片方の鍵でしか復号できないという性質を利用する暗号の方式)**である。公開鍵は文字通り誰にでも公開してよい鍵であり、秘密鍵は本人だけがひそかに保管する鍵である。この二つの鍵は数学的に対になっており、公開鍵で暗号化した内容は対応する秘密鍵でしか元に戻せず、逆に秘密鍵で施した処理は対応する公開鍵を使えば誰でも検証できる、という性質を持つ。
この性質が、ネットワークの世界でどう役に立つのか、二つの使い道に整理しておこう。一つは**内容を秘密にする使い道**である。相手の公開鍵で暗号化してから送れば、その内容を元に戻せるのは対応する秘密鍵を持つ本人だけになるため、途中の道で誰かに盗み見られても、内容そのものは読み取られずに済む。もう一つは**本人であることを証明する使い道**である。本人だけが持つ秘密鍵で何らかの処理を施しておけば、対応する公開鍵を使ってその処理を検証できた人は、「これは確かに秘密鍵の持ち主本人が行った処理だ」と確認できる(この仕組みはデジタル署名と呼ばれる)。「鍵を公開してよい鍵と、絶対に公開してはいけない鍵の二つに分ける」という、一見逆説的に思えるこの発想の転換こそが、見知らぬ相手同士が安全に通信を始めるための土台になっている。
### TLSハンドシェイクの直感 — 出会ったその場で安全な合言葉を決める
WWWをはじめとする現代の多くの通信サービスでは、**TLS(ティーエルエス、Transport Layer Security、水準六: 通信の内容を暗号化し、通信相手が正当な相手であることを確認するための、通信の信頼性を支える仕組み)**という仕組みが、通信の安全を支える標準的な土台として使われている。
TLSによる通信も、前章のTCPの三ウェイハンドシェイクと同じように、本題のやり取りを始める前の準備の段階、**TLSハンドシェイク**を踏む。この手順の直感を、大まかにつかんでおこう。まず通信を始める二者は、公開鍵暗号を使って、これから使う暗号化の方式や、通信を守るための一時的な合言葉(共通鍵と呼ばれるものにあたる)を、安全に決め合う。ここで公開鍵暗号が活躍する。二人はまだ一度も直接会ったことがない間柄でも、公開鍵という「誰に見られても構わない情報」だけをやり取りしながら、その場限りの安全な合言葉を、途中でのぞき見されることなく決めることができる。この合言葉が決まった後は、実際のデータのやり取り自体は、その合言葉を使った、より処理の軽い暗号化の方式に切り替えて進められる。「最初だけ手間のかかる公開鍵暗号を使ってその場限りの合言葉を安全に決め、その後は決めた合言葉を使った軽い暗号化に切り替える」という二段構えが、TLSハンドシェイクの直感的な骨格である。
### 証明書と認証局 — なりすましを防ぐ仕組み
公開鍵暗号によって、内容を盗み見られない、本人であることを確認できるという性質は手に入った。しかしここでもう一つ、重要な問題が残っている。それは、**「そもそも、目の前にある公開鍵が、本当に通信したい相手本人のものである」という保証は、どこから来るのか**という問題である。もし悪意ある第三者が、自分の公開鍵を「これは正当なサービスの公開鍵です」と偽って配ることができてしまったら、公開鍵暗号のすべての利点は台無しになってしまう。
この問題に対処するのが**証明書(しょうめいしょ、水準六: ある公開鍵が、確かにその名前を名乗る本人・組織のものであることを、第三者が確認し、保証する電子的な証書)**と、その証明書を発行する**認証局(にんしょうきょく、CA、Certificate Authority、水準六: 証明書を発行し、公開鍵と、その持ち主である本人・組織との対応関係を検証・保証する、信頼された第三者機関)**という仕組みである。
認証局は、ある組織が「これは私の公開鍵です」と申請してきたときに、その組織が本当に名乗っている通りの組織であるかを一定の手続きで検証し、問題がなければ、その組織の名前と公開鍵を結びつけた証明書を発行する。この証明書には認証局自身のデジタル署名(前述の秘密鍵による処理)が付けられており、証明書を受け取った側は、認証局の公開鍵を使ってその署名を検証することで、「この公開鍵は、確かに認証局のお墨付きを得た、名乗っている通りの相手のものだ」と確認できる。電話帳の比喩をもう一度借りるなら、証明書と認証局は、「その電話番号が本当にその会社のものであることを、信頼できる第三者機関があらかじめ確認し、太鼓判を押しておいてくれる」仕組みにあたる。この太鼓判の連鎖があるおかげで、私たちは一度も直接会ったことのない相手のサービスに対しても、「このサービスは確かに名乗っている通りの相手だ」という一定の確信を持って通信を始めることができる。なりすましを防ぐこの信頼の連鎖こそが、見知らぬ相手だらけの巨大な通信網の上で、安心して情報をやり取りするための土台になっている。
---
## 第七章: 規模と分散 — CAP定理、負荷分散、CDN
### 世界規模に広がった通信網が抱える、新しい種類の課題
ここまでの章では、一対一の通信を正確に、安全に届けるための工夫を見てきた。しかし現代の通信網は、単に一対一の通信が正確であればよいという規模をはるかに超えて、世界中の無数の利用者が同時に同じサービスにアクセスするという、まったく新しい種類の課題に直面している。この章では、通信網が「規模」に対応するために採用している考え方を見ていく。
### CAP定理 — 一貫性・可用性・分断耐性、三つは同時に満たせない
世界中に分散して置かれた複数のサーバーが、同じデータを扱いながら協調して動く**分散システム**を設計するとき、避けて通れない理論的な制約がある。それが**CAP定理(キャップていり、水準六: 分散システムにおいて、一貫性・可用性・分断耐性という三つの望ましい性質を、同時にすべて満たすことはできないとする理論)**である。
CAP定理が扱う三つの性質を、一つずつ確認しておこう。**一貫性(Consistency)**とは、どのサーバーに問い合わせても、常に同じ最新のデータが返ってくるという性質である。**可用性(Availability)**とは、システムに問い合わせれば、常に何らかの応答が返ってくるという性質である。**分断耐性(Partition tolerance)**とは、サーバー間をつなぐ通信網の一部が切れてしまっても、システム全体が機能を続けられるという性質である。CAP定理は、この三つのうち**分断耐性は現実の分散システムでは避けられない前提条件であり、残る一貫性と可用性の二つは、分断が起きた際にはどちらか一方しか完全には満たせない**、という趣旨の主張をする理論として整理されている。この理論は**2000年にエリック・ブリュワー(Eric Brewer)が提唱し、2002年にセス・ギルバート(Seth Gilbert)とナンシー・リンチ(Nancy Lynch)が定理として証明した**、という経緯が広く知られている。
なぜ三つとも同時には満たせないのか、直感をつかんでおこう。世界中に分散して置かれた複数のサーバー間の通信網が、何らかの事情で一時的に分断されてしまった(分断耐性が問われる状況)としよう。このとき、分断されたそれぞれのサーバーに問い合わせが来たら、選択肢は二つしかない。一つは、「分断された向こう側のサーバーと同期が取れていないかもしれないが、とにかく手元にあるデータで応答する」という選択であり、これは可用性を優先し一貫性を犠牲にする道である。もう一つは、「向こう側との同期が確認できるまで、応答を保留する」という選択であり、これは一貫性を優先し可用性を犠牲にする道である。分断が起きている間、この二つの選択のどちらかを選ばざるを得ず、両方を完全に満たすことはできない、というのがCAP定理の核心である。分散システムを設計する技術者たちは、CAP定理が示すこの三択を踏まえた上で、自分たちのサービスの性質に応じて、一貫性を重視するか可用性を重視するかという設計判断を下すことになる。
### 負荷分散 — 一人に仕事を集中させない工夫
世界中から同じサービスへ問い合わせが殺到する状況では、そのすべてを一台のサーバーだけで処理しようとすると、そのサーバーが過負荷になって応答できなくなってしまう。この問題への対処として広く使われているのが**負荷分散(ふかぶんさん、ロードバランシング、水準六: 複数台のサーバーを用意し、届いた問い合わせを何らかのルールに従って各サーバーに振り分けることで、特定の一台に処理が集中することを防ぐ仕組み)**である。
負荷分散の考え方は、複数の窓口を用意した受付にたとえるとわかりやすい。もし窓口が一つしかなければ、来訪者の列はどんどん伸びてしまう。窓口を複数用意し、来訪者を各窓口に均等に振り分ける係(負荷分散装置)を置いておけば、来訪者一人あたりの待ち時間を短く保ちながら、全体としてより多くの来訪者をさばくことができる。この仕組みによって、世界中からの膨大な問い合わせを、多数のサーバーで手分けして処理することが可能になる。
### CDN — 近くから配るという発想
負荷分散が「複数のサーバーで仕事を手分けする」という発想だとすれば、もう一つ別の角度からの解決策として広く使われているのが**CDN(シーディーエヌ、Content Delivery Network、水準六: よく使われるデータのコピーを、世界中の利用者の近くに分散して配置しておき、利用者が実際に近くのコピーから受け取れるようにする仕組み)**である。
CDNの発想を理解する鍵は、前巻の第七章で見た**光速の壁**を思い出すことにある。地球の反対側にあるサーバーから直接データを受け取ろうとすれば、光速という物理法則そのものが原因で生じる遅延を避けられない。それならば、そもそも「地球の反対側まで毎回データを取りに行く」必要をなくしてしまえばよい、というのがCDNの発想である。よく使われるデータのコピーを、世界中の主要な都市などに前もって配置しておけば、利用者は地球の反対側の本来のサーバーまで往復する代わりに、自分の近くに置かれたコピーから、ずっと短い距離でデータを受け取ることができる。
これは前巻で確認した郵便網の比喩でも理解しやすい。もし全国どこからの注文にも、たった一つの倉庫からその都度荷物を発送していたら、倉庫から遠い地域ほど届くまでに時間がかかってしまう。あらかじめ人気の商品のコピーを、各地域の近くの小さな倉庫に分散して置いておけば、利用者は最寄りの倉庫からすぐに荷物を受け取れる。CDNは、まさにこの「近くの倉庫から配る」という発想を、世界中のデータ配信に応用したものである。負荷分散が「同じ場所にある複数の窓口で仕事を分ける」仕組みだったのに対し、CDNは「そもそも利用者の近くまで倉庫そのものを分散させる」仕組みであり、両者は「規模に対応する」という同じ目的に向かう、異なる二つのアプローチだと整理しておくとよい。
---
## 第八章: まとめと次への一歩
この巻で歩いた道のりを、前巻からの流れも含めて整理しておこう。
```
[前巻の土台] パケット交換・ARPANET・TCP/IP・階層モデル・IPアドレス・DNS基礎
│
▼
[信頼性の設計] 三ウェイハンドシェイク(SYN/SYN-ACK/ACK)・再送・順序制御・フロー制御(ウィンドウ)
│
▼
[混雑をさばく] 輻輳・スロースタート・AIMD(加算増加・乗算減少)=譲り合いで全体が速くなる設計
│
▼
[道を選ぶ] 距離ベクトル型RIP・リンク状態型OSPF・ダイクストラ法・自律システム間のBGP
│
▼
[名前を引く] ルート→TLD→権威サーバの階層・キャッシュとTTL
│
▼
[信頼の土台] 公開鍵暗号(公開鍵/秘密鍵)・TLSハンドシェイクの直感・証明書と認証局
│
▼
[規模と分散] CAP定理(Brewer 2000提唱/Gilbert&Lynch 2002証明)・負荷分散・CDN(近くから配る)
```
前巻が「記号をどうやって遠くまで届けるか」という通信網の骨格を描いたのに対し、この巻では、その骨格の上に「不確実な世界でどう信頼性を作り出すか」「混雑にどう対処すれば全体が速くなるか」「どうやって最適な道を選ぶか」「どうやって相手を信頼するか」「どうやって世界規模の需要を支えるか」という、五つの筋肉を付けてきた。TCPの再送やフロー制御が個々の通信の正確さを支え、AIMDという譲り合いの設計が道全体の速さを支え、RIP・OSPF・BGPという階層的なルーティングが道の選び方を支え、公開鍵暗号とTLS・証明書が見知らぬ相手との信頼を支え、CAP定理を踏まえた設計と負荷分散・CDNが世界規模の需要を支えている。
これらの仕組みに共通して流れている発想を、最後にもう一度確認しておきたい。それは、**「単純なルールに従う多数の主体が、それぞれ自分の持ち場だけを見て動いているにもかかわらず、その積み重ねの結果として、全体として秩序立った、効率の良いふるまいが生まれる」**という発想である。AIMDにおける「みんなが自分から譲り合う」設計も、BGPにおける自律システムどうしの分散した交渉も、CDNにおける「近くから配る」という分散配置も、根っこにあるのはこの同じ発想である。この発想は、次に控えている**分散システム**という、より広い主題そのものの中心にある考え方でもある。
次巻(分散システム・大規模設計)では、この巻で見たCAP定理や負荷分散のような「規模」の話題をさらに掘り下げ、複数のサーバーがどうやってデータの複製を保ちながら協調して動くか、障害が起きたときにどうやってシステム全体を守るか、といった、世界規模のサービスを支える設計の考え方を歩いていく予定である。「遠くの相手に記号を届ける」という一本の願いから始まった旅は、ここからさらに、「世界中に散らばった無数の機械が、まるで一つの大きなシステムであるかのように協調して働く」という、新しい段階へと進んでいく。
---
（本冊子は現代学問宇宙図鑑シリーズ BOOK-0119。応用の軌道ステーション群・情報工学(情報派生)分野の第2巻(ネットワーク 第2巻)。参照: BOOK-0070(情報派生_ネットワーク 第1巻)。次巻では分散システム・大規模設計への橋渡しを予定。GAKUMON_UNIVERSE.md 進捗台帳を参照。）
# BOOK-0119 ネットワーク 第2巻 — 信頼性と規模の設計（情報派生 第2巻）