ネットワーキングとインターネットを第一原理から理解する

 (fazamhd.com)
4 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • インターネットは音声・映像・文字を電気・光・電波のパターンに変換して複数の独立した事業者の機器を通過させ、中央の統制者や全経路を把握する単一主体なしに、各ホップのローカルな判断だけでデータを伝送する
  • 電信のデジタル再生、電話網の回線交換、パケット交換、Ethernet、IP、TCP、DNS、TLSは、完成済みの設計図の構成要素ではなく、それぞれの時代の物理的・運用上の限界を解決しながら積み重なってきたプロトコルである
  • IPは損失・重複・順序入れ替わりを許容するベストエフォート型の配送だけを担い、TCPが終端で再送・順序復元・輻輳制御を行い、DNSは名前をアドレスに変換し、TLSは認証と暗号化を追加する
  • Webページを最初に開くときは、コンテンツ転送より前にDNS問い合わせ、TCP接続、TLSハンドシェイクのために複数回の往復が必要なので、高い帯域幅だけではレイテンシによるスロースタートをなくせない
  • シンプルなIP階層と公開標準のおかげで、HTTP、VPN、WebRTC、QUICのような新しいプロトコルを既存ルーターの許可や交換なしに展開でき、インターネットは新たな要求が現れるたびに階層ごとの限界を補い続けている

物理信号からビットへ

  • インターネット通信は、メッセージをWi-Fiの電波、銅線の電気パルス、光ファイバーの光へと連続的に変換し、反対側で逆順に復元する
    • 機器とケーブルは何百万もの対話で共有され、データは複数の国にまたがる独立企業が所有する機器を通過する
    • 中央コンピュータがトラフィックを指揮するのではなく、各機器が次の経路だけを選ぶ
  • インターネットは一度に設計されたものではなく、パケット交換・TCP・DNS・TLSは、すでに動いていたネットワークの特定の問題を解決するために後から追加された
  • すべてのリンクの基本原理は、一方で物理量を変化させ、合意された時点で他方がそれを測定することにある
    • 張ったひもは機械的振動を伝えるが、距離が伸びると摩擦やたるみにより信号が弱くなる
    • 銅線は電圧、光ファイバーはレーザー、Wi-Fiは電波の形を変化させてビットを運ぶ

電信が確立したデジタル通信とプロトコル

  • ネットワークという言葉はもともと糸やひもが交差した網状構造を意味し、19世紀初頭の運河・鉄道網を経て、1840年代には電信の電線・中継所の体系を指すようになった
  • 1844年、Samuel MorseはWashingtonからBaltimoreへ“What hath God wrought”を送信した
    • Morse codeは音声そのものを送るのではなく、短い電気パルスと長い電気パルスという離散記号を伝えるデジタルネットワークだった
    • 中継器は弱まった波形を増幅する代わりに、パルスの有無を判定してクリーンな新しいパルスを生成した
    • 単純増幅は区間ごとにノイズまで増やすが、離散記号の再生は大陸規模でもメッセージ劣化を防いだ
  • 送受信者が文字ごとのパルスやreceived、repeatのような手順をあらかじめ共有した規則がプロトコルである
    • IP、TCP、DNS、TLSも、メッセージ形式と通信順序を公開的に合意した規則という点で同じである
  • 電信網では人間がルーティングを行った
    • 中継所の運用者がメッセージを紙テープに打ち出し、宛先に近い回線が空くと再送した
    • 混雑時間帯にはメッセージを保管箱で待機させ、この構造が後の電子的なストアアンドフォワードやルーターに再現された
  • 最初の大西洋横断電信ケーブルは1858年8月に稼働したが、絶縁損傷と過電圧問題の中で3週間で故障した
    • 成功したケーブルは1866年にSS Great Easternが約4,000kmの長さを一体で敷設した
  • ビットは0と1の2つの状態のいずれかを表す最小情報単位である
    • 8ビットの1バイトは256の状態を表現し、文字1つや小さな数値を格納できる

帯域幅とレイテンシ

  • 帯域幅はリンクが1秒あたりに運ぶビット数で、レイテンシは1ビットが反対側に到達するまでにかかる時間である
  • 帯域幅は信号送信間隔を縮めたり複数の波長を並列利用したりして高められるが、レイテンシは距離と光速によって制限される
    • 光はガラス中を毎秒約200,000kmで移動し、真空中の約3分の2である
    • New York–London区間は片道約28msが物理的下限で、往復にはその2倍が必要となる
  • 映像ストリーミングは数秒分を先にバッファしてレイテンシに耐えるが、大きな帯域幅を必要とする
  • ビデオ通話は帯域幅要件が比較的小さくても、低レイテンシが重要である
  • Webページはコンテンツを受け取る前にDNS、TCP、TLSの往復を経るため、ギガビット接続でも開始が遅くなりうる
  • 帯域幅は送信スケジュールから、レイテンシはリンク長から生じるため、両者は互いに交換できる値ではない

回線交換とモデム

  • 1876年以降、電話網は通話ごとに端から端までの専用電気経路を予約する回線交換を使った
    • 初期には交換手がパッチコードを差し込み、その後は電気機械式リレーが自動化した
    • 音声は通話中ずっと流れ続けるため、予約された回線を継続利用する構造が合理的だった
  • 1950～60年代、コンピュータは既存の電話網を使うしかなく、モデム(modulator-demodulator) でデジタルビットをアナログ音声に変換した
  • Bell 103のような300-baudの初期モデムはFSKを使用した
    • 1は高い周波数、0は低い周波数の連続音で表した
    • 相手側モデムは聞こえる周波数を判別してビットを復元した
  • データ送信前には通信速度、誤り訂正、回線特性を交渉した
    • 1981年のHayes Smartmodem以降は、人が接続状態を確認できるようスピーカーがオンになっており、ダイヤルトーン、呼び出し、機能交換、変調交渉、イコライザ訓練が聞こえた
    • 実際のハンドシェイクは30秒以内に複数の段階を経た
  • DSLとケーブルは既存の電話線・テレビ線を常時接続のデジタルリンクとして再利用し、家庭向け光ファイバーは音声網の配線を完全に離れた
  • コンピュータトラフィックは、要求後に読み込みや計算の間休むバースト型である
    • 回線を予約すると大半の時間で容量が遊休化し、他の利用者は使えなくなる
    • 経路は通話開始時に固定されるため、中間リンクが1本切れただけでも接続全体が終了する
  • 1960年代初頭には、研究用コンピュータの増加、対話型コンピューティングのバースト性、一部区間を失っても生き残る必要があった米軍の要求が、回線交換の限界を露呈させた

パケット交換とベストエフォート型配送

  • Paul Baranは耐障害性のために、Donald Daviesは回線共有のために、独立してパケット交換を考案し、Daviesがpacketという名称を付けた
  • メッセージは小さな単位に分割され、各パケットは送信元・宛先のような制御情報を含むヘッダーと、実データであるペイロードで構成される
  • ルーターはパケット全体を受け取った後で宛先を読み、自身のテーブルに従って次のリンクへ送るストアアンドフォワード(store-and-forward) を行う
    • 規模を維持するため、個別ホストではなく、アドレス範囲であるネットワークをテーブルに記録する
  • パケットは複数の対話が同じ回線を交差利用し、それぞれ独立にルーティングされる
    • 中間ルーターが停止しても、その後のパケットは別経路を使える
    • 障害情報が広がる前には古い経路へ送られて失われ、新しい経路が安定する過程を収束(convergence) と呼ぶ
  • アドレスを持つ装置はホスト、対話を始める側はクライアント、既知の固定アドレスで要求を待つ側はサーバーである
  • 入力速度が出力リンクより速いと、ルーターはパケットをメモリに待機させ、キューが満杯になると超過分を破棄する
  • ネットワークはパケットの損失・重複・順序入れ替わりを許容するベストエフォート型配送しか提供しない
    • 信頼性をネットワーク中央ではなく終端コンピュータに任せた決定が、インターネットをシンプルに保ち、世界規模へ拡張する基盤になった

ARPANETと最初のルーター

  • ARPAは1969年、大学の研究用コンピュータを接続するため、最初の実用的なパケット交換網であるARPANETを支援した
  • メーカーやOSが異なるメインフレームにパケット交換処理を任せるのが難しかったため、BBNはIMP(Interface Message Processor) を製作した
    • IMPはメッセージをパケットに分割・ルーティング・再構成する専用ミニコンピュータだった
    • サイトのメインフレームはローカルIMPに接続され、IMP同士は専用電話回線で通信した
    • 計算を行うメインフレームをHost、伝送インフラをIMPと区別した用語は今日まで続いている
    • IMPは最初のルーターであり、家庭用無線ルーターも専用装置がネットワークプロトコルを代行処理するという同じパターンに従う
  • 1969年10月29日、UCLAのCharley KlineがStanford Research InstituteにLOGINを入力していた際、LOまで送った時点で受信側システムが故障した
  • ARPANETは1969年12月に4ノードとなり、1973年にはNorwayとLondonまで拡張された

Ethernetとローカルネットワーク

  • ARPANETのような広域網は WAN、オフィス内の複数の機器を接続する網は LAN である
  • Robert Metcalfeは1973年にXerox PARCで Ethernet を設計した
    • ハワイ諸島を結んでいたALOHAnetの無許可送信と衝突処理から着想を得た
    • 初期のEthernetでは、すべてのコンピュータが1本の共有同軸ケーブルに接続され、すべてのフレームを受信するが、自分のアドレスのものだけを処理した
  • 同軸ケーブルは、中心の銅線、絶縁層、円筒形のシールド、外被で構成される
    • シールドは戻り経路であると同時に、外部からの干渉を遮断する
  • 共有回線で2つの機器が同時に送信すると 衝突 が発生する
    • CSMA/CDは送信前に媒体を監視し、送信中に衝突を検知すると即座に停止し、ランダムな時間の後に再試行する
    • 衝突が繰り返されるときに遅延範囲を2倍ずつ広げる 指数バックオフ が、永続的な衝突を防ぐ
  • 現代のオフィスでは、共有同軸ケーブルの代わりに、各機器からスイッチまで専用のツイストペア線とRJ-45コネクタを使う
    • 各ポートが専用線で、送受信経路が分離された 全二重 であるため、原理的に衝突はない
    • CSMA/CDは現代の有線Ethernetでは不要になったが、共有媒体である空気を使うWi-Fiでは競合の問題が再び現れる

  • スイッチとMACアドレス

    • ネットワーク switch という名称は、鉄道の分岐器、電流を切り替える電気スイッチ、電話交換台といった系譜を持つ
    • 現代のネットワークスイッチは、数百万個のトランジスタスイッチで構成されたASICでフレームを転送する
    • ルーターはグローバルなネットワークアドレスを使うが、スイッチはローカルなハードウェアアドレスである MACアドレス を使う
    • Ethernetにおけるデータ単位はフレームである
    • MACアドレスは 00:1A:2B:3C:4D:5E のように16進数6組、合計48ビットで表記する
    • 16進数1桁はちょうど4ビット、2桁は1バイトに対応するため、生のビット列を短く表すのに適している
    • 従来のMACアドレスでは、先頭3組はメーカーのOUI、後ろ3組はそのインターフェースのシリアル番号である
    • スマートフォンもWi-FiチップとBluetoothチップにそれぞれアドレスを持つ
    • 固定アドレスを使った公共の場での追跡を防ぐため、現代のOSは探索・接続時に一時的なランダムMACアドレスを生成する
    • スイッチはフレームの 送信元MAC と流入ポートを観察し、転送テーブルを自動的に学習する
    • 宛先がまだ分からなければ、ほかのすべてのポートへフラッディングする
    • 宛先が分かっていれば、その1つのポートにだけ転送する
    • スイッチのテーブルはローカルトラフィックから受動的に推論されるが、ルーターのテーブルは手動設定またはルーティングプロトコルで埋められる
    • MACアドレスはローカルセグメント内でのみ意味を持ち、IPアドレスはネットワーク間を移動するために使われる

IPとネットワークのネットワーク

  • 1970年代のSATNET、PRNET、Ethernetなど、異なるパケット網は形式・アドレス・最大サイズが異なり、直接通信できなかった
  • Vint CerfとBob Kahnは1973年に、各ネットワークの内部構造を統一せずに接続する internetwork を設計した
  • IPは、すべての参加ネットワークが合意すべき薄い共通層である
    • 汎用的なIPアドレスと汎用的なパケット形式を定義する
    • 各ローカルネットワークは、IPパケットを自前のフレーム内に入れて運ぶ
    • ルーターは通信状態を記憶せず、損失の回復もしない
    • 設定段階もパケット間の共有状態もない コネクションレス であるため、銅線・光ファイバー・無線・衛星のどこでも実装できる
  • さまざまな物理媒体が下に、さまざまなアプリケーションが上にあり、その中央でIPが狭い共通接点を成す 砂時計構造 が相互運用性を生み出す

  • IPv4アドレスと最長プレフィックス一致

    • IPv4アドレスは32ビット、つまり4つのオクテットを 91.198.174.192 のようにドット区切りの10進数で表記する
    • /24 は先頭24ビットが固定されたネットワークプレフィックスである
    • 255.255.255.0 というサブネットマスクも、同じ固定ビットを別の方法で表したものだ
    • ルーターは宛先と経路をXORし、プレフィックス以降をマスクして、固定部分が一致しないかどうかを検査する
    • 複数の経路が一致する場合は、最も多くのビットが固定された 最長プレフィックス一致 を選ぶ
    • 具体的な経路がないときは 0.0.0.0/0 のデフォルトルートを使う
    • 各ルーターはインターネット全体の地図ではなく、隣接先と大まかな方向だけを知っていれば、次のルーターの同じ判断を通じて宛先に到達できる

  • Classful addressingからCIDRへ

    • 1981年のclassful addressingは、ネットワーク規模を3種類に固定していた
    • Class A /8 は16,777,216個、Class B /16 は65,536個、Class C /24 は256個のアドレスを提供する
    • 約4,000個のアドレスが必要な組織は、Class Bを受け取って約94%を無駄にするか、Class Cを16個受け取ってすべてのコアルーターに16個の経路を作るしかなかった
    • 1990年代初頭には、アドレス空間とルーターのメモリが急速に枯渇していった
    • 1993年に導入された CIDR は、プレフィックス長を自由に決められるようにした
    • /20 1つで4,096個のアドレスを提供し、隣接ブロックを1つの経路に集約できる
    • IANAはIPv4空間全体を管理し、5つの地域インターネットレジストリに大きなブロックを割り当てる
    • 地域レジストリはISPに、ISPは企業や家庭に、より小さなブロックを配分する
    • 各機関が自分の領域だけを管理する階層的委任は、DNSと同じ拡張原理である

  • TTL、ICMP、ping、traceroute

    • IPヘッダーの TTL は時間ではなく残りホップ数を表し、ルーターごとに1ずつ減少する
    • 0になるとパケットを破棄し、誤った経路によってパケットが無限に循環する事態を防ぐ
    • TTLが期限切れになると、ルーターは送信元へICMP Time Exceeded を送る
    • ping はICMP Echo Request と Echo Reply の往復時間で、特定ホストまでの遅延を測定する
    • traceroute はTTLを1、2、3と増やし、各ホップで発生した Time Exceeded 応答を収集する
    • もともとループ防止用に作られたTTLから、経路診断機能が派生した

  • MTUとフラグメンテーション

    • 各リンクには一度に運べる最大サイズである MTU があり、Ethernetでは1,500バイトである
    • 従来のIPv4ルーターは、次のリンクより大きいパケットを複数の断片に分割し、宛先で再構成した
    • ルーターの作業量が増え、断片を1つでも失うと元のデータ全体を再送しなければならない
    • 現代の方式では don’t fragment を設定し、転送できないルーターがICMPで許容MTUを知らせる Path MTU Discovery を使う
    • より狭い後続リンクが現れた場合、送信者は再びサイズを縮小し、実際の経路上の最小MTUに収束する
    • IPv6はルーターによるフラグメンテーションを廃止し、送信者側のPMTUDのみを許可する

  • ユニキャスト・ブロードキャスト・ARP・マルチキャスト

    • 1つの送信者から1つの受信者へ送る ユニキャスト が、インターネットトラフィックの大部分を占める
    • サブネットは、同じ回線または無線チャネル上で、ルーターなしにMACアドレスで直接到達できる物理的・数値的な近隣である
    • ブロードキャストはサブネット内のすべてのホストに配送され、ルーター境界を越えない
    • DHCPはアドレスを持たない機器に設定を配布する
    • ARP は「このIPを持つ機器は誰か」をブロードキャストし、所有者だけがユニキャストで応答して、ローカルIPアドレスに対応するMACアドレスを見つける
    • 結果は数分間キャッシュされる
    • 外部サブネット宛の目的地については、リモートサーバーではなくデフォルトゲートウェイのMACアドレスを問い合わせる
    • マルチキャストは参加しているグループにだけ1つのパケットを配送し、IPTVや内部ルーティングプロトコルなどで使われる
    • IPv4の約43億個のアドレスでは不足し、128ビットアドレスを使う IPv6 が約20年にわたって並行展開され、現在はトラフィックのほぼ半分を運んでいる

TCPが生み出す信頼性

  • TCP は、IPが提供しない信頼性を両端で実装し、中間ルーターはTCPの状態を認識しない
  • すべてのバイトに番号を付け、受信側は次に期待するバイトをACKで知らせる
    • 確認されていないデータは再送する
    • 順序が入れ替わったデータは番号に従って再整列してからアプリケーションに渡す
  • 双方が対話の状態を記憶するため、TCPはコネクション指向であり、明示的な開始と終了がある
  • 層ごとのデータ単位は、Ethernetフレーム、IPパケット、TCPセグメント、UDPデータグラムである

  • 3-way handshakeとチェックサム

    • TCPの3-way handshakeは、双方の初期シーケンス番号を同期する
      1. クライアントが SYN, seq=5000 を送る
      1. サーバーが SYN-ACK, seq=9000, ack=5001 で応答する
      1. クライアントが ACK, ack=9001 を送る
    • チェックサムは、送信バイトから計算した値を一緒に送り、受信側が再計算して偶発的なビット破損を検出する
    • 不一致のパケットは破棄され、ACKがないため既存の再送手順が復旧を担う
    • EthernetはCRCベースのframe check sequence、IP・TCP・UDPは1の補数加算を使う
    • チェックサムを再計算できる攻撃者による意図的な改ざんは防げず、その役割はTLSが担う

  • フロー制御と輻輳制御

    • TCP送信側は、確認されていないデータを制限するスライディングウィンドウを維持する
    • ACKが到着するたびにウィンドウが前進し、高速な送信側が低速な受信側を圧倒しないようにする
    • 損失は中間ルーターのキューあふれの信号と解釈され、送信側はウィンドウを縮小する
    • 1986年10月、Lawrence Berkeley LabとUC Berkeleyの間の400mリンクは、送信側が損失に対してさらに多くの再送で対応したことで、32,000bpsから40bpsへと崩壊した
    • Van Jacobsonの輻輳制御は、損失時には送信量を乗数的に減らし、成功時には慎重に増やす
    • 数十億の接続が中央調整なしに同じローカルルールを適用し、共有ネットワークの輻輳崩壊を防いでいる
    • 中間のパケットが欠落すると、受信側は最後の連続バイトに対する重複ACKを送り、送信側はタイムアウト前に損失を検知して再送できる

  • ポート・ソケット・UDP

    • IPアドレスがデバイスを識別するなら、ポートはそのデバイス内のプログラムを識別する
    • HTTPSサーバーは慣例的に443番ポートを使う
    • IPアドレス、ポート、プロトコルの組み合わせが、アプリケーションのソケット終端を表す
    • クライアントOSは接続中、一時ポートを借りて応答が返ってくる先を区別する
    • UDP はIPにポートだけを追加し、接続確立、再送、順序復元を提供しない
    • Webページ・メール・ファイルのように完全性が重要なデータにはTCPが適している
    • ビデオ通話・マルチプレイヤーゲーム・DNSのように、遅れたデータが損失より悪い場合にはUDPが適している
    • TCP/IPは1983年1月1日にARPANETの公式プロトコルとなり、IPパケットの運搬に同意するすべてのネットワークがインターネットを構成する

ルーティング情報が作られる仕組み

  • 組織内部のOSPFとRIP

    • 1つの組織内では、IGP がリンク状態と経路情報を交換する
    • OSPFのようなリンクステートプロトコルでは、各ルーターが自分の接続情報を全体へフラッディングする
    • すべてのルーターが同じトポロジーマップを持ち、独立して最短経路を計算する
    • RIPのようなディスタンスベクタープロトコルは、隣接ルーターに宛先までのホップ数だけを知らせる
    • 交換量は少ないが、隣接ルーターの数値が本当に正しいかを検証するための全体地図がない
    • 障害後にテーブルが新しい状態を反映する過程が収束である
    • OSPFは実際のトポロジー変更を伝えるため、すばやく収束する
    • RIPは、2つの隣接ルーターが互いを経路として信じるループを作ることがあり、パケットはTTLが尽きるまで往復する
    • RIPは16ホップを到達不能として扱い、複数の緩和策があってもOSPFより収束が遅いため、ほとんどの本番ネットワークで置き換えられている

  • 自律システムとBGP

    • NSFNETは1985年、複数の地域学術ネットワークをつなぐバックボーンとして始まった
    • 当初は商用トラフィックを禁止しており、1991年に制限を解除した
    • 1995年の閉鎖後、バックボーンの役割は複数の競争する商用通信事業者に分散され、インターネットは単一の所有者を持たない構造になった
    • インターネットは、ISP、大学、通信事業者、クラウド企業など、数万の**自律システム（AS）**で構成される
    • BGPは、各ASが到達可能なアドレスブロックと通過してきたAS経路を隣接ASに知らせるようにする
    • 実際の経路選択は、速度よりも事業ポリシーを優先する
    • AS経路長は、local preferenceやweightのようなポリシー基準の後に適用される判定条件である
    • 小規模事業者は、上位事業者にインターネット全体への接続費用を支払うtransitを購入する
    • 同程度の規模のネットワークは、transit費用を減らすために無償ピアリングを結ぶ
    • インターネットエクスチェンジの共通スイッチング設備で、数百のネットワークが接続される
    • DE-CIXとAMS-IXは約1,000のネットワーク規模を接続している
    • BGPポリシーは一般に、有償の顧客経路、無料のピア経路、有償の上位事業者経路の順に選好する
    • Lumen、Arelion、NTTのようなtier-1バックボーンは互いにピアリングし、上位事業者に料金を支払わない

海底光ケーブル、Anycast、CDN

  • 約600本の海底光ケーブルが、事実上ほぼすべての大陸間トラフィックを運んでいる
  • 1956年のTAT-1は、同軸銅線で36の音声回線を提供し、約70kmごとに増幅器を配置した
    • アナログ増幅は信号と雑音を一緒に増幅する
  • 1988年のTAT-8は、初の大西洋横断光ケーブルで、2本のガラスファイバー上で数万の音声回線相当の容量を提供した
  • 光ファイバーは、屈折率の高いコアとそれを囲むクラッドの境界で全反射を利用する
    • 一般的な鏡と違って境界反射損失がなく、約100kmにわたって光を導いた後に増幅できる
  • 波長分割多重化は、各レーザーのビットストリームを異なる波長に載せて1本にまとめる
    • 波長は線形媒体内を一緒に進み、反対側のフィルターで分離される
    • 実際のシステムでは1本あたり約100波長を載せ、新しい波長を1つ追加するごとに、既存の海底ガラスのスループットが1ストリーム分増える
  • Anycast は、複数の大陸のサーバーが同じIPを使い、各地点で同じ経路をBGPで広告する
    • クライアントは設定変更なしに、トポロジー上で近いサーバーへ到達する
  • CDNはAnycastや位置認識DNSを使って、コンテンツを近くのサーバーから提供する
    • CloudflareとAkamaiは、動画・画像・Webサイトのコピーを世界中に配置している
    • 光速が生む遅延の下限を減らす方法は、リクエスト前にデータをユーザーの近くへ移しておくことだ
  • BGPは、隣接ASの広告をおおむね信頼する
    • 2008年、Pakistan Telecomが国内のYouTube遮断のためにより具体的な経路を広告し、この情報が世界中に広がって、多くのトラフィックがPakistanへ流れ込み消失した
    • RPKI は、署名付きレジストリを通じてアドレスブロックの経路広告権限を検証する

家庭用プライベートネットワークとNAT

  • 家庭用ルーター1台には、Ethernetスイッチ、Wi-Fi無線装置、DHCP、デフォルトゲートウェイ、DNS設定配布機能が組み合わされている
  • インターネット上でルーティングされないプライベートIPv4ブロックは、繰り返し再利用できる
    • 10.0.0.0/8 は16,777,216個のアドレス
    • 172.16.0.0/12 は1,048,576個のアドレス
    • 192.168.0.0/16 は65,536個のアドレス
  • NAT は、内部のプライベートアドレスとポートをルーターのグローバルアドレスとポートに変換し、応答を元の内部セッションへ戻すテーブルを維持する
    • 別々の家庭にある 192.168.1.5 同士は、パケットがそれぞれのプライベートネットワークを出ないため衝突しない
  • NATは内部から開始されたセッションだけを記録するため、要求されていない外部接続は破棄する
    • 家庭でサーバーを運用するには、特定の外部ポートを内部デバイスに接続するポートフォワーディングが必要になる
    • ISPがグローバルアドレスを変更した場合は、それを別途追跡しなければならない
    • P2Pビデオ通話には、双方が同時にパケットを送るなどのNAT越え技術が必要になる
    • アドレス不足の一時的な解決策が、インターネットを外部からの要求を受けるサーバーと、要求だけを開始するデバイスに分けることになった
  • 127.0.0.0/8 はループバックアドレスであり、ネットワークカードまで行かずOSが同じコンピューターへ戻す
    • 127.0.0.1 は慣例的に localhost である
    • 開発サーバーの 127.0.0.1:3000 は、そのコンピューターからしかアクセスできない
  • デバイスは、ローカルハードウェアを表すMACアドレスと、ネットワーク上で割り当てられたIPアドレスの両方を持つ

DNS: 数字の代わりに名前を使う

  • ARPANETの初期には、Stanford Research InstituteのElizabeth Feinlerのグループが、単一のHOSTS.TXTであらゆる名前とアドレスを手作業で管理していた
    • 各コンピュータがそのファイルを定期的にダウンロードしており、登録されていない機器は事実上見つけられなかった
    • ネットワークの成長により、一つのオフィスの編集能力と単一のダウンロード地点がボトルネックになった
  • Paul Mockapetrisは1983年に委任ベースのDNSを設計した
    • en.wikipedia.orgは右から左へ、root、org、wikipedia.org、enという階層に従う
    • ネームスペースは、各組織が権威サーバーを管理するzoneに分かれている
  • 機器は、ISPやCloudflareの1.1.1.1のような再帰リゾルバに問い合わせを任せる
    1. rootは.orgのネームサーバーを教える
    2. .orgはwikipedia.orgの権威サーバーを教える
    3. Wikipediaの権威サーバーが91.198.174.192と3,600秒のTTLを返す
  • DNSのTTLは、IPのホップ数とは異なり、秒単位のキャッシュ寿命である
    • ブラウザ、オペレーティングシステム、再帰リゾルバが応答をキャッシュするため、人気のある名前は近い場所で即座に解決される
    • キャッシュは上位DNSの負荷を下げる一方、アドレス変更後も古い値がTTLの間残ることで、ある種の慣性を生む
  • ドメインを購入すると、registrarが.comのようなregistryのzoneに、権威ネームサーバーを指定するNS recordを記録する
    • ドメインのzone fileには、IPv4向けのA recordやIPv6向けのAAAA recordなどが含まれる
    • Cloudflare、Route 53、registrar、または自前で運用するサーバーが権威DNSを担える
    • 位置認識DNSは、問い合わせ元の場所に応じて異なるデータセンターのアドレスを返すことができる

  • DNSのセキュリティとプライバシー

    • 初期のDNSは、先に到着して問い合わせと一致する応答を信頼していた
    • Dan Kaminskyは2008年に、16ビットのトランザクションIDの65,536通りの可能性を悪用したキャッシュポイズニングの危険性を公表した
    • 攻撃者が本物の応答より先に、IDを一致させた偽の応答と悪意あるネームサーバー情報を送ると、リゾルバは攻撃者が指定したTTLの間、偽情報をキャッシュしてしまう可能性がある
    • DNSSECでは、各zoneがレコードに暗号学的署名を付け、リゾルバが信頼するroot keyまでチェーンを検証する
    • 偽の応答の署名は検証されないため破棄される
    • DNSSECは真正性と完全性を保証するが、問い合わせそのものを暗号化はしない
    • DoTとDoHは、それぞれDNS問い合わせをTLSまたはHTTPSの中に入れ、経路上の観測者が参照ドメインを読めないようにする

Webが追加したユーザーインターフェース

  • 1980年代末までにIP、TCP、Ethernet、DNSは完成していたが、情報にアクセスするには対象システムとコマンドラインツールを知っている必要があった
  • Tim Berners-Leeは1989年にCERNで文書共有システムを提案し、1991年にWorld Wide Webを稼働させた
  • Webは3つのシンプルな構成要素を使う
    1. HTMLは文書内の単語や要素を、インターネット上の別の文書へつなぐ
    2. URLはhttps、en.wikipedia.org、/wiki/Internetのように、プロトコル・サーバー・パスを表す
      • HTTPSのデフォルトポートは443、HTTPは80なので省略できる
    3. HTTPはTCP上でGET /pageのようなリクエストとレスポンスをやり取りする
      • 200 OKは成功、404 Not Foundは文書がないこと、500 Internal Server Errorはサーバー内部の失敗を意味する
  • URLはDNSの上に、HTTPはTCPの上に、TCPはIPの上に構築されるため、新しいWebのために既存のルーターを変える必要はなかった
  • IP、TCP、DNS、HTTPは、誰でも無料で読んで実装できるRFCで定義されている
    • RFCは1969年にARPANETの開発者たちが意見を求めるためのメモとして始まった
    • IETFは1986年からインターネットプロトコルを標準化している
    • 80番・443番ポートも、RFCがIANAに登録した慣例である
  • NCSA Mosaicは1993年に文書内へ画像を配置し、同じチームのNetscape Navigatorは1994年にWebを家庭へ広めた

公開された回線で秘密をやり取りするTLS

  • 初期のインターネットプロトコルは平文のバイト列を送るため、ルーター、ISP、中間ネットワークが内容を読んだり改変したりできた
  • 公開鍵暗号は、計算は容易だが逆算は現実的に難しい演算によって、公開鍵と秘密鍵のペアを作る
    • 公開鍵で暗号化したデータは秘密鍵でしか復号できない
    • 秘密鍵で作った署名は公開鍵で検証できる
    • 実際の署名では、メッセージ全体の代わりに、すべてのバイトから計算したハッシュに署名することで、変更の有無も結び付ける
    • RSAだけでなく、ECDSAやEd25519も、秘密鍵で署名し公開鍵で検証するという契約を提供する
  • 攻撃者が銀行になりすまして自分の公開鍵を提示する問題は、証明書で解決する
    • ブラウザにあらかじめ含まれている認証局の公開鍵が、サーバーの身元と公開鍵の結び付きを保証する
    • サーバー証明書から中間認証局を経て信頼されたrootまで、署名チェーンを検証する
    • チェーンがrootに到達できなければ、ブラウザは全画面のセキュリティ警告を表示する
  • Netscapeは1994年にSSLを作り、その後TLSとして標準化された
    • TLSはTCPとHTTPの間に位置する

  • Diffie–Hellmanとセッションキー

    • TLSハンドシェイクで、ブラウザはClientHello、対応する暗号スイート、公開key shareを送り、サーバーは選択した暗号スイート・証明書・署名済みkey shareを返す
    • 小さな例で公開定数g=5、p=23を使うとき:
    • ブラウザは秘密値a=6でA=5⁶ mod 23=8を計算する
    • サーバーは秘密値b=15でB=5¹⁵ mod 23=19を計算する
    • ブラウザは19⁶ mod 23=2、サーバーは8¹⁵ mod 23=2を計算し、同じセッションキーを得る
    • 盗聴者はg、p、A、Bを見るが、実際の大きさでは離散対数問題を解いて秘密値を得るのは難しい
    • 現代のブラウザは、より小さい数で同等の安全性を提供する楕円曲線方式の交換を使う
    • 公開鍵演算はすべてのバイトに適用するには遅いため、鍵交換にだけ使い、その後は同じ鍵で暗号化・復号する高速な対称鍵を使う
    • HTTPSの錠前は、中間装置が通信相手、時点、データ量は見えても、内容は読めないことを意味する

カプセル化とVPN

  • 各層は上位層のデータを自分のヘッダーで包む
    • HTTPリクエストはTLS recordの中に、TCP segmentの中に、IP packetの中に、EthernetまたはWi‑Fi frameの中に入る
    • スイッチとルーターは、それぞれ自分に必要な外側のヘッダーだけを処理する
  • VPNはアプリケーションのストリームではなく、IPパケット全体を暗号化し、VPNサーバーのアドレスを持つ新しいパケットのペイロードとして入れる
    • ISPはVPNサーバーとの間でやり取りされる暗号化トラフィックしか見えない
    • 訪問先サイトには、ユーザーのアドレスではなくVPNサーバーのアドレスが見える
    • VPN事業者は、以前ISPが見ていた位置を引き継ぐため、絶対的にセキュリティを追加するというより、信頼の置き場所を移すことになる
  • VPNの本来の用途は、リモートのノートPCを会社の私設ネットワークに接続し、あたかもオフィスに直接つながっているかのように動作させることだ

リンクをクリックしたときに実際に起こること

  1. ブラウザが https://en.wikipedia.org からホスト名を抽出し、DNSでアドレスを引く
  2. 得られたアドレスの443番ポートにTCP接続を開き、3-way handshakeを行う
  3. TLSハンドシェイクで証明書チェーンを検証し、セッションキーを合意する
  4. 暗号化された GET /wiki/Internet リクエストを送信する
  5. 数十個のIPパケットで届いたHTMLをTCPが再順序化・再送・再構成し、TLSが復号し、ブラウザが解釈して画面に描画する

  • 段階別の障害診断

    • どのサイトも開けない場合は、Wi-Fi、ルーター、ISPリンクのようなDNS以前の区間を点検する
    • 1.1.1.1 のような既知のアドレスに ping を送って、ローカルネットワークの外に到達できるか確認できる
    • 他のサイトは開けるのに特定の名前だけ解決できないなら、DNSキャッシュまたはそのサイトのレコードの問題である
    • DNSは成功するのにTCP接続がタイムアウトするなら、サーバーまたは途中のネットワークの問題であり、traceroute で到達したホップを確認する
    • 全画面の証明書警告は、TLS証明書チェーンの検証失敗である
    • すべての通信が成功してHTTP 500 を受け取ったなら、リクエストはサーバーまで完全に到達しており、失敗はサーバー内部で発生している
    • DNS、TCP、TLSはそれぞれコンテンツの最初の1バイトの前に往復遅延を必要とするため、高速回線でも初期応答が遅くなることがある

  • パケットヘッダーと階層ごとの可視性

    • 例のリクエストは20バイトのIPv4ヘッダーと20バイトのTCPヘッダーを持つ
    • IPヘッダーには、全長、断片化フラグ、TTL、TCPを意味するプロトコル番号6、チェックサム、送信元・宛先アドレスが入る
    • TCPヘッダーには、一時的な送信元ポート 54211、宛先ポート 443、シーケンス番号、ACK番号、フラグ、ウィンドウサイズ、チェックサムが入る
    • 途中のルーターはIPヘッダーだけを読み、20バイト以降のTCP情報や暗号化されたペイロードは開かない
    • TLSはペイロードを暗号化するが、配送に必要なIP・TCPヘッダーは暗号化しないため、通信相手とデータ量は観測可能である

インターネットの階層構造

  • リンク・物理層のEthernet、Wi‑Fi、fiberは、1つのローカル媒体上でフレームとビットを移動させる
  • ネットワーク層のIPは、独立したネットワークをまたいでパケットをホップ単位でルーティングする
  • トランスポート層のTCPとUDPは、プログラムごとの配送、信頼性、または低オーバーヘッドを提供する
  • セキュリティ層のTLSは、回線を暗号化し、相手を認証する
  • アプリケーション層のHTTPとDNSは、文書要求と名前解決というユーザー上の意味を提供する
  • 下から上へ、各層は直下の層の限界を隠す
    • リンク層は、共有ケーブルと無線媒体の物理的な問題を隠す
    • IPは、所有者の異なるネットワーク境界を隠す
    • TCPは、損失・重複・順序変更を隠す
    • TLSは、盗聴と改ざんを防ぐ
    • HTTPは、全体の過程をリクエストとレスポンスに単純化する
  • 1984年のOSIモデルは、物理層・データリンク層を分離し、セッション・プレゼンテーション・アプリケーションを区別した7階層を定義した
    • 実際のインターネットは先に展開されたTCP/IP構造を使ったが、layer 2 スイッチング、layer 3 ルーティング、layer 7 アプリケーション認識というOSI用語は業界に残った

QUICと進化し続けるインターネット

  • 階層は下位インターフェースにだけ依存するため、銅線を光ファイバーやWi‑Fiに置き換えても、アプリケーションを変更する必要はない
  • HTTP/3は、TCPの代わりにUDP上の QUIC で信頼性と暗号化をまとめて実装する
  • TCPの単一の順序付きバイトストリームでは、多重化されたリクエストのうち1つのパケットが失われると、無関係なリクエストも後ろで待たされる
    • QUICは、リクエストごとに独立してACKされるストリームを提供し、損失によって停止するのをそのストリームだけに限定する
  • TCPハンドシェイクの後にTLSハンドシェイクを順番に行うと、HTTPデータの前に2回の往復が必要になる
    • QUICは、転送設定と暗号化を1つのハンドシェイクに統合し、記憶されているサーバーへの再訪時には追加の往復なしで開始できる
  • TCP接続はIP・ポートの組み合わせに縛られるが、QUICは携帯電話がWi‑Fiからセルラーへ切り替わってアドレスが変わっても接続を維持する
  • IPはポートでペイロードを渡すだけで、内部プロトコルを制限しない
    • SSHはリモートシェル、SMTPはメール、MQTTは制約のあるIoT機器向けの publish/subscribe、WebRTCはブラウザ間の直接音声・映像、ゲームエンジンは古い位置更新を捨てるカスタムUDPプロトコルを使う
    • GoogleはQUICをChromeと自社サーバーの間に独自展開した後、IETFがHTTP/3として標準化し、既存のインターネットインフラの変更は必要なかった
  • IPv4アドレス枯渇の後も、IPv6移行は基盤層の置き換えコストのため進行中であり、リアルタイム映像・クラウドゲーム・リモートコラボレーションは遅延の限界を引き続き押し上げている
  • 低軌道衛星は往復遅延で海底ケーブルと競争しており、今後のプロトコルも、現在のアプリケーションが既存階層の限界と衝突するとき、新たなトレードオフを通じて登場することになる

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの反応

  • 比べてみると、こちらの記事も 構成が非常に良かった: https://explained-from-first-principles.com/internet/

  • ガイドライン上、こういう称賛だけを残すのは失礼かもしれないが、本当に素晴らしい記事だった。ネットワークが生まれた経緯とその仕組みを有益かつよく整理して解きほぐし、興味深い物語としてまとめている
    LLMが書いた文章だという反応もあるが、たとえそうでも構わない。良い記事は良い記事だ

    • 最初のアニメーションには メッセージングプラットフォームをホストするサーバー も入っているべきだ。でなければ、その例はP2Pアプリケーションに変えたほうがよい
    • 朝起きてふと思いついて、人間が自分で俳句っぽいものを作ってみた
      「すでにクリンゴン語とエルフ語はあった。今や LLM語 まで生まれた。」

  • 内容そのものは完全に著者が書いたのかもしれないが、本文と著者コメントの文体を比べると、AIでかなり強く推敲されたと確信している
    それが必ずしも悪いという意味ではないが、それに気づいた人たちを被害妄想扱いするのも不当だ

  • Digital PDP-1が受けた最初の大口注文は、ITTの紙テープメッセージング業務に投入するためのものだった: https://www.eejournal.com/article/gordon-bell-1934-2024-gran...

  • 否定的な反応とのバランスを取りたい。まだ最初の数節しか読んでいないが、単純な出発点からさまざまな概念がどう発展していったかを非常にうまく説明していた
    ソフトウェアエンジニアとして働きながら調査と試行錯誤を通じて学んだ数多くの概念を、1本の記事に凝縮してある。Fazaにはこういう記事をこれからも作って共有してほしい

    • 私たちが当然のものとして受け止めているものが、どのように発展してきたのかを説明するのが、これらの記事の目的だった。書いている間に私自身も多くを学び、理解が足りていなかった部分にも気づいた
      既存の資料は技術的な詳細だけに集中していたり、誰でも追えるように概念を過度に単純化していたりすると感じていた。そこで、詳しいが追いやすい説明を目指した
      最初は文章と図表だけにするつもりだったが、シミュレーションを使えばはるかにうまく説明できるとわかった

  • 記事の構成と表現が素晴らしく、Bartosz Ciechanowskiの仕事を思い出す: https://ciechanow.ski
    本文中の インタラクティブ要素に使った技術スタック が何か、また作り直すなら別の技術を選ぶかどうかも気になる

    • 最初はインタラクティブ要素を入れるつもりはなく、Astroベースの静的サイトを作ってMarkdownファイルにコンテンツを書いていた
      その後、AstroがカスタムJavaScriptコンポーネントを埋め込めるMDXをサポートしていると知った。初期のアニメーションは素のJavaScript、SVG、CSSトランジションで実装していたが、シミュレーションが複雑になるにつれて、状態管理のためにReact を使い始めた

  • ここにある比較的無難なコメント2つが [dead] 扱いされている。ボットコメント だとしたら、何を見て判定できるのか気になる

    • HNのブログ記事の大半と、かなりの数のコメントは主にAIで書かれているように感じる。ただ、匿名のインターネットには昔からこういう要素が常にあった

  • ページを読み込んだあとで 機内モード を有効にすると、それまで画面内に入っていなかったアニメーションが再生されない。妙な挙動だ

    • 著者です。以前はスクロールして画面内に入った時点でのみシミュレーションをダウンロードしていた
      今は ページ読み込み時にすべてのシミュレーションをダウンロード し、画面に入ったときに再生するよう修正してデプロイした

  • ここの反応は過度に否定的だ。いくつかの部分をざっと見たが、アニメーションは見やすく、文章も読みやすく、内容も低品質な生成物ではなかった
    電信の歴史的背景 が興味深く、帯域幅と遅延の違いも丁寧に扱っていた。ただ、記事が長すぎるので、この分野にあまり詳しくない読者が最後まで読む可能性は低そうだ

    • 既存の資料は教科書的すぎるか、逆に概説的すぎると感じていたので、誰でも概念を詳しく理解できるよう手助けしたかった。そこで、もう少し興味を引く説明を試みた
    • 他人を切り捨てると、自分が優れているように感じやすい。特にHNでは、長文を実際に読んで評価し、建設的な批判を出すまでには時間がかかるので、早い反応ほど否定的だったり文脈から外れたりしがちだ