|
次のページ
前のページ
目次へ
11. ネットワーク
ネットワーキングと Linux とはほとんど同義語である。本当の意味で、Linux は インターネットもしくは World Wide Web(WWW) の産物である。開発者やユーザたち はウェブを使って情報やアイデアやコードを交換しているし、Linux そのものが組織に おけるネットワークへの要求を満たすために利用されている。この章では、TCP/IP と 総称されるネットワークプロトコルを Linux がどのようにサポートしているかを 解説する。
TCP/IP プロトコルが設計されたのは、ARPANET に接続されたコンピュータ間 での通信をサポートするためであった。合衆国政府によって設立されたアメリカ の研究用ネットワークである ARPANET は、ネットワークの基本概念を作り出した パイオニアであり、その中には、パケットスイッチング(packet switching)や、ある プロトコルが別のプロトコルのサービスを利用するというプロトコル層(protocol layer)といった概念がある。 ARPANET は 1988 年に解散されたが、その後継者(NSF( 脚注 1) NET やインターネット)はそれ以上のものに成長した。 今日 World Wide Web と呼ばれるものは、ARPANET から発展しており、それ自体が TCP/IP プロトコルによってサポートされている。Unix は ARPANET 上で広範囲に 使用されが、最初にリリースされたネットワークバージョンの Unix は 4.3 BSD であった。Linux におけるネットワークの実装は、(いくつかの拡張機能とともに)BSD ソケットと TCP/IP 全般をサポートしている点で、4.3 BSD をモデルとするものであ る。BSD ソケットというプログラミングインターフェイスが 採用されたのは、その人気ゆえであり、Linux とその他の Unix プラットフォーム間 でのアプリケーションの移植を容易にするためであった。
11.1 TCP/IP ネットワーキングの概要この章では、TCP/IP ネットワーキングにおける基本原則を概説する。 しかし、本書のテーマからして、徹底した記述というわけではない。 IP ネットワークでは、すべてのマシンが IP アドレスを割り当てられる。これはマシン をユニークに識別する 32 ビットの数である。WWW は広大で今も成長過程にあり、そ れに接続された IP ネットワークとすべてのマシンはユニークな IP アドレスを割り当 てられなければならない。 IP アドレスは、たとえば 16.42.0.9 のようにドットで区切られた 4 つの 数字で表現される。この IP アドレスは実際には、ネットワークアドレスとホスト アドレスのふたつの部分に分かれる。( IP アドレスにはいくつかのクラスがあるので) それらの部分のサイズは定まっていないが、仮に 16.42.0.9 を例に取り、ネットワー クアドレスを 16.42 とし、ホストアドレスを 0.9 であるとする。ホストアドレスは さらにサブネットとホストアドレスとに再分割できる。ここでも 16.42.0.9 を例に 取ると、サブネットアドレスは 16.42.0 であり、ホストアドレスは 9 となるだろう。 IP アドレスの細分化により、組織はネットワークを再分割できる。 たとえば、16.42 が ACME コンピュータ会社のネットワークアドレスであるとすると、 16.42.0 はサブネット 0 であり、16.42.1 はサブネット 1 となる。これらのサブ ネットは、異なる建物の中にあり、おそらく専用線かもしくは無線によっ て接続されているだろう。IP アドレスはネットワーク管理者によって割り当てられる ので、IP サブネットを持つことはネットワーク管理を分散するよい方法である。IP サブネットの管理者は、その IP サブネットワーク内で自由に IP アドレスを割り当 てることができるからである。
しかし、一般的に IP アドレスは覚えるのがやや困難である。名前のほうがより
簡単であり、linux.acme.com のほうが 16.42.0.9 よりもずっと覚えやすい。だが、
ネットワーク名を IP アドレスに変換するには多少の仕組みが必要となる。そうした
名前は、
ウェブページを読む時などに他のマシンに接続する際はいつも、相手のマシンとの データ交換に IP アドレスが使用される。このデータは IP パケットに含まれていて、 個々のパケットは、送信元の IP アドレスと送信先の IP アドレス、チェックサム その他の情報を含んだ IP ヘッダを持っている。チェックサムは IP パケットの データから導き出されるもので、それによって、おそらく電話回線上のノイズなどで、 転送中に IP パケットが壊れなかったかどうかを IP パケットの受信者が判断できる ようになる。アプリケーションによって送信されるデータは、処理しやすいように、 より小さなパケットへと分割される。IP データパケットのサイズは接続 メディアによって異なり、イーサネットパケットは一般に PPP パケットよりも サイズが大きい。送信先のホストはそのデータパケットを組み立て直して、それを受信 すべきアプリケーションに渡さなければならない。多くのグラフィックイメージを 含むウェブページに比較的低速なシリアル回線経由でアクセスする場合、このデータ の分割と統合の過程を視覚的に理解することができる。
同一の IP サブネットに接続されたホスト間ではお互いに直接 IP パケットを送信 することができるが、それ以外のすべてのパケットは特別なホストであるゲートウェイ (gateway)に送信される。ゲートウェイ(あるいはルータ(router))は、複数の IP サブネットに接続されていて、あるサブネット上で受信した IP パケットが、別のサブ ネット宛であった場合に、その IP パケットを送信先に向けて送りなおす。 たとえば、サブネット 16.42.1.0 と 16.42.0.0 がゲートウェイに よって接続されている場合、サブネット 0 からサブネット 1 へと送信されるパケット は、ルーティングが可能なゲートウェイに送られなければならない。ローカルホスト はルーティングテーブルを設定し、それによって正しいマシンに IP パケットを 経路付けすることができる。すべての IP の送信先に関して、ルーティングテーブル 内にひとつのエントリがある。Linux は、それを参照することで、どのホストに送れば よいかを判断して、IP パケットを宛先に届けている。 これらのルーティングテーブルは、複数のアプリケーションがネットワークを使用した り、ネットワークトポロジーが変更された場合など、時間の経過によって動的に変化す る。
図表(10.1) TCP/IP プロトコル層
IP(Internet Protocol) プロトコルは、他のプロトコルがデータを運ぶために利用
する、転送のための層(layer)である。TCP (Transmission Control Protocol)は、エン
ドシステム間における信頼性のあるプロトコルで、自己のパケットを送受信するために
IP を使用する。
IP が独自のヘッダを持つように、TCP も独自のヘッダを持つ。TCP はコネクション
(connection)に基づくプロトコルなので、両端のアプリケーションは、間に多くの
サブネットワークやゲートウェイ、ルータがある場合でも、単一の仮想的コネクション
によって接続される。TCP はふたつのアプリケーション間で信頼性をもってデータ
の受け渡しを行うので、データの喪失や重複が生じないことが保証される。TCP が IP
を利用してパケットを転送するとき、IP パケット内に含まれるデータは TCP パケット
そのものである。
個々の通信ホスト上で IP 層は、IP パケットの送受信に関して責任を持つ。
UDP (User Datagram Protocol)も IP 層を使用して自分のパケットを転送するが、
TCP と異なり、UDP は信頼性のあるプロトコルではなく、単にデータグラム(datagram)
サービスを提供するだけである。
このように、IP は、他のプロトコルによって利用されている。したがって、IP パケッ
トを受け取った際、受信した IP 層は、どの上位プロトコル層に対してその IP パケッ
トに含まれるデータを渡すべきか認識できなければならない。これを簡単に実現するた
めに、すべての IP ヘッダには、プロトコル識別子が記述された 1 バイトの情報があ
る。TCP が IP 層に IP パケットの送信を依頼するとき、IP パケットのヘッダには、
そのパケットが TCP パケットを含むものであることを伝える情報が記述される。
受信した IP 層は、そのプロトコル識別子を使用して、どの上位層(この場合は、
TCP)に受信したデータを渡すべきかを判断する。
また、アプリケーションが TCP/IP 経由で通信を行うとき、それらは相手方の IP アド
レスだけでなく、アプリケーションのポート番号をも指定しなければならない。
ポート番号はアプリケーションをユニークに特定するものであり、標準的なネット
ワークアプリケーションは標準のポート番号を使用する。たとえば、ウェブサーバは
80 番ポートを使用している。これら登録済みのポート番号は、
このようなプロトコルの多層構造は、TCP, UDP や IP だけに留まらない。すなわ ち、IP プロトコル自身が様々な異なる物理メディアを使用して IP パケットを他の IP ホストに転送している。したがって、それらの物理メディア自体も独自のプロトコル ヘッダを付け加えている。イーサネット層がその一例であり、他にも PPP 層や SLIP 層 などがある。イーサネットのネットワークでは、多くのホストを同時に単一の物理ケー ブルに接続することが可能である(訳注: 10BASE5 など。現在、単一の物理ケーブルが 使われることは少なくなりました)。送信されたイーサネットフレーム(frame)は、その ケーブルに接続されたすべてのホストから見ることが出来るので、個々のイーサネット デバイスはユニークな(ハードウェア)アドレスを持たなければならない。 特定の(ハードウェア)アドレスに対して送信されたイーサネットフレームはそのアドレ スのホストに受信され、ネットワークに接続されたそれ以外のすべてのホストからは無 視される。こうしたユニークなアドレスはイーサネットデバイスの製造時にデバイスに 組み込まれていて、通常、イーサネットカードの SROM( 脚注2) に保存されている。 イーサネットのアドレスは 6 バイト長で、たとえば、08-00-2B-00-49-A4 といったもの になっている。イーサネットのアドレスにはマルチキャスト( 訳注: 用語集(multicast))の目的に予約されたものがあり、そうした送信先 アドレスを設定されて送信されたイーサネットフレームは、そのネットワーク上のすべ てのホストで受信される。 イーサネットフレームは、多種のプロトコルを(データとして)運ぶことができるので、 IP パケットの場合と同様に、イーサネットフレームのヘッダにはプロトコル識別子が 含まれている。これによって、イーサネット層は IP パケットを正確に受信して、それ を IP 層に渡すことができる。
イーサネットのような(ケーブルに繋がったすべてのホストにフレームが流れる) マルチコネクションのプロトコル経由で IP パケットを送信するためには、IP 層は、 IP ホストのイーサネットアドレスを知らなければならない。というのも、IP アドレス は単にアドレス割り当ての概念にすぎず、イーサネットデバイス自体が独自の物理 アドレスを持っているからである。すなわち、IP アドレスはネットワーク管理者の 意志によって割り当てや再割り当てが可能であるのだが、ネットワークハードウェア は、自分の物理アドレスが付加されたイーサネットフレームか、あるいはすべての マシンで受信すべき特別なマルチキャストアドレスにしか反応しないからである。 Linux は、ARP (Address Resolution Protocol)を使用して、マシンが、IP アドレスを イーサネットアドレスのような実際のハードウェアアドレスに変換できるようにしてい る。 ある IP アドレスに関連付けられたハードウェアアドレスを知ろうとするホストは、 変換したい IP アドレスを含めた ARP リクエストパケットを、マルチキャストアドレス を付けてネットワーク上のすべてのノード(node)に送信する。その IP アドレスを持つ ターゲットホスト(target host)は、自分の物理アドレスを含めた ARP リプライによっ てそれに応答する。ARP はイーサネットデバイスだけでしか利用できないわけではな く、 FDDI などのそれ以外の物理メディアに対しても IP アド レスの解決が可能である。 ARP が利用できないネットワークデバイスはそれが出来ない旨マークされているので、 その場合、Linux がARP を試すことはない。ARP の逆の機能も存在しており、リバース ARP もしくは RARP は、ハードウェアアドレスを IP アドレスに変換する。これは ゲートウェイによって利用されるもので、ゲートウェイは、リモートネットワークにあ る IP アドレスが書かれた ARP リクエストに応答する際にそれを使用する。
11.2 Linux の TCP/IP ネットワーク層
図表(10.2) Linux のネットワーク層
ネットワークプロトコル自体が多層構造を持つのと同様に、図表(10.2)では、Linux
がインターネットプロトコルアドレスファミリ(address family)をソフトウェアの多層
構造として実装していることが示されている。BSD ソケットは、BSD ソケットだけに関
する汎用のソケット管理ソフトウェアとしてサポートされている。
BSD ソケットをサポートするのが INET ソケット層で、これは、IP ベースの TCP や
UDP プロトコルのためのエンドポイント通信を管理する。
UDP(User Datagram Protocol)はコネクション管理を行わないプロトコル
であるが、TCP(Transmission Control Protocol)は信頼性のある一対一(end to end)の
プロトコルである。UDP パケットが送信されるとき、Linux はそれが安全に送信先に
届いたかどうか分からないし、気にもしない。TCP パケットは番号付けされている
ので、TCP コネクションの両方のエンド(end, 端)は、送信されたデータが正しく受信さ
れたかどうかを確認できる。
IP 層には、インターネットプロトコル(IP)を処理するためのコードが含まれている。
このコードは、受信したデータの IP ヘッダを取得し、その IP パケットが TCP か
UDP のどちらかの上位層に宛てたものかを判断して、適切な上位層にルーティングす
る。IP 層の下で Linux のネットワーキングをサポートしているのが、PPP やイーサ
ネットといったネットワークデバイスである。ネットワークデバイスとは必ずしも物理
デバイスを意味するものではない。ループバックデバイス(loopback device)などは純粋
なソフトウェアデバイスだからである。
11.3 BSD ソケットインターフェイスBSD ソケットインターフェイスは、汎用インターフェイスであり、ネットワークの 様々な形態をサポートするだけでなく、プロセス間通信の仕組みでもある。 ソケットは通信リンクの一方のエンド(end, 端)を記述するもので、ふたつの通信プロセ スが個別にソケットを持ち、両者の間の通信リンクのそれぞれのエンドを記述する。 ソケットはパイプの特殊なケースであると考えることも可能だが、パイプと異なり、 ソケットは保持できるデータ容量に制限がない。Linux は、いくつかのソケットクラス (socket class)をサポートしており、それらはアドレスファミリ(address family)と 呼ばれている。これは、個々のクラスが独自の通信方式を持っているからである。 Linux は次のようなアドレスファミリもしくはドメイン(domain)をサポートしている。
アドレスファミリもしくはドメインには、いくつかのソケットタイプ(socket type) があり、それらはコネクションをサポートするサービスのタイプを表している。 すべてのサービスタイプをサポートしていないアドレスファミリもある。 Linux BSD ソケットは次のいくつかのソケットタイプをサポートしている。
ソケットを利用して通信を行うプロセスは、クライアントサーバモデル(client
server model)を使用する。
サーバはサービスを提供し、クライアントがそのサービスを利用する。その典型が
ウェブサーバであり、サーバがウェブページを提供し、クライアント、もしくは
ブラウザがそのページを読み出す。ソケットを使うサーバは、まずソケットを作成
し、それに名前を結びつける(bind)。その名前のフォーマットはそのソケットの
アドレスファミリに依存し、事実上サーバのローカルアドレスになる。ソケットの
名前もしくはアドレスは、
BSD ソケット上での操作が厳密に何を意味するかは、その基礎となるアドレス ファミリによって異なる。TCP/IP コネクションの設定は、アマチュア無線 X.25 コネクションの設定とは非常に異なる。仮想ファイルシステムの場合のように、Linux は、BSD ソケット層(layer)を使ってソケットインターフェイスを抽象化している。 BSD ソケット層側は、アプリケーションプログラムに対する BSD ソケットインター フェイスと関係付けられ、アプリケーション側は、アドレスファミリごとに独立した 固有のソフトウェアによりサポートされている。 カーネルに組み込まれたアドレスファミリは、カーネルの初期化時に、BSD ソケット インターフェイスと伴に登録される。その後、アプリケーションが BSD ソケットを 作成して使用する場合、BSD ソケットとそれがサポートするアドレスファミリとの 間で関連付けがなされる。この関連付けは、データ構造体とアドレスファミリ固有の サポートルーチンとをクロスリンクすることにより実現される。 たとえば、アドレスファミリ固有のソケット作成ルーチンがある場合、アプリケー ションが新規にソケットを作成しようとする際には、BSD ソケットインターフェイス は、そのルーチンを使用してソケットを作成する。
一般に、カーネル設定の際には、いくつものアドレスファミリとプロトコルが
ビルドされ、
図表(10.3) Linux BSD ソケットデータ構造体
11.4 INET ソケット層INET ソケット層は、TCP/IP を含むインターネットアドレスファミリをサポート
するものである。上記で説明したように、これらのプロトコルは多層構造になってい
て、ひとつのプロトコルが別のプロトコルのサービスを利用する。
Linux の TCP/IP のコードとデータ構造はその多層構造を反映している。BSD ソケット
層に対する INET ソケット層のインターフェイスは、一連のインターネットアドレス
ファミリのソケット操作ルーチンを経由するものであり、Linux は、ネットワークの
初期化時にそれらのルーチンを BSD ソケット層と伴に登録する。
それらは、登録された他のアドレスファミリと一緒に
BSD ソケットの作成システムコールで新規ソケットを作成する際は、アドレスファミリ、ソケットタイ
プ、プロトコルに関する識別子を渡す。
新規に作成された BSD
未使用のファイル記述子が、カレントプロセスの
アドレスを INET BSD ソケットに bind する入って来るインターネットコネクションリクエストを待機(listen)するためには、
個々のサーバが INET BSD ソケットを作成して、それにアドレスを結びつけ(bind)
なければ
ならない。bind 操作の大部分は、その基礎にある TCP と UDP プロトコル層の
サポートを受けた INET ソケット層内部で処理される。アドレスを結びつけ(bind)ら
れた
ソケットは、それ以外の通信には使用できない。これは、ソケットの状態(state)が
TCP_CLOSE でなければならないことを意味する。
パケットが基礎となるネットワークデバイスで受信されると、パケットは正しい
INET ソケットと BSD ソケットへと伝達されて、処理されなければならない。
そのために、UDP と TCP は、ハッシュテーブルを管理していて、それを使って、到着
した IP パケット内にあるアドレスを問い合わせて、正しい
UDP は、割り当てられた UDP ポートを
TCP は、複数のハッシュテーブルを管理しているので、UDP よりずっと複雑である。
しかし、TCP は、bind 操作をする間、実際に bind すべき REVIEW NOTE: What about the route entered?
INET BSD ソケット上でコネクションを確立するソケットが作成されると、そのソケットは、相手側からの(inbound)コネクション リクエストを待機(listen)するために使用されていない限り、自己側からの(outbound) コネクションリクエストのために使用できる。 UDP のようなコネクションレスのプロトコルの場合、このソケット操作は限定された 意味しか持たないのだが、TCP のようなコネクション指向のプロトコルの場合だと、 それはふたつのアプリケーション間で仮想サーキットを構築することを意味する。
自己側からの(outbound)コネクションリクエストが可能となるのは、INET BSD
ソケットを使用し、しかも使用する INET BSD ソケットが適切な状態(state)にある
場合だけである。
すなわち、そのソケット上で既にコネクションが確立していないこと、およびそれが
相手側からの(inbound)コネクションリクエストの待機のために使用されていない
場合である。
これは、BSD
TCP BSD ソケット上での connect 操作の場合、TCP は、コネクション情報を含んだ
TCP セグメント(segment)を作成して、指定された IP 送信先に送らなければならない。
TCP セグメントには、コネクション情報、開始セグメントのシーケンス番号(sequence
number)、接続を開始したホスト側が処理できるセグメントの最大サイズ(maximum
segment size, MSS)、送信および受信の際のウィンドウサイズ(window size)、等が含
まれる。
TCP では、すべてのセグメントに番号が付けられるので、シーケンス番号の初期値に
は、最初のセグメントの番号が利用される。Linux は、悪意のあるアタックを防ぐため
に、妥当な範囲の乱数値を選択している。TCP コネクションの一方から送信され、相手
側で問題なく受信されたセグメントに対してはすべて、データ破損なく成功裡に到達し
た旨の送達確認(acknowledgement)がなされる。送達確認のないセグメントは再送され
る。送信と受信のウィンドウサイズとは、送達確認が送信されないまま存在しうる未解
決セグメントの数である。最大セグメントサイズは、コネクションリクエストを発信し
た側で使用されているネットワークデバイスに依存する。受信側のネットワークデバイ
スがそれよりも小さい最大セグメントサイズしかサポートしていない場合、そのコネク
ションは小さい方を使用する。
自己側からの(outbound) TCP コネクションリクエストを発したアプリケーションは、
相手側アプリケーションがコネクションリクエストを受け入れ(accept)るか拒絶(
reject)するかを返答してくるまで待たなければならない。
その場合、TCP ソケットは相手側からのメッセージを期待しているので、そのソケット
は
INET BSD ソケット上での待機(listen)ソケットにアドレスが結びつけ(bind)られると、そのソケットは、結びつけ(bind) られたアドレスを指定した入ってくるコネクションリクエストを待機する(listen)。 ネットワークアプリケーションは、予めソケットにアドレスを結びつけ(bind)なくて もそのソケット上で待つことができる。 その場合、INET ソケット層が(そのプロトコルに関して)未使用なポート番号を探して、 自動的にそのソケットに結びつけ(bind)る。ソケット関数 listen は、ソケット状態 (state)を TCP_LISTEN 状態へと変更し、入って来る接続を許可するために必要とされ るそのネットワーク固有のすべての処理を行う。
UDP ソケットの場合、ソケット状態の変更で充分だが、TCP は、その際、アクティ
ブとなったことで、ソケットの
入って来る(incoming) TCP コネクションリクエストがアクティブな待機中
(listening)のソケットで受信されたときはいつも、TCP は、それを表す新規の
コネクション要求を受け入れる(accept)UDP はコネクションの概念をサポートしていないので、INET ソケット上でのコネク
ションリクエストの受け入れ(accept)は、TCP プロトコルだけに適用される。先ず、
待機(listen)状態のソケット上の accept 操作ルーチンは、その
11.5 IP 層
ソケットバッファ(socket buffer)個々の層が他層のサービスを利用するという、多層構造のネットワークプロトコル
を持つことの問題点は、個々のプロトコルが、送信の際にはヘッダ(header)とテイル
(tail)をデータに付加し、受信データの処理の際にはそれを削除するといった操作が
必要になることである。
個々の層は自分のプロトコルヘッダとテイルがどこにあるのか探す
必要があるので、このことがプロトコル間でのデータバッファの受け渡しを
むずかしくしている。
個々の層でバッファをコピーすることはひとつの解決策であるが、それでは
非効率である。そこで、Linux は、ソケットバッファもしくは
図表(10.4) ソケットバッファ (sk_buff)
図表(10.4)は、
IP パケットの受信
「デバイスドライバ」の章では、Linux の
ネットワークドライバがカーネルに組み込まれて、初期化される方法を説明した。
それによって、一連の
ネットワークボトムハーフハンドラがスケジューラによって実行されるとき、
そのハンドラは、まず送信待ちになっているネットワークパケットをすべて処理
した後に、どのプロトコル層に受信したパケットを渡すか判断して、
IP パケットの送信パケットは、データ交換をしようとするアプリケーションによって送信される他に、
確立されたコネクションを維持したりコネクションを確立したりするときに、
ネットワークプロトコルによって生成される。しかし、データの生成方法が
どのようなものであっても、そのデータを保持するために
送信されるすべての IP パケットについては、IP がルーティングテーブルを使用
して送信先の IP アドレスに対するルートの解決をする。ルーティングテーブル内で
の個々の IP 送信先の問い合わせが成功した場合、使用すべきルートを示した
データの細分化(fragmentation)すべてのネットワークデバイスには最大パケットサイズ(maximum packet size)が あり、それより大きなデータパケットは送信も受信もできない。IP プロトコルはこれに 対処しており、データを小さな断片(fragment)に分割することで、ネットワーク デバイスが処理できるパケットサイズに合わせるようになっている。 IP プロトコルヘッダにはフラグメント(fragment)フィールドがあり、そこにはフラグ (flag)とフラグメントオフセット(fragment offset)が含まれている。
IP パケットの送信準備ができたとき、IP はそのパケットを外に送信するネット
ワークデバイスを探す。そのデバイスは IP ルーティングテーブルで見つかる。
IP フラグメントの受信は、その送信よりもやや面倒である。IP フラグメントは、
順序ばらばらに受信されるかもしれず、それらすべてが受信されてから組み立て直す
必要があるからである。
11.6 Address Resolution Protocol (ARP)ARP(Address Resolution Protocol)の役割は、IP アドレスをイーサネットアドレス
のような物理的なハードウェアのアドレスへと変換することである。IP がこの変換
を必要とするのは、送信のために(
ARP プロトコルそのものは非常にシンプルであり、ARP リクエスト(要求、request) と ARP リプライ(応答、reply)のふたつのタイプのメッセージから成っている。 ARP リクエストには、変換に必要な IP アドレスが含まれ、応答には(上手くいけば) その IP の変換後のアドレスであるハードウェアアドレスが含まれる。ARP リクエスト は、ネットワークに接続されたすべてのホストにブロードキャストされるので、ある イーサネットネットワークにおいては、そのイーサネットに繋がるすべてのマシンが ARP リクエストを見ることになる。 要求された IP アドレスを所有するマシンがその ARP リクエストに応答し、 自分の物理アドレスを含めた ARP リプライを返す。
Linux 上の ARP プロトコル層は
ARP テーブルは、ポインタテーブル(
IP アドレス変換が要求されたが、適合する
ARP プロトコル層は、自身の IP アドレスを指定した ARP リクエストに対する応答
(respond)もしなければならない。ARP は、物理層の ARP リクエストのプロトコル
タイプ(ETH_P_ARP)を登録し、
ネットワークトポロジーは時間の経過によって変化することがあるので、IP アドレ
スが以前と異なるハードウェアアドレスに割り当てられることがある。たとえば、
ダイヤルアップサービスの中には、個々のコネクションが確立した時点で IP アドレス
を割り当てるものがある。ARP テーブルが最新の情報を保持するようにするために、
ARP は定期的に実行されて、
11.7 IP ルーティングIP ルーティング(経路づけ)機能は、特定の IP アドレス宛の IP パケットをどこに 送信すべき かを決定する。IP パケットを送信する際は多くの選択肢がある。送信先には到達 可能だろうか? 到達可能なら、送信のためにどのネットワークデバイスを 使用すべきか? 送信先に到達し得る利用可能なデバイスが複数ある場合、よりよい デバイスはどれか? IP ルーティングデータベースは、それらの疑問に答えるための 情報を管理する。ふたつのデータベースが存在するが、最も重要なのは、フォワーディ ング 情報データベース(Fowarding Information Database)である。 これは既知の IP 送信先とそこへの最良の経路を 漏れなく収めたリストである。それより小規模だが高速なデータベースとしてルート キャッシュ(route cache)があり、それは IP 送信先に関するすばやい経路問い合わ せのために使用される。 すべてのキャッシュと同様に、これには頻繁にアクセスされる経路しか含まれてお らず、その内容は、フォワーディング情報データベースから取り込まれたものである。
経路(route)は、BSD ソケットインターフェイスへの IOCTL リクエストを経由して 追加と削除がなされる。それらはプロトコルに渡されて、処理される。INET プロトコル層の場合、IP の経路の追加と削除ができるのは、スーパーユーザ権限を 持ったプロセスだけである。経路は固定することも可能であり、あるいは、時間の 経過によって動的に変更することも可能である。ルータ(router)(訳注: ルータとは、 ネットワークから他のネットワークに、他のシステムが送信したパケットを送り出す もの)でない限り、大部分の システムでは固定されたルートが使用されている。ルータはルーティングプロトコルを 実行して、それが既知の送信先の全 IP に対してルーティングできるよう常時チェック している。ルータでないシステムは、エンドシステム(end system)と呼ばれる。 ルーティングプロトコルは、たとえば GATED のようにデーモンとして実装されている が、それらも IOCTL BSD ソケットインターフェイス経由で経路を追加したり削除した りしている。
ルートキャッシュIP 経路の問い合わせがあるときはいつも、合致する経路がないか、まず ルートキャッシュがチェックされる。ルートキャッシュに合致する経路がない場合、 経路についてフォワーディング情報データベースが検索される。そこにも経路が 見つからない場合、IP パケットの送信は失敗し、アプリケーションにその旨通知が なされる。 フォワーディング情報データベースに該当する経路があり、ルートキャッシュに はない場合、新規のエントリが生成され、ルートキャッシュにその経路が付け加え られる。 ルートキャッシュは、
フォワーディング情報データベース(Forwarding Information Database)
図表(10.5) フォワーディング情報データベース
フォワーディング情報データベース(図表(10.5)参照)には、IP アドレスから見た、 その時点においてシステム上で利用可能な経路の一覧が含まれる。 それは非常に複雑なデータ構造をしていて、妥当な効率を得られるようアレンジされて はいるが、高速で問い合わせが可能なデータベースではない。 特に、送信されるべきすべての IP パケットについて送信先をこのデータベースに 問い合わせるとしたら、検索は非常に遅いものになるだろう。 ルートキャッシュが存在するのは、そのためである。既存の適切な経路を 使って IP パケットを高速に送信するわけである。ルートキャッシュはこの フォワーディング情報データベースから派生したもので、よく利用されるエントリを 表したものである。
個々の IP サブネットは
同一の IP サブネットに対していくつかの経路がある場合があり、それらの 経路は複数のゲートウェイのひとつを通過できる。IP ルーティング層は、 同一サブネットへの複数の経路が同じゲートウェイを使用することは許さない。 言い換えると、あるサブネットへの経路が複数ある場合、個々の経路は 必ず異なるゲートウェイを使用することが保証される。個々の経路に関連付けられ るのがメトリック(metric)である。これは、その経路がどれだけ最短に近いかを示す 指標である。経路のメトリックは、本質的には、宛先のサブネットに到達するまで に経由しなければならない IP サブネットの数である。メトリックが大きくなるに つれて、その経路は最短経路から遠くなる。
(脚注1) National Science Foundation
次のページ 前のページ 目次へ |
[ |