インターネットがどうやって動いているのかを理解するのを助けるため に、あなたが典型的なインターネットの操作をしたときに何が起こって いるのかについて見ていきましょう。 the Linux Documentation Project の Web 上にあるホームページで、このドキュメントの先頭ペ ージをクリックしたとします。このドキュメントは
http://metalab.unc.edu/LDP/HOWTO/Fundamentals.html
で、これはホスト metalab.unc.edu の WWW 公開用ディレクトリの LDP/HOWTO/Fundamentals.html にあることを示しています。
あなたのブラウザがまずしなければならないことは、そのドキュメント があるマシンへのネットワーク・コネクションを確立することです。こ れを行うためにはまず、ホスト metalab.unc.edu のネットワーク的な位置を見つけなければなりません(「ホスト」とは 「ホストマシン」または「ネットワークホスト」の略です。 metalab.unc.edu は典型的なホスト名です。これ に対応する位置は、実際にはIP アドレスと呼ば れる番号です(この用語の中の `IP' の部分については後述します)。
これを行うため、ブラウザはネームサーバと呼ば れるプログラムに対して問い合わせを行います。ネームサーバはあなた のマシン上にあるかもしれませんが、あなたが対話しているサービス・ マシン上で動いている可能性の方が高いでしょう。ISP に接続の申し込 みをする時、セットアップ手続きの一部において、ほぼ間違いなく、イ ンターネット・ソフトウェアに対してその ISP のネットワーク上のネ ームサーバのIP アドレスを教えてやる必要があります。
異なったマシン上のネームサーバは、お互いに対話し合って、ホスト名 を解決する(ホスト名を IP アドレスにマッピングする)ために必要な すべての情報を交換し、最新に保つようにしています。あなたのネーム サーバは、metalab.unc.edu を解決するために、ネットワークをまたが って 3 つか 4 つのサイトに問い合わせを行っているかもしれません。し かし、通常これは(1 秒以内とかの)あっという間に行われます。
ネームサーバはあなたのブラウザに対して、metalab の IP アドレスは 152.2.22.81 であることを教えます。これを知ると、あなたのマシンは metalab と直接ビットデータの交換を行えるようになります。
次にここでブラウザがしようとするのは、metalab のウェブサーバに対して 以下のようなコマンドを送ることです。
GET /LDP/HOWTO/Fundamentals.html HTTP/1.0
実際に起こることは以下のようになります。コマンドはパケットとして送られます。これはビット列のブロックで、3 つの重 要な情報といっしょに電報のように包まれています。重要なものとは、 始点アドレス(あなたのマシンの IP アドレス)、 終点アドレス(152.2.22.81)、 それからこれが WWW のリクエストであることを示す サービス番号またはポート番号 (この場合は 80)です。
その後、あなたのマシンがそのパケットをケーブル(ISP へのモデム接続、 またはローカルなネットワーク)へ送ると、そのパケットはル ータと呼ばれる特殊なマシンに届きます。ルータは自分の メモリ内にインターネットの地図を持っています。その地図は必ずし も完全なものではありませんが、あなたのネットワークに隣接する部分 までを完全に網羅したものなので、ルータはそのパケットを、インター ネット上の他の場所にあるルータへどう届ければよいかを分かっていま す。
あなたのパケットは、宛先に届くまでの経路において、いくつかのルー タを通っていくかもしれません。それら相互のルータは、相手のルータ がパケットを受信したことを認識するために、どれくらい送信に時間が かかっているかを監視します。ルータはこの情報を使って、トラフィックを高速な リンクに向けます。また、ルータはこの情報を使って、他のルータ(またはケーブル) がネットワークからはずれてしまった時には通知を出し、可能であれば他の経路を 見つけて経路情報を補正します。
インターネットは核戦争を生き残るために設計されたという都市伝説が あります。これは真実ではありませんが、インターネットの設計は、不 確実な世界における変なハードウェアから確実な性能を得ることが非常に 得意です。この直接の理由は、インターネットの知的処理の部分は (電話ネットワークのような)少数の大規模なスイッチにではなく、 何千ものルータに分散されているという事実のおかげです。つまり、不具合が起き てもそれは局所的なものにとどまり、ネットワークはこれを回避した経路を作るこ とができるのです。
いったんあなたのパケットが宛先のマシンに届くと、そのマシンはサー ビス番号を使ってそのパケットをウェブサーバに入力します。ウェブサー バはコマンドパケットの送り元 IP アドレスを見て、どこに応答を返せ ばよいかがわかります。ウェブサーバがこのドキュメントを返す時、それ は数多くのパケットに分割されます、それらのパケットのサイズは、ネ ットワークにおける伝送メディアやサービスのタイプにより異なります。
複数パケットの転送がどうやって処理されるのかを理解するには、インターネット が実際には階層構造になっている 2 つのプロトコルを使っていることを知らなけれ ばなりません。
下位のレベルであるIP (Internet Protocol)は、 個々のパケットを始点アドレスから終点アドレスに送る方法を知っています(このこ とから、これらの 2 つのアドレスは IP アドレスと呼ばれているのです)。 しかしながら、IP には信頼性がありません。あるパケットが失われた り脱落してしまったりしても、始点や終点のマシンにはこのことがわかりません。 ネットワークの専門用語では、IP はコネクションレスなプロトコルです。 送信側はパケットを受信側に対して送りつけるだけで、その ACK(肯定応答)を求め ません。
しかしながら IP は高速かつコストの低い通信方法です。高速で手軽で信頼性が なくても構わない場合もあります。例えば、ネットワーク対応の Doom や Quake (訳注:両方ともゲームの名前)をしているとき、各々の弾丸は IP パケットとして 表現されますが、そのうちのいくつかがなくなっても OK ですよね?
上位レベルのTCP(Transmission Control Protocol =伝送制御プロトコル)は信頼性を提供します。2 つのマシンが TCP で送受信を行う際、受信側は送信側に対して ACK パケットを返します。 送信側は一定時間内に ACK パケットを受信できないと、そのパケット を再送します。しかも、送信側は各 TCP パケットにシーケンス番号を 付けて、もし(分割されたパケットが)順番に届かなかった場合、受信 側でパケットを再構成することができるようになっています。(これは、 接続中にネットワーク・リンクが確立したりダウンしたりする場合に起 こります。)
TCP/IP パケットにはまた、不良のリンクによるデータの破損を検出できるようにチェッ クサムが設けられています。このため、TCP/IP とネームサーバを使っているユーザ から見ると、ホスト名/サービス番号のペアの間には信頼できるバイト・ストリーム の経路があるように見えます。ネットワーク・プロトコル(のソフトウェア)を書く 人は、これより下層レベルで行われるパケット化やパケット組み立て、エラーチェック、 チェックサムの生成やチェック、再送といったことを全部考える必要はまずありま せん。
ここで前の例に戻りましょう。ウェブブラウザとサーバは、TCP/IP の上 位で動作するアプリケーションプロトコルで話を します。これは単にバイト文字列をやり取りするという単純な方法です。 このプロトコルはHTTP (Hyper-Text Transfer Protocol)と呼ばれていて、そのコマンドのうちの 1 つが前に紹介した GET コマンドです。
GET コマンドは metalab.unc.edu のウェブサーバにサービス番号 80 と いっしょに届き、そのサーバ上でポート 80 番を監視しているサーバ・デーモンに渡されます。インターネット上のサー ビスのほとんどはサーバ・デーモンにより実装されていて、これは単に ポート上で入力を監視し、入ってくるコマンドを実行しているだけです。
インターネットの設計がある包括的なルールを持っているとすれば、 それはすべてのパーツが可能な限りシンプルで、かつ人間が見てわかる ようになっているということです。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
これらのヘッダに続いて 1 つの空行があり、その後(コネクションが切 られるまで)Web ページのテキストが続きます。あなたのブラウザは単 にそのページを表示するだけです。ヘッダはブラウザに対して、その表 示方法を指示します(代表的なものとして、Content-Type ヘッダは返 されたデータが本物の HTML であることを伝えます)。