test

Solaris のシステム管理 (第 3 巻)

第 4 章 TCP/IP の概要

この章では、Solaris 実装の TCP/IP ネットワークプロトコル群を紹介します。この章の情報は、まだあまり TCP/IP に慣れていないネットワーク管理者を対象としています (ネットワークの基本概念の紹介については、第 2 章「ネットワークサービスの概要」を参照してください)。TCP/IP の経験のあるネットワーク管理者の場合は、この章では以下の項目について説明します。

インターネットプロトコル群の概要

この節では、TCP/IP を構成するプロトコルについて詳しく紹介します。ここに示す情報は概念的なものですが、各プロトコルの名前とそれぞれの働きを理解することができます。TCP/IP 関係の書籍は、どれもここに示す概念を理解していることを前提として書かれているので、この情報は重要です。

TCP/IP は、インターネットプロトコル群を形成するネットワークプロトコルの集合を示すニックネームとして使用されています。多くの書籍では、「インターネット」という用語は、プロトコル群と広域ネットワークの両方を表すものとして使用されています。本書では、「TCP/IP」は特にインターネットプロトコル群を表し、「インターネット」は広域ネットワークとそれを運営する組織を表すものとします。

TCP/IP ネットワークと他のネットワークとを相互接続するには、一意な IP ネットワーク番号を入手する必要があります。本書を作成した時点では、IP ネットワーク番号は、InterNIC と呼ばれる組織によって割り当てられていました。

ネットワーク上のホストがインターネットドメイン名システム (DNS) に参加する場合は、一意なドメイン名を入手し登録する必要があります。InterNIC は、いくつかのトップレベルのドメイン、たとえば .com (商業)、.edu (教育)、.gov (政府) などのドメインの傘下にあるドメイン名の登録も行なっています。InterNIC については、第 5 章「TCP/IP ネットワークの計画」で詳しく説明します (DNS についての詳細は、『Solaris ネーミングの管理』を参照してください)。

プロトコル層と OSI モデル

ほとんどのネットワークプロトコル群は、一連の層として構築されており、これはしばしば総称的にプロトコルスタックと呼ばれます。各層はそれぞれ特定の目的のために設計されていて、送信側ホストと受信側ホストの両方に存在しています。一方のマシンの特定の層が、相手のマシンの対等プロセスが送受信するオブジェクトと同じものを送受信するように設計されています。このような動作は、問題の層の上下の層で進行していることとは独立して行われます。つまり、ホストの各層は、同じマシンの他の層から独立して、他のホストの同じ層と協調して働きます。

OSI 参照モデル

ほとんどのネットワークプロトコル群が層の形に構造化されているとみなされるのは、国際標準化機構 (ISO) が設計した開放型相互接続 (OSI) 参照モデルの結果です。OSI モデルは、ネットワーク活動が 7 つの層から成る構造を持ち、それぞれの層に 1 つまたは複数のプロトコルが関連付けされるものと規定しています。層は、連携するネットワーク相互間でのすべての種類のデータ転送に共通するデータ転送操作を表します。

OSI 参照モデルのプロトコル層は、通常は表 4-1 に示すように、上 (層 7) から下 (層 1) へ並べて表します。

表 4-1 開放型相互接続参照モデル

層番号 

層の名前 

説明 

7 

アプリケーション

誰でも使用できる標準の通信サービスとアプリケーション 

6 

プレゼンテーション

情報が解読可能な形で受信側マシンに渡されるようにする 

5 

セッション

連携コンピュータ間の接続と終了を管理する 

4 

トランスポート

データの転送を管理し、受信されたデータと送信されたデータが同じになるようにする 

3 

ネットワーク

ネットワーク間でのデータのアドレス指定と配送を管理する 

2 

データリンク

ネットワークメディアを通過するデータの転送を取り扱う 

1 

物理

ネットワークハードウェアの特性を定義する 

OSI モデルにより定義されている動作は概念的なものであり、特定のネットワークプロトコル群に特有のものではありません。たとえば、OSI ネットワークプロトコル群は、OSI 参照モデルの 7 つの層をすべて実装しています。TCP/IP は、OSI モデルの層のいくつかを使用し、その他を合併しています。その他のネットワークプロトコル、たとえば SNA では、8 番目の層が追加されています。

TCP/IP プロトコルアーキテクチャモデル

TCP/IP は、いくつかの OSI 層を合併して 1 つの層にしていたり、またまったく使用しない層があったりするため、このモデルに直接対応しているとは言えません。表 4-2 は、Solaris 実装の TCP/IP の層を示しています。最上位の層 (アプリケーション) から最下位の層 (物理ネットワーク) まで並べてあります。

表 4-2 TCP/IP プロトコルスタック

OSI 参照の層番号 

対応する OSI 層 

TCP/IP 層 

TCP/IP プロトコルの例 

5,6,7 

アプリケーション、セッション、プレゼンテーション 

アプリケーション

NFS、NIS+、DNS、telnet、ftp、rlogin、rsh、rcp、RIP、RDISC、SNMP、その他

4 

トランスポート  

トランスポート

TCP, UDP 

3 

ネットワーク 

インターネット

IP, ARP, ICMP 

2 

データリンク 

データリンク

PPP, IEEE 802.2 

1 

物理 

物理ネットワーク

Ethernet (IEEE 802.3) トークンリング、RS-232、その他 

この表は、TCP/IP プロトコルの層、対応する OSI モデルの層、および TCP/IP プロトコルスタックの各レベルで使用できるプロトコルの例を示しています。通信トランザクションに関与する各ホストは、それぞれ独自の実装によるプロトコルスタックを実行します。

物理ネットワーク層

物理ネットワーク層は、ネットワークに使用するハードウェアの特性を規定します。たとえば、通信メディアの物理特性を規定します。TCP/IP の物理層はハードウェア規格を意味しています。たとえば、Ethernet ネットワークメディアの仕様である IEEE 802.3 や、標準ピンコネクタの仕様である RS-232 などです。

データリンク層

データリンク層は、パケットのネットワークプロトコルの種類を識別します。この場合は TCP/IP です。また、この層には、エラー制御と「フレーミング」の働きもあります。データリンク層の例としては、Ethernet IEEE 802.2 フレーミングと、ポイントツーポイントプロトコル (PPP) フレーミングがあります。

インターネット層

この層はネットワーク層とも呼ばれるもので、ネットワークに対してパケットを受け入れたり、配送したりします。この層には、強力なインターネットプロトコル (IP)、アドレス解決プロトコル (ARP)、インターネットコントロールメッセージプロトコル (ICMP) が組み込まれています。

IP プロトコル

IP プロトコルとそれに関連したルーティングプロトコルは、TCP/IP 群全体の中でたいへん重要なものです。IP は次の機能を受け持ちます。

前のリリースの Solaris オペレーティング環境では、インターネットプロトコルバージョン 4 (IPv4 と記述される) が実装されていました。しかし、インターネットの急速な成長によって、アドレス空間の拡張など、機能強化された新しいインターネットプロトコルを開発する必要が生じました。バージョン 6 として知られるこの新バージョンは IPv6 と記述されます。Solaris オペレーティング環境では、両方のバージョンを使用することができます。インターネットプロトコルについて言及するときに混乱を避けるため、以下の規則を適用します。

ARP プロトコル

アドレス解決プロトコル (ARP) は、データリンク層とインターネット層の間に概念的に存在するものです。ARP は、Ethernet アドレス (48 ビット長) を既知の IP アドレス (32 ビット長) にマッピングし、IP はこの情報に基づいてデータグラムを正しい受信側ホストに向けることができます。

ICMP プロトコル

インターネット制御メッセージプロトコル (ICMP) は、ネットワークエラー条件の検出とその報告を担当するプロトコルです。ICMP は以下の事項について報告します。

「ping コマンド」の節には、エラー検出に ICMP を使用するオペレーティングシステムコマンドについての詳細な説明があります。

トランスポート層

TCP/IP トランスポート層プロトコルは、パケットが正しい順序でエラーなしに到着するようにするために、データ受領の肯定応答を交換し、失われたパケットがあれば転送し直します。この種類の通信を「終端間」通信と呼びます。このレベルのトランスポート層プロトコルは、トランスミッションコントロールプロトコル (TCP) とユーザーデータグラムプロトコル (UDP) です。

TCP プロトコル

TCP は、物理的な回線で接続されているのと同じようにしてアプリケーション相互間の通信ができるようにします。TCP は、独立したパケットの形ではなく、文字単位で転送されているような形でデータを送信します。この転送では、まず開始ポイントで接続がオープンされ、次にバイト順序ですべてのデータが転送され、終了ポイントで接続がクローズされます。

TCP は、転送するデータにヘッダーを添付します。このヘッダーには、送信側マシン上のプロセスが受信側マシン上の対等プロセスに接続できるようにするための、多数のパラメータが含まれています。

TCP は、送信側ホストと受信側ホストとの間に終端間接続を確立することにより、パケットが宛先に到達したことを確認します。したがって、TCP は、「信頼性の高い接続指向型」プロトコルとみなすことができます。

UDP プロトコル

もう 1 つのトランスポート層プロトコルである UDP は、データグラム配送サービスを提供します。受信側ホストと送信側ホストとの間で接続が達成されているかどうかを検査する手段は提供しません。UDP は接続の確立と検査を省略するので、少量のデータを送信するアプリケーションにとっては、TCP よりも効率的です。

アプリケーション層

アプリケーション層は、誰でも使用できる標準的なインターネットサービスとネットワークアプリケーションを定義します。これらのサービスとトランスポート層の両方の働きにより、データの送受信が行われます。アプリケーション層のプロトコルにはさまざまのものがあり、そのうちのいくつかは、すでに使用しているでしょう。以下に、この種のプロトコルの例をいくつか挙げます。

標準 TCP/IP サービス

UNIX の "r" (リモート) コマンド

UNIX の "r" (リモート) コマンドを使用すると、ユーザーは、指定したリモートホストで実行したいコマンドを、各自のローカルマシンで発行することができます。この種のコマンドには次のものがあります。

これらのコマンドの使い方については、rcp(1)、rlogin(1)、rsh(1) の各マニュアルページに説明されています。

ネームサービス

Solaris 実装の TCP/IP では、NIS+ と DNS の 2 つのネームサービスが使用できます。

ファイルサービス

NFS アプリケーション層プロトコルは、Solaris オペレーティングシステム用のファイルサービスを提供します。NFS サービスについての詳細は、第 29 章「Solaris NFS の環境」で説明しています。

ネットワーク管理

SNMP (ネットワーク管理用プロトコルの一種。Simple Network Management Protocol) を使用すると、ネットワークのレイアウトを表示し、主要マシンの状態を表示し、さらに、その他の複雑な統計情報をグラフィカルユーザーインタフェースを持つソフトウェアから得ることができます。多くの企業が、SNMP を実装するネットワーク管理パッケージを提供しています。SunNet ManagerTM はその一例です。

ルーティングプロトコル

TCP/IP ネットワーク用の 2 つのルーティングプロトコルとして、RIP (Routing Information Protocol) と RDISC (Router Discovery Protocol) があります。これらのプロトコルについては、「ルーティングプロトコル」で説明します。

TCP/IP プロトコルがデータ通信を行う方法

ユーザーが TCP/IP アプリケーション層プロトコルを使用するコマンドを発行すると、一連のイベントが発生します。ユーザーのコマンドまたはメッセージは、ローカルマシン上の TCP/IP プロトコルスタックを通過し、ネットワークメディアを通り、受信側のプロトコルに到達します。送信側ホストの各層のプロトコルにより、オリジナルのデータに情報が付加されていきます。

ユーザーのコマンドがプロトコルスタックを通過していくとき、送信側ホストの各層のプロトコルは、受信側ホストのそれぞれの対等プロトコルとの間で対話します。図 4-1 に、この対話がどのように行われるかを示します。

データのカプセル化と TCP/IP プロトコルスタック

パケットは、ネットワーク上を転送される情報の基本単位で、少なくとも、送信側ホストと受信側ホストのアドレスが入ったヘッダーと、転送するデータが入ったボディーが含まれています。パケットが TCP/IP プロトコルスタックを通過するとき、各層のプロトコルは、基本ヘッダーにフィールドを追加したり、そこからフィールドを削除したりします。送信側ホストのプロトコルがパケットヘッダーにデータを追加する場合、その動作をデータのカプセル化と呼びます。また、変更後のパケットを表す言葉は、図 4-1 に示すように層によって異なります。

図 4-1 TCP/IP スタックを通過するパケット

Graphic

この節では、ユーザーがコマンドを発行するかまたはメッセージを送信してから、それを受信側ホストの該当のアプリケーションが受け取るまでの、パケットのライフサイクルを要約して示します。

アプリケーション層 - ユーザーが通信を開始

パケットの履歴は、あるホストのユーザーが、リモートホストへのアクセスを必要とするようなメッセージを送信するかコマンドを発行した時点から始まります。そのコマンドまたはメッセージに関連付けられているアプリケーションプロトコルは、対応する TCP か UDP のどちらかのトランスポート層プロトコルで取り扱えるように、パケットの形式を設定します。

図 4-1 に示したように、ユーザーが、リモートホストにログインするために rlogin コマンドを発行したとします。rlogin コマンドは TCP トランスポート層プロトコルを使用します。TCP は、コマンド内の情報を含むデータをバイトストリーム形式で受け取るものと仮定しています。したがって、rlogin はこのデータを TCP ストリームとして送信します。

しかし、すべてのアプリケーション層プロトコルが TCP を使用するわけではありません。あるユーザーが、リモートホストのファイルシステムをマウントしようとして、NIS+ アプリケーション層プロトコルを開始したとします。NIS+ は UDP トランスポート層プロトコルを使用します。したがって、このコマンドを含むパケットは、UDP が仮定しているような方法に形式化する必要があります。この種類のパケットをメッセージと言います。

トランスポート層 - データのカプセル化の開始

データがトランスポート層に到着すると、この層のプロトコルはデータのカプセル化を開始します。最終的な結果は、TCP と UDP のどちらが情報を処理したかによって異なります。

TCP のセグメンテーション

TCP はしばしば「接続指向型」プロトコルと呼ばれますが、これは、このプロトコルが、受信側ホストにデータが正常に到達したかどうかを確認するからです。 図 4-1 に、TCP プロトコルが rlogin コマンドからのストリームをどのように受け取るかを示してあります。TCP は、アプリケーション層から受け取ったデータをセグメントに分割し、各セグメントにヘッダーを添付します。

セグメントヘッダーには、送信側と受信側のポート、セグメント順序に関する情報、検査合計と呼ばれるデータフィールドが含まれています。両方のホストの TCP プロトコルがこの検査合計データを使用して、データがエラーなしに転送されたかどうかを判別します。

TCP 接続の確立

TCP は、受信側ホストでデータ受信の準備が整っているかどうかを判別するためにも、セグメントを使用します。送信側 TCP は、接続を確立するために、受信側ホストで実行されている対等 TCP プロトコルに SYN と呼ばれるセグメントを送ります。受信側 TCP は ACK と呼ばれるセグメントを戻して、セグメントを正しく受信したことを知らせます。送信側 TCP は新たな ACK セグメントを送信して、それからデータの送信を開始します。このような制御情報の交換を「3 相ハンドシェーク」と呼びます。

UDP パケット

UDP は「コネクションレス」プロトコルです。TCP の場合と異なり、UDP は、受信側ホストにデータが到達したかどうかを確認しません。そのかわりに、UDP は、アプリケーション層から受け取ったメッセージを「UDP パケット」に形式化します。UDP は、各パケットにヘッダーを付加します。ヘッダーには、送信側ホストと受信側ホストのポート、パケットの長さを示すフィールド、検査合計が含まれています。

送信側 UDP プロセスは、受信側ホストの対等 UDP プロセスにパケットを送ろうとします。アプリケーション層は、受信側 UDP プロセスが、パケットを受信したことを示す肯定応答を戻すかどうかを判別します。UDP は受領の通知を必要としません。UDP は 3 相ハンドシェークを使用しません。

インターネット層

図 4-1 に示したように、TCP と UDP はどちらもセグメントとパケットを下位のインターネット層に送り、セグメントとパケットはそこで IP プロトコルにより処理されます。IP は、セグメントとパケットを IP データグラムと呼ばれる単位に形式化して、配送の準備を整えます。次に、IP はデータグラムの IP アドレスを判別して、受信側ホストへの効率的な配送ができるようにします。

IP データグラム

IP は、TCP または UDP が付加した情報に付け加える形で、セグメントまたはパケットのヘッダーに「IP ヘッダー」を付加します。IP ヘッダーには、送信側ホストと受信側ホストの IP アドレス、データグラムの長さ、データグラムのシーケンス番号が含まれます。これらの情報が付加されるのは、データグラムがネットワークパケットとしての許容バイトサイズを超過してフラグメント化が必要になった場合に備えるためです。

データリンク層 - フレーミングの実施

PPP などのデータリンク層プロトコルは、IP データグラムをフレームの形に形式化します。これらのプロトコルは、第 3 のヘッダーとフッターを付加することにより、データグラムを「フレーミング」します。フレームヘッダーには、フレームがネットワークメディアを通過するときのエラーを検査するための、巡回冗長検査 (CRC) フィールドが含まれています。次に、データリンク層は物理層にフレームを渡します。

物理ネットワーク層 - フレームの転送準備

送信側ホストの物理ネットワーク層は、フレームを受け取ると、IP アドレスをネットワークメディアに合わせたハードウェアアドレスに変換します。次に、物理ネットワーク層は、フレームをネットワークメディアに送り出します。

受信側ホストでのパケットの取り扱い

受信側ホストに到着したパケットは、送信側ホストのときと逆の順序で TCP/IP プロトコルスタックを通過します。 図 4-1 にこの経路を示してあります。受信側ホストの各プロトコルは、送信側ホストの対等プロトコルがパケットに付加したヘッダー情報を取り除きます。この処理の順序を以下に示します。

  1. 物理ネットワーク層はフレーム形式のパケットを受け取ります。パケットの CRC を計算し、データリンク層にフレームを送ります。

  2. データリンク層はフレームの CRC が正しいかどうかを検査し、フレームヘッダーと CRC と取り除きます。最後に、データリンクプロトコルは、インターネット層にフレームを送ります。

  3. インターネット層はヘッダーの情報を読み、転送の種別を識別して、それがフラグメントであるかどうかを判別します。その転送がフラグメントである場合は、IP は、フラグメントを組み立て直して、オリジナルのデータグラムに戻します。そして、IP ヘッダーを取り除いてから、データグラムをトランスポート層プロトコルに渡します。

  4. トランスポート層 (TCP と UDP) はヘッダーを読んで、どのアプリケーション層プロトコルにデータを渡すかを判断します。次に、TCP または UDP は、自分に関連するヘッダーを取り除き、メッセージまたはストリームを受信アプリケーションに送ります。

  5. アプリケーション層はメッセージを受け取り、送信側ホストから要求された操作を行います。

TCP/IP 内部トレースのサポート

TCP/IP は、RTS パケットにより接続が終了したときに、TCP 通信のログを記録することで内部トレースをサポートします。RTS パケットが送信または受信されたときに、その接続上で直前に送信または受信された最大 10 パケットの情報が、接続情報とともにログに記録されます。

TCP/IP とインターネットについてもっと詳しく知るには

TCP/IP とインターネットについては、膨大な量の情報が出版されています。本書で説明していない特別な情報は、以下に挙げる情報源からも入手できます。

市販のコンピュータ関係書籍

地域の図書館やコンピュータ関係の書店に、TCP/IP とインターネットに関する多数の書籍がそろっています。中でも特にお勧めしたいのは次の書籍です。

RFC と FYI

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 システム管理者セットに含まれる他のマニュアルでも、関連の RFC が参照されています。

InterNic Directory and Database Service には、RFC の蓄積が維持されています。インターネットに接続している場合は、次のようにしてオンラインで RFC を検索できます。

RFC のオンラインインデックスを必要とする場合は、 document-by-name rfc-index という要求を含んだメッセージを、米国の ds.internic.net に電子メールで送ってください。

注 -

インターネットは急速に成長しているので、上記に示したアドレスは、本書をお読みになる時点には変更されている場合があります。