この章では、Solaris 実装の TCP/IP ネットワークプロトコル群を紹介します。この章の情報は、まだあまり TCP/IP に慣れていないネットワーク管理者を対象としています (ネットワークの基本概念の紹介については、第 1 章「ネットワーク管理の概要」を参照してください)。TCP/IP の経験のあるネットワーク管理者の場合は、この章をとばして行いたい作業に該当する章に進んでもかまいません。
この節では、TCP/IP を構成するプロトコルについて詳しく紹介します。ここに示す情報は概念的なものですが、各プロトコルの名前とそれぞれの働きを理解することができます。TCP/IP 関係の書籍は、どれもここに示す概念を理解していることを前提として書かれているので、この情報は重要です。
TCP/IP は、インターネットプロトコル群を形成するネットワークプロトコルの集合を示すニックネームとして使われています。多くの書籍では、「インターネット」という用語は、プロトコル群と広域ネットワークの両方を表すものとして使われています。本書では、「TCP/IP」は特にインターネットプロトコル群を表し、「インターネット」は広域ネットワークとそれを運営する組織を表すものとします。
TCP/IP ネットワークと他のネットワークとを相互接続するには、一意な IP ネットワーク番号を入手する必要があります。本書を作成した時点では、IP ネットワーク番号は、InterNIC と呼ばれる組織によって割り当てられていました。
ネットワーク上のホストがインターネットドメイン名システム (DNS) に参加する場合は、一意なドメイン名を入手し登録する必要があります。InterNIC は、いくつかのトップレベルのドメイン、たとえば .com (商業)、.edu (教育)、.gov (政府) などのドメインの傘下にあるドメイン名の登録も行なっています。InterNIC については、第 3 章「ネットワークの計画」で詳しく説明します (DNS についての詳細は、『Solaris ネーミングの管理』を参照してください)。
ほとんどのネットワークプロトコル群は、一連の層として構築されており、これはしばしば総称的にプロトコルスタックと呼ばれます。各層はそれぞれ特定の目的のために設計されていて、送信側ホストと受信側ホストの両方に存在しています。一方のマシンの特定の層が、相手のマシンの対等プロセスが送受信するオブジェクトと同じものを送受信するように設計されています。このような動作は、問題の層の上下の層で進行していることとは独立して行われます。つまり、ホストの各層は、同じマシンの他の層から独立して、他のホストの同じ層と協調して働きます。
ほとんどのネットワークプロトコル群が層の形に構造化されているとみなされるのは、国際標準化機構 (ISO) が設計した開放型相互接続 (OSI) 参照モデルの結果です。OSI モデルは、ネットワーク活動が 7 つの層から成る構造を持ち、それぞれの層に 1 つまたは複数のプロトコルが関連付けされるものと規定しています。層は、連携するネットワーク相互間でのすべての種類のデータ転送に共通するデータ転送操作を表します。
OSI 参照モデルのプロトコル層は、通常は表 2-1 に示すように、上 (層 7) から下 (層 1) へ並べて表します。
表 2-1 開放型相互接続参照モデル
層番号 |
層の名前 |
説明 |
---|---|---|
7 |
誰でも使用できる標準の通信サービスとアプリケーション |
|
6 |
情報が解読可能な形で受信側マシンに渡されるようにする |
|
5 |
連携コンピュータ間の接続と終了を管理する |
|
4 |
データの転送を管理し、受信されたデータと送信されたデータが同じになるようにする |
|
3 |
ネットワーク間でのデータのアドレス指定と配送を管理する |
|
2 |
ネットワークメディアを通過するデータの転送を取り扱う |
|
1 |
ネットワークハードウェアの特性を定義する |
OSI モデルにより定義されている動作は概念的なものであり、特定のネットワークプロトコル群に特有のものではありません。たとえば、OSI ネットワークプロトコル群は、OSI 参照モデルの 7 つの層をすべて実装しています。TCP/IP は、OSI モデルの層のいくつかを使用し、その他を合併しています。その他のネットワークプロトコル、たとえば SNA では、8 番目の層が追加されています。
TCP/IP は、いくつかの OSI 層を合併して 1 つの層にしていたり、またまったく使わない層があったりするため、このモデルに直接対応しているとは言えません。表 2-2 は、Solaris 実装の TCP/IP の層を示しています。最上位の層 (アプリケーション) から最下位の層 (物理ネットワーク) まで並べてあります。
表 2-2 TCP/IP プロトコルスタック
OSI 参照の層番号 |
対応する OSI 層 |
TCP/IP 層 |
TCP/IP プロトコルの例 |
---|---|---|---|
5,6,7 |
アプリケーション、セッション、プレゼンテーション |
NFS、NIS+、DNS、telnet、ftp、"r"(リモート) コマンド1、RIP、RDISC、SNMP、その他 |
|
4 |
トランスポート |
TCP, UDP |
|
3 |
ネットワーク |
IP, ARP, ICMP |
|
2 |
データリンク |
PPP, IEEE 802.2 |
|
1 |
物理 |
イーサネット (IEEE 802.3) トークンリング、RS-232、その他 |
1."r" コマンドには、rlogin、rsh、rcp があります。
この表は、TCP/IP プロトコルの層、対応する OSI モデルの層、および TCP/IP プロトコルスタックの各レベルで使用できるプロトコルの例を示しています。通信トランザクションに関与する各ホストは、それぞれ独自の実装によるプロトコルスタックを実行します。
物理ネットワーク層は、ネットワークに使用するハードウェアの特性を規定します。たとえば、通信メディアの物理特性を規定します。TCP/IP の物理層はハードウェア規格を意味しています。たとえば、イーサネットネットワークメディアの仕様である IEEE 802.3 や、標準ピンコネクタの仕様である RS-232 などです。
データリンク層は、パケットのネットワークプロトコルの種類を識別します。この場合は TCP/IP です。また、この層には、エラー制御と「フレーミング」の働きもあります。データリンク層の例としては、イーサネット IEEE 802.2 フレーミングと、ポイントツーポイントプロトコル (PPP) フレーミングがあります。
この層はネットワーク層とも呼ばれるもので、ネットワークに対してパケットを受け入れたり、配送したりします。この層には、強力なインターネットプロトコル (IP)、ARP プロトコル、ICMP プロトコルが組み込まれています。
IP プロトコルとそれに関連したルーティングプロトコルは、TCP/IP 群全体の中でたいへん重要なものです。IP は次の機能を受け持ちます。
IP アドレス指定 - IP アドレス指定の規則は IP プロトコルの一部です (IP アドレス指定については、第 3 章「ネットワークの計画」で詳しく説明します)。
パケット形式設定 - IP は、パケットを IP データグラムと呼ばれる単位に組み立てます。データグラムについては、「インターネット層」で詳しく説明します。
フラグメント化 - パケットが大きすぎてネットワークメディアを介して転送できないときは、送信側ホストの IP は、パケットを小さいフラグメントに分割します。受信側ホストの IP は、これらのフラグメントを組み立てて元のパケットに戻します。
アドレス解決プロトコル (ARP) は、データリンク層とインターネット層の間に概念的に存在するものです。ARP は、イーサネットアドレス (48 ビット長) を既知の IP アドレス (32 ビット長) にマッピングし、IP はこの情報に基づいてデータグラムを正しい受信側ホストに向けることができます。
インターネット制御メッセージプロトコル (ICMP) は、ネットワークエラー条件の検出とその報告を担当するプロトコルです。ICMP は以下の事項について報告します。
第 6 章「TCP/IP の障害追跡」に、エラー検出のために ICMP を使用するオペレーティングシステムコマンドに関する詳細が記載されています。
TCP/IP トランスポート層プロトコルは、パケットが正しい順序でエラーなしに到着するようにするために、データ受領の肯定応答を交換し、失われたパケットがあれば転送しなおします。この種類の通信を「終端間」通信と呼びます。このレベルのトランスポート層プロトコルは、トランスミッションコントロールプロトコル (TCP) とユーザーデータグラムプロトコル (UDP) です。
TCP は、物理的な回線で接続されているのと同じようにしてアプリケーション相互間の通信ができるようにします。TCP は、独立したパケットの形ではなく、文字単位で転送されているような形でデータを送信します。この転送では、まず開始ポイントで接続がオープンされ、次にバイト順序ですべてのデータが転送され、終了ポイントで接続がクローズされます。
TCP は、転送するデータにヘッダーを添付します。このヘッダーには、送信側マシン上のプロセスが受信側マシン上の対等プロセスに接続できるようにするための、多数のパラメータが含まれています。
TCP は、送信側ホストと受信側ホストとの間に終端間接続を確立することにより、パケットが宛先に到達したことを確認します。したがって、TCP は、「信頼性の高い接続指向型」プロトコルとみなすことができます。
もう 1 つのトランスポート層プロトコルである UDP は、データグラム配送サービスを提供します。受信側ホストと送信側ホストとの間で接続が達成されているかどうかを検査する手段は提供しません。UDP は接続の確立と検査を省略するので、少量のデータを送信するアプリケーションにとっては、TCP よりも効率的です。
アプリケーション層は、誰でも使用できる標準的なインターネットサービスとネットワークアプリケーションを定義します。これらのサービスとトランスポート層の両方の働きにより、データの送受信が行われます。アプリケーション層のプロトコルにはさまざまのものがあり、そのうちのいくつかは、すでに使用しているでしょう。以下に、この種のプロトコルの例をいくつか挙げます。
標準 TCP/IP サービス。たとえば、ftp、tftp、telnet コマンドなど
UNIX の "r"(リモート) コマンド。たとえば、 rlogin や rsh など
ネームサービス。たとえば、NIS+ やドメインネームシステム (DNS) など
ファイルサービス。たとえば NFS など
SNMP (ネットワーク管理用プロトコルの一種。Simple Network Mamagement Protocol の略)
FTP と匿名 FTP - ファイル転送プロトコル (FTP) は、リモートネットワークとの間でファイルを転送します。このプロトコルには、ftp コマンド (ローカルマシン) と in.ftpd デーモン (リモートマシン) が含まれています。ユーザーは、リモートホストの名前とファイル転送コマンドのオプションを、ローカルホストのコマンド行に指定します。すると、リモートホストの in.ftpd デーモンが、ローカルホストからの要求を処理します。rcp とは違って、ftp は、リモートコンピュータのオペレーティングシステムが UNIX でない場合でも動作します。匿名 FTP を認めるように設定されている場合を除いて、ftp 接続を行うときにはリモートコンピュータにログインする必要があります。
現在では、インターネットに接続されている各種の匿名 FTP サーバーから、さまざまの豊富な資料や情報を入手できます。これらのサーバーは大学その他の研究機関により設定されたもので、ある種のソフトウェア、研究報告、その他の情報をパブリックドメインに公開しています。この種のサーバーにログインするときには、ログイン名として anonymous を使用します。「匿名 (anonymous) FTP サーバー」という言葉はこれに由来しています。
匿名 FTP の使用法と匿名 FTP サーバーの設定については、本書では説明しません。しかし、たとえば『The Whole Internet User's Guide & Catalog』など、匿名 FTP について詳しく説明している多数の書籍が市販されています。FTP を使って標準マシンに到達するための方法については、 『Solaris のシステム管理 (第 1 巻)』に説明があります。ftp(1) のマニュアルページには、コマンドインタプリタによって呼び出されるものも含むすべての ftp コマンド・オプションについての説明があります。 ftpd(1M) のマニュアルページには、in.ftpd デーモンが提供するサービスに関する説明があります。
Telnet - Telnet プロトコルは、端末と端末指向プロセスが、TCP/IP を実行するネットワーク上で通信できるようにします。このプロトコルは、telnet プログラム (ローカルマシン上の) と in.telnet デーモン (リモートマシン上の) として実装されます。Telnet は、2 つのホストが文字単位または行単位で通信できるようなユーザーインタフェースを提供します。アプリケーションにはコマンドのセットが含まれていますが、これについては、telnet(1) のマニュアルページに詳しい説明があります。
TFTP - 簡易ファイル転送プロトコル (tftp) は ftp に似た機能を備えていますが、ftp の対話型接続を確立する機能はありません。したがって、ユーザーは、ディレクトリの内容を表示したり、ディレクトリを変更したりすることはできません。これは、ユーザーが、コピーしたいファイルのフルネームを知っていなければならないことを意味します。tftp のコマンドセットについては、tftp(1) のマニュアルページに説明があります。
UNIX の "r"(リモート) コマンドを使用すると、ユーザーは、指定したリモートホストで実行したいコマンドを、各自のローカルマシンで発行することができます。この種のコマンドには次のものがあります。
rcp
rlogin
rsh
これらのコマンドの使い方については、 『OpenWindows ユーザーズガイド (上級編)』および、rcp(1)、rlogin(1)、rsh(1) の各マニュアルページに説明されています。
Solaris 実装の TCP/IP では、NIS+ と DNS の 2 つのネームサービスが使用できます。
NIS+ - NIS+ は、ホスト名から IP アドレスとイーサネットアドレスへのマッピング、パスワードの検査など、ネットワーク管理サービスに対する集中制御の機能を提供します。詳細は、 『Solaris ネーミングの管理』を参照してください。
ドメインネームシステム - ドメインネームシステム (DNS) は、ホスト名から IP アドレスへのサービスを提供します。また、メール管理用のデータベースとしての働きもします。このサービスの詳細は、『Solaris ネーミングの管理』を参照してください。in.named(1M) のマニュアルページも参照してください。
NFS アプリケーション層プロトコルは、Solaris オペレーティングシステム用のファイルサービスを提供します。NFS サービスについての詳細は、『NFS の管理』で説明しています。
SNMP (ネットワーク管理用プロトコルの一種。Simple Network Management Protocol) を使用すると、ネットワークのレイアウトを表示し、主要マシンの状態を表示し、さらに、その他の複雑な統計情報をグラフィカルユーザーインタフェースを持つソフトウェアから得ることができます。多くの企業が、SNMP を実装するネットワーク管理パッケージを提供しています。SunNet ManagerTM はその一例です。
TCP/IP ネットワーク用の 2 つのルーティングプロトコルとして、RIP (Routing Information Protocol) と RDISC (Router Discovery Protocol) があります。これらのプロトコルについては、第 5 章「ルーターの構成」で説明します。
ユーザーが TCP/IP アプリケーション層プロトコルを使用するコマンドを発行すると、一連のイベントが発生します。ユーザーのコマンドまたはメッセージは、ローカルマシン上の TCP/IP プロトコルスタックを通過し、ネットワークメディアを通り、受信側のプロトコルに到達します。送信側ホストの各層のプロトコルにより、オリジナルのデータに情報が付加されていきます。
ユーザーのコマンドがプロトコルスタックを通過していくとき、送信側ホストの各層のプロトコルは、受信側ホストのそれぞれの対等プロトコルとの間で対話します。図 2-1 に、この対話がどのように行われるかを示します。
パケットは、ネットワーク上を転送される情報の基本単位で、少なくとも、送信側ホストと受信側ホストのアドレスが入ったヘッダーと、転送するデータが入ったボディーが含まれています。パケットが TCP/IP プロトコルスタックを通過するとき、各層のプロトコルは、基本ヘッダーにフィールドを追加したり、そこからフィールドを削除したりします。送信側ホストのプロトコルがパケットヘッダーにデータを追加する場合、その動作をデータのカプセル化と呼びます。また、変更後のパケットを表す言葉は、図 2-1 に示すように層によって異なります。
この節では、ユーザーがコマンドを発行するかまたはメッセージを送信してから、それを受信側ホストの該当のアプリケーションが受け取るまでの、パケットのライフサイクルを要約して示します。
パケットの履歴は、あるホストのユーザーが、リモートホストへのアクセスを必要とするようなメッセージを送信するかコマンドを発行した時点から始まります。そのコマンドまたはメッセージに関連付けられているアプリケーションプロトコルは、対応する TCP か UDP のどちらかのトランスポート層プロトコルで取り扱えるように、パケットの形式を設定します。
図 2-1 に示したように、ユーザーが、リモートホストにログインするために rlogin コマンドを発行したとします。rlogin コマンドは TCP トランスポート層プロトコルを使用します。TCP は、コマンド内の情報を含むデータをバイトストリーム形式で受け取るものと仮定しています。したがって、rlogin はこのデータを TCP ストリームとして送信します。
しかし、すべてのアプリケーション層プロトコルが TCP を使用するわけではありません。あるユーザーが、リモートホストのファイルシステムをマウントしようとして、NIS+ アプリケーション層プロトコルを開始したとします。NIS+ は UDP トランスポート層プロトコルを使用します。したがって、このコマンドを含むパケットは、UDP が仮定しているような方法に形式化する必要があります。この種類のパケットをメッセージと言います。
データがトランスポート層に到着すると、この層のプロトコルはデータのカプセル化を開始します。最終的な結果は、TCP と UDP のどちらが情報を処理したかによって異なります。
TCP はしばしば「接続指向型」プロトコルと呼ばれますが、これは、このプロトコルが、受信側ホストにデータが正常に到達したかどうかを確認するからです。 図 2-1 に、TCP プロトコルが rlogin コマンドからのストリームをどのように受け取るかを示してあります。TCP は、アプリケーション層から受け取ったデータをセグメントに分割し、各セグメントにヘッダーを添付します。
セグメントヘッダーには、送信側と受信側のポート、セグメント順序に関する情報、検査合計と呼ばれるデータフィールドが含まれています。両方のホストの TCP プロトコルがこの検査合計データを使用して、データがエラーなしに転送されたかどうかを判別します。
TCP は、受信側ホストでデータ受信の準備が整っているかどうかを判別するためにも、セグメントを使用します。送信側 TCP は、接続を確立するために、受信側ホストで実行されている対等 TCP プロトコルに SYN と呼ばれるセグメントを送ります。受信側 TCP は ACK と呼ばれるセグメントを戻して、セグメントを正しく受信したことを知らせます。送信側 TCP は新たな ACK セグメントを送信して、それからデータの送信を開始します。このような制御情報の交換を「3 相ハンドシェーク」と呼びます。
UDP は「コネクションレス」プロトコルです。TCP の場合と異なり、UDP は、受信側ホストにデータが到達したかどうかを確認しません。そのかわりに、UDP は、アプリケーション層から受け取ったメッセージを「UDP パケット」に形式化します。UDP は、各パケットにヘッダーを付加します。ヘッダーには、送信側ホストと受信側ホストのポート、パケットの長さを示すフィールド、検査合計が含まれています。
送信側 UDP プロセスは、受信側ホストの対等 UDP プロセスにパケットを送ろうとします。アプリケーション層は、受信側 UDP プロセスが、パケットを受信したことを示す肯定応答を戻すかどうかを判別します。UDP は受領の通知を必要としません。UDP は 3 相ハンドシェークを使用しません。
図 2-1 に示したように、TCP と UDP はどちらもセグメントとパケットを下位のインターネット層に送り、セグメントとパケットはそこで IP プロトコルにより処理されます。IP は、セグメントとパケットを IP データグラムと呼ばれる単位に形式化して、配送の準備を整えます。次に、IP はデータグラムの IP アドレスを判別して、受信側ホストへの効率的な配送ができるようにします。
IP は、TCP または UDP が付加した情報に付け加える形で、セグメントまたはパケットのヘッダーに「IP ヘッダー」を付加します。IP ヘッダーには、送信側ホストと受信側ホストの IP アドレス、データグラムの長さ、データグラムのシーケンス番号が含まれます。これらの情報が付加されるのは、データグラムがネットワークパケットとしての許容バイトサイズを超過してフラグメント化が必要になった場合に備えるためです。
PPP などのデータリンク層プロトコルは、IP データグラムをフレームの形に形式化します。これらのプロトコルは、第 3 のヘッダーとフッターを付加することにより、データグラムを「フレーミング」します。フレームヘッダーには、フレームがネットワークメディアを通過するときのエラーを検査するための、巡回冗長検査 (CRC) フィールドが含まれています。次に、データリンク層は物理層にフレームを渡します。
送信側ホストの物理ネットワーク層は、フレームを受け取ると、IP アドレスをネットワークメディアに合わせたハードウェアアドレスに変換します。次に、物理ネットワーク層は、フレームをネットワークメディアに送り出します。
受信側ホストに到着したパケットは、送信側ホストのときと逆の順序で TCP/IP プロトコルスタックを通過します。 図 2-1 にこの経路を示してあります。受信側ホストの各プロトコルは、送信側ホストの対等プロトコルがパケットに付加したヘッダー情報を取り除きます。この処理の順序を以下に示します。
物理ネットワーク層はフレーム形式のパケットを受け取ります。パケットの CRC を計算し、データリンク層にフレームを送ります。
データリンク層はフレームの CRC が正しいかどうかを検査し、フレームヘッダーと CRC と取り除きます。最後に、データリンクプロトコルは、インターネット層にフレームを送ります。
インターネット層はヘッダーの情報を読み、転送の種別を識別して、それがフラグメントであるかどうかを判別します。その転送がフラグメントである場合は、IP は、フラグメントを組み立て直して、オリジナルのデータグラムに戻します。そして、IP ヘッダーを取り除いてから、データグラムをトランスポート層プロトコルに渡します。
トランスポート層 (TCP と UDP) はヘッダーを読んで、どのアプリケーション層プロトコルにデータを渡すかを判断します。次に、TCP または UDP は、自分に関連するヘッダーを取り除き、メッセージまたはストリームを受信アプリケーションに送ります。
TCP/IP とインターネットについては、膨大な量の情報が出版されています。本書で説明されていない特別な情報は、以下に挙げる情報源から入手できると考えられます。
地域の図書館やコンピュータ関係の書店に、TCP/IP とインターネットに関する多数の書籍がそろっています。中でも特にお勧めしたいのは次の書籍です。
Craig Hunt 著『TCP/IP Network Administration』 - この書籍には、異種 TCP/IP ネットワークの管理について、ある程度の理論と、豊富な実践的情報が記載されています。
W. Richard Stevens 著『TCP/IP Illustrated, Volume I』 - この書籍では、TCP/IP のプロトコルが詳細に解説されています。これは、TCP/IP に関する技術的な背景知識を必要とするネットワーク管理者、ネットワークプログラマにとって最適です。
Ed Krol 著『The Whole Internet User's Guide & Catalog』 - この書籍は、インターネットを介して情報を検索するためのさまざまなツールの使用に関心がある方にとって最適です。
1969 年以来、インターネットプロトコル群に携わる開発者たちは、それぞれのプロトコルと関連の主題を、RFC (コメント要求 = Requests for Comments) と呼ばれる文書の形で記述してきました。多くの RFC は特定の TCP/IP プロトコルの仕様であり、そのプロトコルを実装するソフトウェアが従う必要のある規格を記述しています。ほかに、インターネット、そのトポロジ、その運営組織について記述した RFC もあります。さらに、DNS などのような TCP/IP アプリケーションの管理方法を説明する RFC もあります。
RFC がパブリックドメインに公開されるには、IAB (Internet Architecture Board) より承認されることが必要です。一般に、RFC の中の情報は開発者やその他の高度の専門知識を持つ読者を対象としていますが、すべてがそうであるとは限りません。
最近になって、RFC のサブセットとして FYI (For Your Information) 文書が発行されるようになりました。FYI には、インターネット規格を取り扱うような情報は含まれていません。むしろ、インターネットのもっと一般的な性格に関する情報を扱うものです。FYI には、たとえば、TCP/IP の入門書や資料の目録、あらゆるインターネット関連のソフトウェアツールを網羅した要覧、インターネットと一般的なネットワーキングに関する用語集などが含まれています。
このマニュアルでも、また Solaris 7 システム管理者セットに含まれる他のマニュアルでも、随所で関連の RFC が参照されています。
InterNic Directory and Database Service には、RFC の蓄積が維持されています。インターネットに接続している場合は、次のようにしてオンラインで RFC を検索できます。
ftp を用いる場合は、InterNic ディレクトリおよびデータベースサーバー ds.internic.net に要求を送ります。要求の形式は次のとおりです。
rfc/rfc.rfcnum.txt または rfc/rfc.rfcnum.ps
rfcnum は、入手したい RFC の番号です。たとえば、RFC 1540 を PostScript 形式で検索したい場合、rfc/rfc.1540.ps という要求を出します。
電子メールを用いる場合は、米国の mailserv@ds.internic.net に電子メールを送ります。これは自動サーバーなので、要求メッセージのボディーは次の形式になっている必要があります。
document-by-name rfcrfcnum.txt
end
または
document-by-name rfcrfcnum.ps
end
World Wide Web ブラウザを用いる場合は、URL http://ds.internic.net/ds/dspg1intdoc.html を指定します。ホームページは次のとおりです。http://ds.internic.net
RFC のオンラインインデックスを必要とする場合は、 document-by-name rfc-index という要求を含んだメッセージを、米国の ds.internic.net に電子メールで送ってください。
インターネットは急速に成長しているので、上記に示したアドレスは、本書をお読みになる時点には変更されている場合があります。