[はじめに] インターネットについて話すとき、多くの人がさまざまな用語やサービスを思い浮かべると思いますが、インターネットはどのように設計され、構築されているのでしょうか? ネットワークとしてのインターネットのアーキテクチャ上の性質は何ですか? シトウ兄弟と私はかつて『コンピュータ ネットワークの問題と解決策』という分厚い本を一緒に翻訳しましたが、実際にそれを注意深く読んでそこから何かを学んだ友人は多くありませんでした。最近、ストーン兄弟は別の記事 https://cacm.acm.org/magazine/2023/2/268956-extracting-the-essential-simplicity-of-the-internet/fulltext を推奨しました。内容は簡潔で簡潔です。非公開で保管するのではなく、編集して全員と共有します。
今日、インターネットは人々が依存するユビキタス接続を提供します。インターネットの基本設計が 1970 年代にコンピューターがデータを交換できるようにするために発明されたことも多くの人が知っています。1983 年に継続的に採用されて以来、アプリケーション、テクノロジー、規模、範囲、容量の根本的な変化にエレガントに適応しながら、基本的には変わっておらず、私たちの生活の不可欠な部分となっています。
そんな優れたITインフラですが、そのシステム構成はどのようなものになっているのでしょうか？
1. 必須ニーズ: インターネット サービス モデル
ホスト上のすべてのソフトウェアは、通信時にインフラストラクチャのサービス モデルに依存する必要があります。したがって、サービス モデルの設計では、ホスト ソフトウェアにとって最適なものとインフラストラクチャがサポートできるものの間で妥協する必要があります。データ転送サービスモデルを設計する際には、その転送単位を選択し、パフォーマンスを確保する必要があります。コンピュータ通信のバースト性を考慮すると、リソースを効率的に利用するには小さな送信ユニットが必要です。インターネットはビットのパケットを使用し、現在のパケット サイズは通常 1.5 kb を超えません。
インターネット アプリケーションには、低遅延 (インタラクティブ ビデオまたは閉ループ制御) から高帯域幅 (大規模なデータ セットの送信) および信頼性の高い送信 (ファイル転送) まで、幅広いネットワーク パフォーマンス要件があります。エンジニアリングの本能は、これらの要件とネットワーク インフラストラクチャの結合をサポートして、遅延、帯域幅、信頼性の特定の限界を保証することです。ただし、インターネットは、無線および有線、共有アクセス、ポイントツーポイントなどのさまざまなローカル パケット ネットワークと相互接続する必要があり、その多くはパフォーマンスを保証できません。これらのネットワークがサポートできる最小公倍数は、「ベスト エフォート」パケット配信です。この場合、ネットワークはすべてのパケットの配信を試みますが、パケットが配信されるかどうか、いつ、どのような速度で配信されるかは保証できません。
したがって、サービス モデルに関する基本的な問題は、テクノロジーとネットワークがすべてのアプリケーション要件をサポートするのが良いのか、それともすべてのデータ パケットに対応し、控えめな最小公倍数と「ベスト エフォート型」のサービス モデルのみを提供するのが良いのかということです。インターネットの設計では、シンプルなアプローチ、つまりベストエフォート型サービス モデルが選択されています。
今では、これがより良い選択であるように思えます。まず、より緩やかなサービス モデルにより、インフラストラクチャに最小限の要件が課され、インターネットが非常に急速に成長することが可能になりました。つまり、インターネットは、パフォーマンス要件が低いため、非常に高速かつ広範囲に展開できます。第 2 に、このアプリケーションには電話網の継続である厳しいネットワーク要件があり、電話網のインテリジェント端末システムはインテリジェント ネットワークに接続され、電話の厳格なパフォーマンス要件、つまり固定料金を満たす責任を全責任を負います。伝送と信頼性の高い伝送。コンピュータが端末としてますます強力になるにつれて、さまざまなレベルのパフォーマンスに対応するように設計されることで、インターネット アプリケーションに対する要求が緩和されます。ほとんどの場合、ネットワーク オペレータは、十分な帯域幅を提供することによって、つまり、ネットワークがほとんど混雑しないようにより多くのより高速なリンクを展開することによって、適切なパフォーマンスを確保することもできます。
2. システムの抽象化: インターネットのアーキテクチャ
アーキテクチャとは、機能の実装ではなく、機能の組織化に関するものです。モジュール性は、システムの目標をクリーンなインターフェイスを備えた小さなタスクに分割することを必要とするアーキテクチャの指針です。インターネットの目的は、2 台の異なるコンピュータ上のアプリケーションが通信できるようにすることなので、インターネットは 2 つのコンポーネントに分類できます。
(i) ネットワークインフラの役割（ホスト間のデータパケットのベストエフォート伝送）
(ii) ホスト上のネットワーク サポート ソフトウェアの役割 (アプリケーションがこのベストエフォート型トランスポートを使用しやすくする)。
2.1 ネットワークインフラストラクチャ
インフラストラクチャによって実装されるホスト間配信タスクは 3 つの異なるタスクに分解でき、これらは階層的に設計されており、上位層はより広い空間範囲を持ち、下位層はよりローカルなタスクを処理します。したがって、送信ホストから受信ホストにパケットを送信するプロセスには、これらのローカル送信タスクの集約が含まれます。最適なパケット配信を提供するというローカルで低レベルのタスクは、リンクまたはブロードキャストを介した送信です。これには、デジタルからアナログへの変換とエラー修正が必要ですが、どちらもインターネットに特有のものではありません。このローカル配信タスクは、いわゆる物理層 (L1) によって処理されます。
L1 がリンク上でビット ストリームを送信できるとすると、次のタスクは、ローカル パケット ネットワーク (イーサネットやワイヤレスなど) での通信を可能にすることです。これには次の 2 つの手順が含まれます。
(i) データ パケットはビットのグループで構成され、その前にこれらのビットの送信先を記述したデータ パケット ヘッダーが続きます。
(ii) これらのパケットをローカル ネットワーク内の適切な宛先に配信します。2 番目のステップを (グローバルではなく) ローカルな送信に制限するには、ブロードキャスト (ブロードキャスト パケットがすべてのホスト (ワイヤレスなど) に到達することをメディア自体が保証します) やフラッディング (フラッディングされたパケットがネットワークによって確実に到達すること) などのスケーラブルでない技術を使用できます。すべてのホスト）。このタスクは、伝統的にリンク層または L2 と呼ばれるものによって処理されます。非ブロードキャスト ネットワークでは、このタスクはローカル ネットワーク内のスイッチによって実行され、パケットが宛先に転送されます。
最後のタスクは、L2 の機能を利用して、これらのネットワーク内のパケットをさまざまなホストに配信し、送信者のネットワークから宛先のネットワークにパケットを配信することです。このようなネットワークの相互接続は、ネットワーク相互接続層 (L3) によって処理され、2 つ以上のネットワークに接続する L2 のルーターによって実装されます。パケットは、宛先ネットワークに到達するまで、一連のルーターを介して転送されます (ルーター間の配信は、2 つのルーターが接続されているネットワークの L2 によってサポートされます)。接続されたネットワークのこの層は、L3 が上位層のホスト ソフトウェアにデータを配信するインターネットのサービス モデルも定義します。
したがって、インターネットによって提供されるユビキタス接続は、概念的にシンプルだが大胆なデザインから始まりました。
2.2 ホスト ソフトウェアでのネットワーク サポート
ネットワーク インフラストラクチャのホスト間サービス モデルでは、パケットをどのホストに配信するかをアプリケーションに指定しないため、追加の支援なしにアプリケーションが最適なパフォーマンスを達成することは困難です。これらの問題を解決するために、ホスト オペレーティング システムは、他のネットワーク サポートに加えてトランスポート層 (L4) を提供します。「ポート」と呼ばれるパケット ヘッダー内のメタデータに基づいて、L4 はホスト上の個々のアプリケーションにパケットを配信します。アプリケーションがベストエフォート サービスを利用しやすくするために、一部の公共トランスポート プロトコルは 3 つの機能を提供します。
バイトストリーム API を使用すると、アプリケーションは単純なファイルのようなインターフェイスを使用して、個別のパケットを明示的に送受信することなく、データの書き込みと読み取りを行うことができます。
ネットワークの過負荷を防ぐためにホストのパケット送信速度を制御するこのアプローチは、輻輳制御トランスポートと呼ばれ、ネットワークの輻輳（たとえば、パケットの欠落や遅延の増加など）を検出した場合、トランスポート プロトコルがネットワーク輻輳を検出する制御ループが含まれます。送信速度が低下します。輻輳制御アルゴリズムは多数あり、輻輳の検出方法と対応方法が異なります。
最も基本的なのは信頼性の高いパケット配信であり、アプリケーションはパケット損失に対処する必要がありません。この損失は最良のサービス モデルの自然な部分ですが、多くのアプリケーションでは許容できません。信頼性はアプリケーション自体または他のサポート ライブラリに実装できますが、明確にするために、この信頼性は L4 に実装されます。
4 層のインターネット アーキテクチャは、モジュール化の自然な結果です。各レイヤーは、そのすぐ上のレイヤーと真下のレイヤーのみと対話します。パケットは常に L1 の物理メディアを介して到着するため、ホストは 4 つの層すべてを実装する必要があり、ルーターは最初の 3 層を実装し、スイッチは最初の 2 層のみを実装します。そこで、ここでは 4 つの質問に答えます。
質問 #1: この階層化されたアーキテクチャはどのような種類の多様性をサポートしていますか?また、それはどのように管理されていますか?
レイヤーの 2 つの実装は、同じ上向きおよび下向きのインターフェイスを提供する限り、アーキテクチャ的に交換可能です。さらに、インターネット アーキテクチャのモジュール性により、複数のトランスポート プロトコルが L4 で共存し、複数のローカル ネットワーク設計が L2 で共存し、複数の物理テクノロジが L1 で共存でき、それぞれが独自のインターフェイスを提供します。L1 および L2 テクノロジーはネットワーク プロバイダーによって選択され、ネットワーク プロバイダーはインターフェイスに互換性があることを確認できます。つまり、ローカル ネットワーク設計で一連のリンク テクノロジーを使用できます。アプリケーションは、オペレーティング システムのネットワーク API を呼び出すときに必要な L4 プロトコルを選択します。アプリケーションとネットワーク プロバイダーは独立して選択を行います。つまり、アプリケーションは現在どのネットワーク上にあるかを知りませんし、ネットワーク プロバイダーはそのネットワーク上でどのアプリケーションが使用されるかを知りません。このアプローチは、すべての L2 設計および L4 プロトコルと互換性のあるインターフェイスのセットが L3 上にある場合にのみ、シームレスに機能します。したがって、L3 には単一のプロトコル、つまりインターネット プロトコル (IP)、現在は IPv4 と IPv6 が必要です。インターネット アーキテクチャの「腰」としての IP の独自性により、他のすべてのレベルでの多様なイノベーションが可能になります。
質問 #2: インターネットではどのような識別子が使用されますか?
インターネットでは、L2 および L3 パケット ヘッダーでルートの宛先を識別し、ユーザーとアプリケーションがアクセスしたいサービスを識別できるようにする必要があります。通常、ホスト上の接続可能な各ハードウェア ネットワーク インターフェイス (Wi-Fi、セルラー カード、イーサネット カードなど) には、MAC アドレスと呼ばれる永続的な一意のアドレスがあり、L2 がそのアドレスを識別するために使用します。目的地の土地。L3 は、インターネット内の一意のネットワークと、そのネットワーク上のアドレスを現在使用している特定のホスト インターフェイスを指定する IP アドレスを使用します (このアドレスの割り当ては時間の経過とともに変更される可能性があります)。ユーザーとアプリケーションは、アプリケーション レベルの名前を使用してホストベースのサービスを参照します。これらの名前にある程度の永続性を与えるため、サービスのベースとなるマシンや、それらのホストがネットワーク内のどこに配置されるかに依存しません。これら 3 つの識別子 (アプリケーション レベルの名前、IP アドレス、および MAC アドレス) のうち、最初の 2 つは次に低いレベルの識別子に解決される必要があります。したがって、あるホスト上のアプリケーションが別のホスト上のアプリケーションにパケットを送信しようとすると、アプリケーション レベルの名前を IP アドレスに解決する必要があります。パケットがネットワークに到達すると、L2 経由で宛先ホストまたはネクストホップ ルーターに送信されます。どちらの場合も、IP アドレスは MAC アドレスに解決される必要があります。
質問 3: インターネット インフラストラクチャをどのように編成すればよいですか?
インターネットは、ルーターで接続された非構造化された L2 ネットワークの集合ではありません。代わりに、これはドメインとも呼ばれる自律システム (AS) の集合であり、各 AS には単一のエンティティによって管理される一連の L2 ネットワークが含まれます。AS の例には、企業、大学、商用インターネット サービス プロバイダー (ISP) が含まれます。これらのシステムは、独自の内部 L3 ルーティングを制御し、システム間のホスト間トランスポートを提供するために他のシステムとのルーティング プロトコルを確立する必要があります。したがって、L3 には 2 つのルーティング タスクが含まれます。
(i) AS 内のネットワーク間のルーティング (ドメイン内ルーティング) は、AS 内のルーターによって処理されます。
(ii) AS 間のルーティング (ドメイン間ルーティング) は、2 つ以上の AS を接続するいわゆる境界ルータによって処理されます。
これら 2 つのルーティング タスクには異なる要件があるため、異なるルーティング パラダイムとプロトコルが必要になります。
質問 4: これらの部品はどのように組み合わされるのでしょうか?
インターネット経由でパケットを配信するプロセスは、アプリケーションがアプリケーション レベルの名前を IP アドレスに解決し、次にホストのネットワーク サポートを呼び出してその宛先 IP アドレスにデータを送信することから始まります。これにより、データをパッケージ化する L4 への呼び出しと、これらのパケットを配信するための L3 への呼び出しが行われます。L3 では、パケットは宛先ネットワーク (パケット ヘッダーの宛先 IP アドレスによって識別される) に到達するまで、一連のルーターを介して転送されます。各ルーターには、宛先 IP アドレスをネクストホップ ルーターの IP アドレスにマッピングする転送テーブルがあります。パケットを受信した後、ルーターは転送テーブルで適切なネクストホップ ルーターを探し、L2 を呼び出してそのネクストホップ ノードにパケットを送信します。L2 は、まずネクストホップ ルーターの IP アドレスを MAC アドレスに解決し、次にパケットをネクストホップ ルーターに配信する必要があります (ブロードキャスト経由、または次のセクションで説明する一連のスイッチを介してパケットを転送することによって)。次にネクストホップルーターによって、ホップルーターはパケットを L3 に返します。このプロセスにおける主な技術的課題は、ネクスト ホップのセットによりパケットが常に適切な宛先に到達するように L3 転送テーブルを設定することです。
3. インターネットの3つの核となる仕組み
インターネット アーキテクチャでは、ルーティング、信頼性、名前解決スキームという、インターネット アーキテクチャの実装に必要な 3 つの重要なメカニズムが特定されます。
3.1 ルーティング
「ルーティング」という用語は、インターネットを介してパケットを宛先ホストに転送するという一般的な問題を指します。この問題は、L3 で発生し、ルーターによって実装されるか、L2 でスイッチによって実装されます。L2 での実装は、ルーティングではなくスイッチングと呼ばれます。L3 ドメイン内ルーティングを検討することから始めて、次のように仮定します。
各 L3 ヘッダーには宛先 IP アドレスが含まれています。
各ルーターには、L2 で接続する一連の隣接ルーターがあります。
各ルータには、ルータがパケットの宛先ネットワークに (L2 で) 接続されているかどうかを正確に示す転送テーブルがあり、接続されていない場合は、到着パケットの宛先をパケットの転送先となる次の隣接ルータに決定的にマッピングします。
問題を単純化するために、まず、一連の静的転送テーブルがパケットを宛先に正常に誘導する状況に焦点を当てます。ルータ間の相互接続のセットは、ルータが接続されていると仮定して、ネットワーク トポロジ グラフと呼ばれます。転送テーブルのセットは、転送状態と呼ばれます。これらのテーブルの結合は、ルーティング状態と呼ばれます。指定されたルーティング ステート インスタンスは、常にパケットを宛先に向ける場合に有効です。リングが存在する場合 (つまり、開始位置と宛先アドレス)、パケットはルータを訪問した位置に戻ることができます。したがって、ルーティング状態インスタンスは、ループがない場合にのみ有効です。
ループが存在しないと仮定します。ネットワークは接続されており有限であるため、どのパケットも最終的には宛先に (L2 で) 接続されているルーターに到達する必要があります。特定の宛先にループが存在すると仮定します。その宛先にアドレス指定されたパケットがループに入っても、宛先には到達しません。
なぜこの明らかな結果を気にするのでしょうか? インターネットではさまざまなルーティング アルゴリズムを使用して転送状態を計算するため、これらのルーティング アルゴリズムの概念的な主な違いは、定常状態でのループを回避する方法にあります。ルーティング プロトコルは、ネットワーク リンクの障害や回復によってネットワーク トポロジが変化したときに、転送ステータスを迅速かつ自動的に再計算する方法の問題を解決する複雑な分散システムです。ここでは、これらの分散プロトコルの複雑さを回避し、アルゴリズムが静的ネットワーク上で安定した状態に収束するときに生成される転送状態のみに焦点を当てます。これらのアルゴリズムでは、定常状態ループを回避する方法は主に、ルーター間でどのような種類の情報が共有されるかによって決まります。
たとえば、ルーターは近隣ルーターを認識しており、フラッディング アルゴリズムを使用してこのローカル情報を他のルーターと共有できます。定常状態では、各ルーターはこの情報を使用してネットワーク トポロジ マップ全体を組み立てることができます。すべてのルーターが同じループフリー パス検索アルゴリズムを使用して、この共有ネットワーク トポロジ グラフ上の転送テーブルを計算する場合、結果として得られるルーティング状態は常に有効です。このアプローチは「リンクステート」ルーティングと呼ばれます。
コンピューター サイエンス コミュニティの多くは、インターネットは概念的に単純で大胆な設計ではなく、単に複雑なプロトコルの集合であると信じています。
もう 1 つのシナリオは、各ルーターが、何らかのメトリック (遅延など) に基づいて、他のすべてのネットワークからの距離を隣接するルーターに通知することです。ルーター α は、各宛先ネットワーク n までの距離を dα (n) = minβ [ dβ (n) + d (α, β)] として計算できます。ここで、 dβ (n) は各隣接ルーター β からネットワークまでの距離です。 n,d(α,β) の は、2 つのルータ間の距離 α,β です。この分散計算の定常状態では、各目的地への最短パス ルートが生成されますが、これにはサイクルがありません。これは「ディスタンス ベクター」ルーティングと呼ばれます。
ネットワーク トポロジが変化すると、距離ベクトル ルーティングおよびリンク ステート ルーティングの再計算中 (つまり、プロトコルがまだ安定した状態に収束していないとき)、ルーティング ステートの一時的なループが発生する可能性があります。チェックしないままにしておくと、パケットがこのようなループ内を際限なく循環し、深刻な輻輳制御が発生する可能性があります。これを防ぐために、IP プロトコルは、パケット ヘッダーに、送信ホストによって設定された初期番号で始まり、パケットが新しいルーターに到達するたびにその番号を減らすフィールドを賢明に組み込みます。このフィールドがゼロに達すると、パケットはドロップされ、それによってパケットが一時ループを通過できる回数が制限され、一時ループによる壊滅的な状況が発生しないことが保証されます。このような単純なメカニズムがなければ、すべてのルーティング プロトコルで一時的なループのトラブルシューティングが必要になり、このレベルの懸念によりルーティング プロトコルが複雑になる可能性があります。
L3 ドメイン間ルーティングを検討してください。AS は明らかに、送信元または宛先となるすべてのパケットを伝送する必要があります。他のすべてのパケットはトランスポート トラフィックとみなされ、送信元 AS から宛先 AS に向かう途中で他の AS を通過します。AS は、伝送するトラフィックと、トラフィックを宛先に迂回するために使用するルートを自由に選択できるようにしたいと考えています。ISP にとって、これら 2 つの戦略的選択は近隣の自律型 ISP との経済的考慮に大きく依存するため、競合他社に役立つ可能性のある開示を避けるためにこれらの選択を秘密にしたいと考えています。
ドメイン間ルーティングは実際には境界ルータによって実装され、境界ルータ間の複雑なドメイン内調整が必要になりますが、ドメイン間ルーティング モデルを簡単に確立して、相互接続された AS のグラフを形成し、AS 自体によって制御できます。決断。ドメイン間ルーティングは次のことを行う必要があります。
AS は任意のポリシーを選択できるため、距離ベクトルは使用できません
これらのポリシーの選択を非公開にして、リンクステート ルーティングを使用できないようにします。
これには、他のすべての AS がこれらのポリシーを使用してルートを計算できるように、AS がポリシーを明示する必要があります。もう 1 つのアプローチは、AS システムが自分のルートをアドバタイズする相手を選択することによって (「この目的地に到達するために私のパスを使用できます」というメッセージを隣接する AS システムに送信することによって)、ルーティング時に複数のネイバーがすでにメッセージを送信している場合に、AS システムがルートをアドバタイズできるようにすることです。特定の宛先への場合、ポリシーを実装するためにこれらのルートが選択されます。これらはディスタンス ベクトル ルーティングで使用されるメッセージと選択肢と同じですが、ディスタンス ベクトルではポリシーの柔軟性が考慮されていません。ルートはすべての近隣にアドバタイズされ、最短パスのみが選択されます。このローカルな自由により、ポリシーの柔軟性とプライバシーが提供されますが、ルート計算における定常状態のループを防ぐにはどうすればよいでしょうか? インターネットの解決策は、経路情報を交換することです。AS "A" が隣接する AS "B" へのパス (特定の宛先) をアドバタイズする場合、宛先へのそのトラフィックの AS レベルのパス全体を指定します。AS "B" は、すでにそのパス上にあることを認識した場合、そのパスを使用しません。すべての AS がこの見かけ上の制約に従う場合、AS によるポリシーの選択に関係なく、いわゆる「パス ベクター」ルーティングの定常状態はループフリーになります。パス ベクトル ルーティングは、現在のドメイン間ルーティング プロトコル BGP で使用されているため、BGP はインターネット上の多くの自動化システムを結合する接着剤の役割を果たします。
パフォーマンス要件が低いため、インターネットは高速かつ大規模に展開されます。
このパス ベクトルのアプローチにより、定常状態にループが存在しないことが保証されます。ただし、これはルーティング プロトコルが安定した状態に収束することを保証するものではありません。たとえば、ポリシーの発振は、パス ベクトル アルゴリズムが収束しない場合です。また、すべての AS が特定の AS へのトランジット接続を拒否する可能性があるため、結果として得られるすべての安定状態がすべてのエンドポイント間の接続を提供することを保証するものではありません。なぜこれらの異常がインターネット上で観察されないのかは不可解ですが、理論分析によると、典型的な運用慣行 (ルーティングにより収益が最大化され、コストが最小化される) により、常に安定した状態に収束するルーティング戦略が生成され、エンドツーエンド接続間のすべてのエンドポイントが提供されます。 。
ループ回避は、宛先に到達するためにフラッディングがよく使用される非ブロードキャスト ネットワークでも役割を果たします。スパニング ツリー プロトコル (STP) は、ネットワーク外部の特定のリンクを使用しないことを選択することによってツリーを作成します。つまり、ネットワーク トポロジ ダイアグラムからすべてのリングを削除します。ネットワークがスパニング ツリーになると、各スイッチがパケットが到着したリンクを除くスパニング ツリー内のすべての隣接リンクにパケットを転送することで、パケットをすべてのホストにフラッディングできます。このフラッディングにより、ホストとルーターは、「この IP アドレスを持つのはどのホストまたはルーターですか?」というアドレス解決プロトコル (ARP) メッセージを介して IP アドレスを MAC アドレスに解決でき、所有者はその MAC アドレスで応答します。この ARP 交換中 (実際にはホストがパケットを送信するたび)、スイッチは、そのホストから最後にパケットを受信したリンクを記憶することで、フラッディングを発生させずに特定のホストに到達する方法を学習できます。スパニング ツリー上の 2 つのノード間にはパスが 1 つだけあるため、ホストから送信されたパケットが到着するリンクを介してホストに到達できます。したがって、このような「学習スイッチ」を使用して、IP アドレスを MAC アドレスに解決する動作によって、送信ホストと受信ホストの間の転送状態が決まります。MAC アドレスが解決されたホストにパケットを送信する場合、ネットワークはフラッディングを使用する必要がなく、代わりにパケットを直接送信できます。
要約すると、すべてのルーティング アルゴリズムには、安定した状態 (つまり、プロトコルが収束した後) でのループ形成を回避するメカニズムが必要であり、これは交換される情報に依存します。AS 内の隣接ルーターとの情報交換を制限するには、距離ベクトルを使用してループが発生しないようにし、最短パスを生成する必要があります。ドメイン内ルーティングのルーティングの柔軟性を高めるには、フラッディングされた近隣情報が必要ですが、ループのない任意のパス計算が可能なリンク ステートの方が良いオプションです。AS がドメイン間ルーティングで個別のポリシー制御を強制できるようにするために、明示的なパス情報を交換してループを回避できます。L2 で動的なフラッディングとルート学習を実装するには、ネットワーク トポロジ グラフは本質的に非循環であるため、ネットワーク トポロジ グラフをスパニング ツリーに変換する必要があります。ルートを再計算せずに障害から回復する方法や、集中制御を使用して SDN などのルーティング プロトコルを簡素化する方法など、ルーティングでは他の問題も考慮される可能性がありますが、ここでのポイントは、一般的に使用されるルーティングでのループを回避する方法を説明することです。パラダイム、道路の役割。
3.2 確実な伝送
ルーティング分析について説明する場合、ルーティング ステータスが有効であっても、リンクの過負荷やルータの障害によりパケットがドロップされる可能性があります。インターネット アーキテクチャでは、最初の 3 つの層の信頼性は保証されていませんが、このタスクはトランスポート層またはアプリケーション自体に委ねられており、失われたパケットは送信ホストによって再送信された場合にのみ送信されます。
信頼性の高い伝送は、1 つのアプリケーションからデータを取得してリモート アプリケーションに転送するための接続を確立するトランスポート プロトコルによって保証されます。広く使用されている TCP などの一部の重要なトランスポート プロトコルは、信頼性の高いバイト ストリームの抽象化を提供します。この抽象化では、バイト ストリーム内のデータがパケットに分割されて順次送信され、すべてのパケット損失はトランスポート プロトコル自体によって回復されます。信頼性の高いバイト ストリームの抽象化は、ホスト ソフトウェアによって完全に実装できます。ホスト ソフトウェアは、パケットにシーケンス番号を付けることで、あるバイト ストリームのパケットを別のバイト ストリームのパケットから区別できます。これにより、パケットは、次へのデータ配信に使用できます。 受信アプリケーションは正しく並べ替えられます。そしてパケットが正常に配信されるまで再送信します。
非公式には、信頼できるトランスポート プロトコルはアプリケーションからデータを取得し、それをパケットの形式で宛先に送信し、最終的には転送が正常に完了したか失敗して終了したかをアプリケーションに通知し、どちらの場合もそれ以上の転送を停止します。基礎となるネットワークが最終的に複製されたパケットを配信するため、永続化プロトコルは常に成功すると仮定します。この場合、すべてのパケットが受信された場合に限り、プロトコルがアプリケーションに成功を通知できるようにするには、送信者と受信者の間でどのような通信が必要ですか? 一般的なアプローチは 2 つあります。1 つは、パケットを受信したときに受信者が送信者に確認応答 (ACK) を送信するか、パケットが失われた可能性がある場合に非確認応答 (NACK) を送信することです。
ACK は信頼性の高い送信に必要かつ十分ですが、NACK は必要でも十分でもありません。信頼できるトランスポート プロトコルは、すべてのパケットが送信されたことがわかっている場合にのみ成功を宣言できます。これは、各パケットの ACK を受信することによってのみ推測できます。NACK (それ自体は削除可能) がないことは、パケットが受信されたことを意味しません。ただし、NACK は、送信者がいつ再送信すべきかに関するタイムリーな情報を提供できるため、便利です。たとえば、TCP は信頼性を向上させるために明示的な ACK を使用し、タイムアウトと暗黙的な NACK (予期された ACK が到着しない場合) に基づいて再送信を開始します。
3.3 名前解決
ARP を介して IP アドレスを MAC アドレスに解決することに加えて、インターネットはアプリケーション レベルの名前を 1 つ以上の IP アドレスに解決する必要もあります。これらの名前は非公式にはホスト名と呼ばれ、正式には完全修飾ドメイン名として知られています。アプリケーション レベルの名前には、MAC アドレスのように特定の物理マシンを参照したり、ドメイン間ルーティングで使用されるドメインの概念に直接関連したりしない、非標準の用語を使用できます。
アプリケーションレベルの命名システムは次のことを行う必要があります。
各名前の管理制御を、その名前がどの IP アドレスに解決されるかを決定する一意の権限に割り当てます。
高解像度のリクエストを処理します。
どちらのプロパティも、数十億のアプリケーション レベルの名前の規模で提供されます。
これらの課題に対処するために、インターネットはドメイン ネーム システム (DNS) と呼ばれる階層的な名前付け構造を採用しています。名前空間はドメインと呼ばれる領域に分割され、再帰的にさらに小さなドメインに分割され、解決と管理制御の両方が階層的に行われます。各名前付きドメインには 1 つ以上のネーム サーバーがあり、新しいサブドメインを作成し、そのドメイン内で名前を解決できます。名前は 1 つ以上の IP アドレスに完全に解決することも、そのような名前をさらに解決できる 1 つ以上のサブドメイン ネーム サーバーに解決を向けることもできます。この階層は一連のトップレベル ドメイン (TLD) から始まり、商用登録により、顧客はこれらの TLD の下にサブドメインを登録できます。TLD のネーム サーバーへの解決は、一連の DNS ルート サーバー (そのアドレスはすべてのホストに知られている) によって処理され、そこから命名階層に沿って解決が進められます。たとえば、www.myschool.edu は最初にルート サーバーによって解決され、ルート サーバーは edu ネーム サーバーを指し、次にルート サーバーは myschool.edu のネーム サーバーを指し、次に www.myschool.edu を IP アドレスに解決します。この階層により、高度な並列名前解決と完全に分散された管理制御が可能になり、どちらもインターネットの名前付けの規模を処理するために重要です。
4. インターネットでの成功の秘訣
この記事では、インターネットの理解しがたい複雑さを、いくつかの設計上の選択肢に落とし込むことを試みます。
サービスモデル
4層アーキテクチャ
3 つの主要なメカニズム (ルーティング、信頼性、解像度)
これらの決定の背後にある理由を理解するだけでは、今日のインターネットの複雑さを理解するのに十分ではありませんが、ほぼ同じ特性を持つ新しいインターネットを設計するのには十分です。残念ながら、この単純さだけではインターネットの長寿を説明するのに十分ではありません。なぜインターネットの設計は、速度、規模、範囲、テクノロジー、および使用法における大きな変化にうまく対処できたのでしょうか?
4.1 素朴
インターネットは、考えられるすべてのアプリケーション要件を満たそうとする代わりに、非常に限定的ではあるものの、保証のない非常に一般的なサービス モデルを採用しています。したがって、スマート デバイスと非スマート ネットワークの場合は次のようになります。
インターネットは特定のアプリケーションのニーズに合わせてカスタマイズされていないため、新しいアプリケーションの繁栄が可能になります。
さまざまな方法 (レート適応、バッファリング、再送信など) で最適なインターネット サービスの変動に適応するホストの能力を活用します。
ネットワーク速度を迅速に向上させることができ、サービス モデルは比較的シンプルです。
インターネットがより複雑なサービス モデルを採用した場合、インターネットはその作成時に存在していたアプリケーション要件に限定され、その時点で利用可能なテクノロジで実装できる可能性があります。その結果、少数のアプリケーション向けに複雑に設計されたテクノロジーがすぐに陳腐化し、短期的には成功しても長期的には失敗することになります。
4.2 モジュール化
4 層インターネット アーキテクチャのモジュール性により、責任が明確に分割されます。ネットワーク インフラストラクチャ (L1/L2/L3) は、(容量、カバレッジ、復元力の点で) より優れたパケット配信をサポートし、アプリケーションは (L4 によって支援されます)このパケット配信サービス モデルに基づいて、ユーザー向けの新しい機能を作成します。したがって、このアーキテクチャにより、ネットワーク インフラストラクチャとインターネット アプリケーションという 2 つの異なるエコシステムが独立して繁栄することが可能になります。
ただし、インターネットのモジュール性は、電話ネットワークのより厳密な適合性とは対照的に、その形式的なアーキテクチャを超えて、標準主導のインフラストラクチャ内で自律性へのより一般的なアプローチを最大化します。たとえば、AS の唯一の要件は、そのルーターが IP をサポートし、ドメイン間ルーティング プロトコル BGP に参加していることです。それ以外の場合、各システムは、他のシステムと調整することなく、任意の L1 および L2 テクノロジーと任意のドメイン内ルーティング プロトコルを展開できます。同様に、個々の名前ドメインは DNS プロトコルをサポートする必要があります。サポートしていない場合は、任意の名前管理戦略と名前解決インフラストラクチャを選択できます。このインフラストラクチャの自律性により、さまざまな運用慣行の出現が可能になります。たとえば、大学のキャンパス ネットワーク、ハイパースケール データ センター ネットワーク、および ISP バックボーン ネットワークには、運用上のニーズが大きく異なりますが、インターネット本来の自律性により、それぞれのニーズを独自の方法で満たすことができ、時間の経過とともに発展していきます。
4.3 失敗はよくあること
システムのサイズが大きくなるにつれて、システムの一部のコンポーネントに障害が発生する可能性が高くなります。したがって、アルゴリズムの複雑さまたは状態爆発の観点からスケーリングがよく考えられますが、障害を効率的に処理することも重要なスケーラビリティ要件です。正常に動作し、障害から回復するために特別なモードに入ることが期待されるシステムとは異なり、ほぼすべてのインターネット メカニズムは障害を一般的なイベントとして扱います。
たとえば、基本的なルーティング アルゴリズムでは、リンク障害によるものでも、ループの再計算によるものでも、同じ方法でルートが計算されます。同様に、パケットが失われた場合は再送信する必要がありますが、そのような再送信は頻繁に発生することが予想され、トランスポート プロトコルでは特別なケースではありません。失敗をよくあるケースとして扱うこの設計スタイルは、Google などでハイパースケール インフラストラクチャを構築するための基礎となっており、もともとインターネットで開拓されたスタイルです。
4.4 大まかな合意と実行可能なコード
インターネットの発明者らは、当時電気通信業界で一般的だった正式な設計委員会を採用するのではなく、明らかに別の道を選択しました。それは、より小さなグループに実行可能な設計を構築するよう奨励し、コミュニティにどの設計を採用するかを選択させるというものでした。インターネット アーキテクチャのリーダーの 1 人であるデイビッド クラーク氏はスピーチで次のように述べています:「私たちは国王、大統領、投票を拒否します。私たちは大まかな合意と実用的なコードを信じています。」 この平等主義の精神は、接続としてのインターネットにも拡張されています。すべてのユーザーのためのユニファイド コミュニケーション プラットフォーム。このように、インターネットの発展は、純粋に技術的な決定だけでなく、世界をつなぐ共有プラットフォームの価値に対する初期のインターネット コミュニティの信念と、このビジョンを実現するための共有所有権によっても形作られました。
5. 完璧などというものはない
インターネットの設計が次善のソリューションである領域は数多くありますが、そのほとんどは低レベルの詳細であり、高レベルの表現は変わりません。インターネット設計には、より根本的な問題が存在する領域が 3 つあります。
5.1 セキュリティ
障害が発生した場合に障害に対処する能力は確かに重要な考慮事項であるにもかかわらず、インターネット セキュリティの貧弱な状態をセキュリティのせいにして、インターネットの設計においてセキュリティが主要な考慮事項ではなかったと主張する人が多くいます。この批判は次の 2 つの理由から見当違いです。
(1) 相互接続された世界では、セキュリティはサイバーセキュリティよりも複雑でとらえどころのない目標であり、インターネットは後者のみを保証できます。
(2) インターネット アーキテクチャ自体はネットワーク セキュリティを提供しませんが、これらのセキュリティを大幅に実現できるプロトコルとテクノロジがあり、その一部は広く使用されています。
より正確には、2 つのホスト間でデータを送信するときに次の特性が保証される場合、ネットワークは安全であると言えます。
ホスト間の接続は適度に信頼性があります (可用性)。
受信者はデータの出所を知ることができます。
データの完全性は送信中に改ざんされていません）。
データは仲介者によって読み取られることはなく、誰もリンクを覗き見せず、どのホストがパケットを交換しているかを知りません (プライバシー)。
後者の 3 つは通常、暗号化プロトコルを通じて保証できます。インターネットの可用性は、分散型サービス拒否 (DDoS) 攻撃に対して脆弱です。DDoS 攻撃では、多くのホストがボットとして使用され、ターゲットにトラフィックを過負荷にしてしまいます。この攻撃的なトラフィックをフィルタリングする技術はありますが、効果は部分的にしかありません。AS のルーティングが脆弱なため、BGP が脆弱であることによって可用性も脅かされており、暗号化ソリューションは利用可能ですが、広く導入されていません。したがって、インターネットが安全なネットワークの定義をかなりの程度満たすことを可能にする暗号化プロトコルと緩和方法が存在します。
ただし、インターネットを本質的に安全なネットワークにすることができないことが、現在のセキュリティ問題の主な原因ではないことは明らかであり、安全なネットワークはホスト ソフトウェアの安全性の低下を防ぐことはできません。たとえば、アプリケーションがユーザーに関する情報を漏洩したり、ユーザーになりすまして不必要な金融取引を実行したりするように設計されている場合、ネットワークがこの悪意のある動作を阻止するためにできることはほとんどありません。ユーザーが誤って悪意のあるアプリケーションをダウンロードした場合、または何らかの攻撃 (バッファ オーバーフローなど) によって無害なアプリケーションが悪意のあるアプリケーションに変わった場合、ホストが感染する可能性があります。インターネット セキュリティに関する批判は、マルウェアをホストに簡単に配置できることを指摘することがよくありますが、これは主にサイバーセキュリティの問題ではありません。
5.2 ネットワーク内のパケット処理
初期のインターネット設計者は、ネットワーク インフラストラクチャは一般にパケット送信に重点を置き、高レベルの機能を避ける必要があると考えていましたが、現在運用されているほぼすべてのネットワークが、いわゆるネットワーク内パケット処理のルールに違反しています。最新のネットワークには、ファイアウォール (ネットワークに入るパケットの制御)、WAN の最適化 (以前のデータをキャッシュすることでネットワークの効率を向上)、負荷分散 (要求を負荷の低いホストに誘導する) など、単なるトランスポート以上のものを提供する多くの中間点があります。
2012 年の調査によると、ネットワーク コンポーネントの約 3 分の 1 がミドルウェア、3 分の 1 がルーター、そして 3 分の 1 がスイッチです。これらのネットワーク内処理機能の一部は、内部効率を向上させるために個々の企業内に導入されています。この動作は企業ネットワーク内でのみ影響を与えるため、許容可能な現実として広く認識されています。さらに、以下で説明するように、一部のクラウド プロバイダーやコンテンツ プロバイダーは、大規模なプライベート ネットワークを展開し、ネットワーク内機能 (特にスロットリング、キャッシュ、負荷分散) を展開して、遅延を削減し、顧客から見える信頼性を向上させています。
5.3 進化能力の欠如
すべてのルーターは IP プロトコルを実装しているため、インターネットのサービス モデルを変更するのは困難です。最近、IPv4 アドレスの不足により IPv6 への移行が加速している間も、同じサービス モデルが維持されています。何十年もの間、インターネットには大きなアーキテクチャ上の変更はなく、インターネットに代わる実現可能なものはありません。ただし、集中管理されたデータ センターに展開された大規模なプライベート ネットワークは、ネットワーク内処理を通じて顧客に優れたサービスを提供します。今日のほとんどのクライアント トラフィックは、ローカル コントロール センターを通じて元の AS サービスをキャッシュするか、ソース AS から直接使用して、大規模なサービスを提供します。プライベート ネットワーク内の処理センターのプライベート ネットワーク。中央コントロール センターからの大規模なプライベート ネットワークは、現在 ISP よりも経済的に支配的な勢力となっているクラウドおよびコンテンツ サービスと垂直統合されています。
したがって、新しいグローバル インフラストラクチャへの移行が見られ始めています。これらのプライベート ネットワークは、現在のインターネット上のほぼすべてのトラフィックのラスト マイルに取って代わりました。これは、実質的な競争相手が存在しなかったインターネット経済の時代の終わりを告げることになります。インターネットは多くの課題に直面していますが、初期のインターネット コミュニティを活気づけた 2 つのビジョン、つまりすべてのユーザーを接続する統一インターネット、本質的にエンドポイントによって提供されるサービスから切り離された代替インターネット、の 2 つのビジョン間の違いを解決することほど、インターネットの将来にとって重要なことはありません。このビジョンは、ネットワーク内処理を使用することでパフォーマンスが向上する、新興の大規模プライベート ネットワークによって代表されています。
6. 一文の要約
インターネットは、非常に大胆で先見の明のある設計上の決定を具体化したエンジニアリングの驚異です。インターネットの複雑さによって、その中心となる設計と成果の単純さが影を落とさないようにし、その創設につながった勇気、コミュニティの精神、ビジョンを忘れないでください。これはおそらく、インターネットのより価値のある側面の 1 つです。 。
追伸：これまでベテランプログラマーが読んできたコンピュータネットワーク関連書籍の中で、本書『コンピュータネットワークの問題と解決策』が最も分かりやすく解説されており、ITエンジニアのみならず、特にITエンジニアとして活用できる本です。ネットワーク エンジニア。エンジニアのデスク マニュアルは、システム アーキテクトやソフトウェア エンジニアにとっても、ネットワーク アーキテクチャとインフラストラクチャがソフトウェア システムに及ぼす影響を理解するのに非常に役立ちます。このマニュアルは 20 年以内に価値が減ることはなく、マニュアルを明確に理解して適用することができます。私たちの周りのコンピュータネットワーク。
【関連読書】