|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
インターネットがどないな仕組みで動いとるんか理解しやすくするために、 ここでは、典型的なインターネットの操作、すなわち、Linux Documentation Project のウェブページ上にあるこの文書の最初のページをブラウザ上で クリックした場合に、どないなことが起こっとるんかを概観しまひょ。 例あげたろか、たとえばやなあ、この文書は次の場所におます。
http://www.linuxdoc.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html |
上記は、LDP/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/index.html ちうファイルが www.linuxdoc.org ちうホストの World Wide Web についての公開ディレクトリ 上に置かれとるちうことを意味しまっせ。
ブラウザがまず初めにせなならへんことは、その文書が置かれた マシンとの間にネットワークコネクションを確立するっちうことや。それをするには、 第一に、そのホスト (host) である www.linuxdoc.org の あるネットワーク上の場所を探す必要がおます(ここで「ホスト」とは、 「ホストマシン」、もしくは「ネットワークホスト」の略や。 www.linuxdoc.org ちう名前は、ごく一般的な ホスト名 (hostname) や)。通信の際の場所の指定は、実際には、 IP アドレス (IP address) と呼ばれる番号が使用されはる(IP アドレスちう用語の IP の部分 については、後ほど説明します)。
IP アドレスを知るには、ブラウザは ネームサーバ (name server) と呼ばれるプログラムに問い合わせをしまっせ。ネームサーバはオノレのマシン上に あってもええねんが、たいていの場合は専用のマシン上で動いとるさかい、 それに問い合わせを送ることになっとりまんねん。ISP と契約したとき、 そのセットアップ手順のなかで、ISP のネットワーク上にある ネームサーバの IP アドレスを、手持ちのインターネットソフトウェアに指示する ちう手順がきっと含まれとったはずや。
異なるマシン上で動くネームサーバは、お互いに通信をし、ホスト名解決 (すなわち、ホスト名を IP アドレスに変換する処理) に必要なずぅぇえええぇぇええんぶの情報を交換しあい、つねに最新の状態に保っとりまんねん。 ネームサーバは、www.linuxdoc.org ちうホスト名解決の過程で三度か 四度ネットワークごしに存在する他のサイトに問い合わせをしまんねんけど、 こら通常どエライ高速に行われはる(一秒以下や)。ネームサーバの 詳細については、次章で概観しまっせ。
ネームサーバはブラウザに対して、www.linuxdoc.org の IP アドレスが 152.19.254.81 であることを教えまんねん。これを知ることによって、 読者のマシンは、www.linuxdoc.org との間で直接情報交換ができる ようになるんですわ。
プログラムとデータベースを連携させてホスト名を IP アドレスに変換する 仕組み全体は、DNS (Domain Name System) と呼ばれとりまんねん。"DNS サーバ" と呼ぶ場合、こら単に「ネームサーバ」と呼ぶのと同じ意味で使われはります。 ここでは、そのシステム全体の仕組みについて説明しまっせ。
インターネットのホスト名は、ドットで区切られはったいくつかの部分から 構成されとりまんねん。ドメイン (domain) とは、ホスト名の末尾部分が同一 であるマシンの集合のことや。ドメインは、他のドメインの内部にも 存在するっちうことができまんねん。例あげたろか、たとえばやなあ、www.linuxdoc.org ちうマシンは、 .org ちうドメインの中の .linuxdoc.org ちうサブドメインに 存在してるんや。
個々のドメインは、そのドメイン内のみなのマシンの IP アドレスを記憶して おる 権威あるネームサーバ (authoritative name server) によって規律されとりまんねん。権威ある(もしくは「プライマリ」) ネームサーバは、故障に備えてバックアップされとることもおます。 セカンダリネームサーバ (secondary name server) (もしくは、セカンダリ DNS) ちう記述がある場合、 そらそないなバックアップホストのことをぬかしておるわけや。 こないなセカンダリサーバ群は、通常、プライマリサーバから数時間ごとに 情報を受け取って更新してんねんさかい、プライマリサーバ上でホスト名 と IP との対応関係に変更が加えられはった場合は、なあんもせんとホッタラかしといてもそれが セカンダリ側にも伝えられはるようになっとりまんねん。
次の事柄はどエライ重要や。すなわち、あるドメインのネームサーバは、 他のドメイン(および、それら自身のサブドメイン)にあるずぅぇえええぇぇええんぶのマシンの位置を 知る必要はないということや。ネームサーバが知らなならへんんは、 他のネームサーバの位置だけや。先ほどの例では、.org ドメインの権威ある ネームサーバは、.linuxdoc.org の権威あるネームサーバの IP アドレスを 知っとりますが、linuxdoc.org 内にあるそれ以外のマシンのアドレスについて は知らしまへん。
DNS システム内のドメインは、巨木を逆さまにしたような階層構造を持つよう 配列されとりまんねん。頂点にあるんは、ルートサーバや。ずぅぇえええぇぇええんぶのネームサーバ は、ルートサーバの IP アドレスを知っとりまんねん。ルートサーバの IP アドレス は、DNS ソフトウェアに組み込まれとるからや。これらのルートサーバは、 .com や .org といったトップレベルドメインに関するネームサーバの IP アドレスを知っとりますが、それらの内部にあるマシンのアドレスは知らしまへん。 個々のトップレベルドメインのサーバは、その直下のドメインのネームサーバ の場所を知ってて、以下そないな関係が続きまんねん。
DNS は、どエライ用心深く設計されてて、各マシンがこの木構造に関する必要最小限の 情報をやり取りするだけやむように、ほんで、局所的なサブツリーの変更は、一箇所 だけの権威あるネームサーバの名前と IP アドレスとのマッピングを変更するだけで 実施できるようになっとりまんねん。
www.linuxdoc.org の IP アドレスを問い合わせた場合、実際には次のような ことが起こるんや。第一に、その問い合わせを受けたネームサーバ(x)が、 ルートサーバに対して、.org に関するネームサーバがどこにあるんか 教えるよう問い合わせをしまっせ。それが分かると、次に(x は)、.org の サーバ に対して、.linuxdoc.org のネームサーバがどこにあるんか教えてくれる ようわ、問い合わせをしまっせ。その答えが返ってきたら、今度は(x は)、 .linuxdoc.org のネームサーバに対して、www.linuxdoc.org ちうホスト の IP アドレスを教えるよう問い合わせまんねん。
たいていの場合、ネームサーバは実際に上記のような難儀な仕事をする必要は おまへん。ネームサーバは大量の情報をキャッシュしてんねんさかいや。 名前の解決ができたとき、ネームサーバは入手した IP アドレスとの 対応関係をちーとの間の間メモリ内に保持しまっせ。初めてのウェブサイトを サーフする際、「ホストを探してるんや」ちうブラウザからの文句 が表示されるんはいっちゃん最初のページを開いた場合だけであるんは、上記 のような仕組みになっとるからや。最終的には、名前とアドレスとの マッピングは時間切れとなり、DNS はその名前をもっかい問い合わせなければ やったらなくなるんですわ。この機能が重要なんは、あるホスト名とアドレスとの 結びつきが変更されたときに、チャラになりよった情報がいつまでも邪魔を するようなことがんゆうことや。あるサイトに関するキャッシュされ た IP アドレスは、そのホストに到達できなくなりよった場合にも、破棄されはります。
ブラウザが実行したろおもておるんは、www.linuxdoc.org 上のウェブサーバ に対して次のようなコマンドを送信するっちうことや。
GET /LDP/HOWTO/Fundamentals.html HTTP/1.0 |
以下で、その際に何が起こるんかについて説明しまっせ。上記コマンドは、 パケット(packet) ちうビットの塊に分割され、電報の場合のように、 次のような三つの重要事項を付け加えた上でラップされはります。その 重要事項とは、送信元アドレス (source address) (読者のマシンの IP アドレス)、あて先アドレス (destination address) (こら、152.19.254.81)、およびそれがウェブに関するリクエストであることを示す サービス番号 (service number) もしくは ポート番号 (port number) (この場合では、80 番)や。
次に、読者のマシンはそのパケットを回線(ISP や ローカルネットワークとの コネクション) 上に送信すると、そのパケットは ルータ(router) と呼ばれる特別なマシンに届きまんねん。ルータは、インターネットの 地図をメモリ内に記憶してるんや。こら必ずしも完全な地図やおまへんが、 そのネットワークの周辺地域については完全に記述してんねんさかい、 インターネット上の他の周辺ルータに至なあかん方法は理解してるんや。
送信したパケットは、いくつかのルータを通過しながら、あて先へと到達しまっせ。 ルータはどエライ上手く出来とりまんねん。ルータは、パケットを受信した旨の 送達確認を他のルータから受け取るまでの経過時間を監視してるんや。また、 その経過時間に関する情報を使うて、空いとるリンク上にパケットを流す ようトラフィックを調整してるんや。また、ルータはその情報を使用して、 他のルータやケーブルが原因でネットワークに支障が生じた際に、 別のルータを探すことで可能な限り埋め合わせをしたろおもてまんねん。
インターネットは核戦争に耐えられはるように設計されたゆう噂が都会で暮らす 人々の間でささやかれていま。こら真実ではおまへんが、せやけどダンさん、インター ネットの設計ちうんは、この不確かいなことが多い世界において、頼りにならへん ハードウェアからでも信頼に足るパフォーマンスを引き出してくれるだけの 極めて優れた設計思想のもとに構築されとりまんねん。 このことは、まさに次の事実によっておりますわ。 すなわち、(電話回線網のように)少数の巨大で脆弱な交換機に処理を集中 させるのやなく、無数のルータにそうした処理の役割を分散したゆう ことや。ゴチャゴチャゆうとる場合やあれへん、要は、障害はあくまで局地的なもんに留まるようになってて、 ネットワークはそないな障害を避けてルーティングするっちうことができるちうワケや。
パケットが一旦あて先のマシンまで到達したやったら、そのマシンはサービス番号を 使うて、そのパケットをウェブサーバに渡しまっせ。ウェブサーバは、そのコマンド パケットの送信元 IP アドレスを見ることで、どこに返答を返したらよいんかを 知ることができまんねん。上記の例で、そのウェブサーバがこの文書を送信する際は、 文書はいくつかのパケットへと分割されはります。パケットのサイズは、ネットワーク 上の伝送方法やサービスの種類によって異なるんですわ。
こないな分割されたパケットを使う通信方法の処理のしかたを理解するには、 インターネットは実際にはふたつのプロトコルを使用してて、一方が他方の 上に積み重ねられとるちう通信の仕組みを知る必要がおます。
下位層である IP (Internet Protocol) は、送信元アドレスからあて先アドレスに個別のパケットを到達させるための 方法は知っとります(これらが IP アドレスと呼ばれるんはそのためや)。 そやかて、IP は信頼性に欠けとりまんねん。パケットが途中で行方不明に なりよったり消失したりしたかて、送信元とあて先のマシンは決してそれに 気づかいないでっしゃろ。ネットワーク用語では、IP は コネクションレス (connection less) なプロトコルや。 送信者はパケットを 受信者に対して送るだけなんやし、受信側からの確認応答は期待でけしまへん。
せやけどダンさん、IP は、高速かつ安価や。高速かつ安価やったら、信頼性がなくとも 問題んという場合もおます。Doom や Quake をネットワーク上でプレイする ときは、弾丸のひとついっこも IP パケットで送られとりまんねん。弾丸の2,3 発 消失してしもたとしたかて、特に問題はあらへんはずや。
上位層の TCP (Transmission Control Protocol) は、信頼性のためのプロトコルや。 二台のマシンが相互に交渉して TCP コネクションを張り (こら、IP を使うて 行われはる)、受信側が受信したパケットについての到達確認を送信側に 送るようになっとりまんねん。送信側が一定時間内にあるパケットの送達確認を 受け取らへん場合は、そのパケットを再送しまっせ。さらに、送信側は、個々の TCP パケットに通し番号を振っとるさかい、受信側ではそれを使うて、パケットの 到着順序が狂った場合でもそないなパケットを並べ直すことができるように なっとりまんねん。(こら、ネットワーク上の経路が、コネクションの最中に 変動した場合には、よう起こる現象や。)
TCP/IP パケットにはチェックサム (checksum) ちう情報も含まれてて、 経路上に障害が生じてデータが壊れてしもたりしておらへんかを検出できる ようになっとりまんねん。 (チェックサムは、まずチェックサム自体を除いたパケットの残りの情報から算出 されはります。そないにしておくと、パケットの残りの部分かチェックサム自体が(経路上で) 壊れてもうていた場合は、(到達先で)そのパケットからもっかいチェックサムを算出 して、もとのチェックサムと比較するっちうことで、アヤマチの有無を高い確率で検出する ことができるわけや)。それやから、 TCP/IP とネームサーバちうんは、使う側の視点からみると、ホスト名とサービス 番号で区別された二台のホスト間でバイトストリームを伝達しあう方法としては、 信頼に足るもんとぬかしてもええでっしゃろ。また、ネットワークプロトコルを書く人から すると、このネットワーク階層以下で起こっとるパケット分割やパケットの再構成、 アヤマチチェック、チェックサムの計算、再送といった事柄をほとんど考慮せえへんかて ようなるんですわ。
ここで、先ほどの例題に戻りまひょ。ウェブブラウザとサーバとは、 アプリケーションプロトコル (application protocol) を使うて 会話をしてるんや。こら、TCP/IP 階層の上位で実行されるプロトコルなんやし、 TCP/IP をバイト列のやりとりの手段として利用してんもんや。上記の例での プロトコルは、 HTTP (Hyper-Text Transfer Protocol) と呼ばれるもんで、ほんで使われるコマンドの一例が GET で始まる文字列である ことは既に見はった通りや。
上記の GET コマンドが www.linuxdoc.org のウェブサーバにサービス番号 80 番で 到達すると、ウェブサーバはこれを、80 番ポートで待機してん サーバデーモン (server daemon) へと渡しまっせ。大部分のインターネットサービスは、 サーバデーモンとして実装されてて、これらは、送られてくるはずのコマンドを 監視し、実行するために、特定のポートでただひたすら待ち受け状態を続けとりまんねん。
インターネットの設計に関する一大原則があるとするんやったら、そらずぅぇえええぇぇええんぶの部分が できる限りシンプルで人間が見て分かるような形にするゆうことや。HTTP と その親戚 (Simple Mail Transfer Protocol, SMTP ちう、ホスト間で電子メールをやりとりするために使われるプロトコルやらなんやら) は、キャリッジ・リターン(復帰)とライン・フィード(改行)で終了する、人間が 読んでも意味の分かるシンプルなテキストコマンドを使うゆう傾向がおます。
こないな方法は、ごっつう非効率や。環境によっては、がちがちに固められはった バイナリプロトコルを使うてスピードアップを図ることもできるはずや。 せやけどダンさん、経験が示すトコによると、人間にとって説明や理解のしやすいコマンド を使うことのメリットは、トリッキーで分かりにくいもんをわざわざ作ること で得られはる僅かいな効率の上昇をはるかに上回るもんなんやこれがホンマに。
したがちう、サーバデーモンが TCP/IP 経由で送り返す返答もテキスト形式 や。返答の最初の部分は、次のようなもんとなるんや(ヘッダの一部は省略 してるんや)。
HTTP/1.1 200 OK Date: Sat, 10 Oct 1998 18:43:35 GMT Server: Apache/1.2.6 Red Hat Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT Content-Length: 2982 Content-Type: text/html |
上記のようなヘッダの後に空行がひとつ入り、その後にウェブページのテキスト が続きまんねん(それらの送信が終わった時点で、コネクションが切断されはる)。 ブラウザは、それらを表示するだけや。ヘッダは、ブラウザに対してその 表示方法を指示するもんや (特に、Content-Type ちうヘッダでは、 返信データが実際に HTML であるちうことをブラウザに伝えとります)。