Solaris のシステム管理 (IP サービス)

第 2 章 TCP/IP (概要)

この章では、Solaris 実装の TCP/IP ネットワークプロトコル群を紹介します。この章の情報は、まだあまり TCP/IP に慣れていないネットワーク管理者を対象としています。 TCP/IP の経験のあるネットワーク管理者の場合は、実行する作業について説明する章だけ参照してもかまいません。

この章では、以下の内容について説明します。

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

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

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

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

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

プロトコル層と OSI モデル

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

OSI 参照モデル

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

OSI 参照モデルでは、プロトコル層を上 (第 7 層) から下 (第 1 層) へ並べて表します。次の表に OSI 参照モデルを示します。

表 2–1 OSI (開放型システム間相互接続) 参照モデル


層番号	層の名前	説明
7	アプリケーション	誰でも使用できる標準の通信サービスとアプリケーション
6	プレゼンテーション	情報が解読可能な形で受信側マシンに渡されるようにする
5	セッション	連携コンピュータ間の接続と終了を管理する
4	トランスポート	データの転送を管理する。また、受信されたデータと送信されたデータが同じになることを保証する
3	ネットワーク	ネットワーク間でのデータのアドレス指定と配送を管理する
2	データリンク	ネットワークメディアを通過するデータの転送を取り扱う
1	物理	ネットワークハードウェアの特性を定義する

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

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

OSI モデルはプロトコルファミリを使用する理想的なネットワーク通信について規定します。TCP/IP は OSI モデルに直接対応していません。TCP/IP は、いくつかの OSI 層を合併して 1 つの層にしたり、一部の層をまったく使用していません。次の表は、Solaris 実装の TCP/IP の層を示しています。最上位層 (アプリケーション) から最下位層 (物理ネットワーク) まで並べてあります。

表 2–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 は次の機能を受け持ちます。

IP アドレス指定 - IP アドレス指定の規則は IP プロトコルの一部です。IPv4 アドレス指定については、第 3 章「TCP/IP ネットワークの計画 (手順)」で詳しく説明します。IPv6 アドレス指定については、第 14 章「IPv6 (概要)」で詳しく説明します。

ホスト間通信 - IP は、受信側ホストの IP アドレスに基づいてパケットが進む経路を決定します。

パケット形式設定 - IP は、パケットを IP データグラムと呼ばれる単位に組み立てます。データグラムについては、インターネット層で詳しく説明します。

フラグメント化 - パケットが大きすぎてネットワークメディアを介して転送できないときは、送信側ホストの IP は、パケットを小さいフラグメントに分割します。受信側ホストの IP は、これらのフラグメントを組み立てて元のパケットに戻します。

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

用語 IP を使用している説明は、IPv4 と IPv6 の両方に適用されます。
用語 IPv4 を使用している説明は、IPv4 のみに適用されます。
用語 IPv6 を使用している説明は、IPv6 のみに適用されます。

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 は、受信側ホストと送信側ホストとの間の接続の検査は行いません。UDP は接続の確立と検査を省略するので、少量のデータを送信するアプリケーションにとっては、TCP よりも効率的です。

アプリケーション層

アプリケーション層は、誰でも使用できる標準的なインターネットサービスとネットワークアプリケーションを定義します。これらのサービスとトランスポート層の両方の働きにより、データの送受信が行われます。アプリケーション層のプロトコルは多数存在します。以下に、アプリケーション層プロトコルの例を示します。

標準 TCP/IP サービス。たとえば、ftp、tftp、telnet コマンドなど
UNIX の “r” (リモート) コマンド。たとえば、 rlogin や rsh など
ネームサービス。たとえば、NIS+ やドメインネームシステム (DNS) など
ファイルサービス。たとえば NFS サービスなど
SNMP (ネットワーク管理用プロトコルの一種。Simple Network Mamagement Protocol の略)
RIP と RDISC ルーティングプロトコル

標準 TCP/IP サービス

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 のシステム管理 (資源管理とネットワークサービス)』に説明があります。ftp(1) のマニュアルページには、コマンドインタプリタによって呼び出されるすべての ftp コマンドオプションについての説明があります。 ftpd(1M) のマニュアルページには、 in.ftpd デーモンが提供するサービスについての説明があります。

Telnet - Telnet プロトコルは、端末と端末指向プロセスが、TCP/IP を実行するネットワーク上で通信できるようにします。このプロトコルは、telnet プログラム (ローカルマシン上の) と in.telnetd デーモン (リモートマシン上の) として実装されます。Telnet は、2 つのホストが文字単位または行単位で通信できるようなユーザーインタフェースを提供します。アプリケーションにはコマンドのセットが含まれていますが、これについては、telnet(1) のマニュアルページに詳しい説明があります。

TFTP - 簡易ファイル転送プロトコル (tftp) は ftp に似た機能を備えていますが、ftp の対話型接続を確立する機能はありません。したがって、ユーザーは、ディレクトリの内容を表示したり、ディレクトリを変更したりすることはできません。ユーザーは、コピーするファイルのフルネームを知っている必要があります。tftp のコマンドセットについては、tftp(1) のマニュアルページに説明があります。

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

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

rcp
rlogin
rsh

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

ネームサービス

Solaris オペレーティング環境では、次のネームサービスを提供しています。

DNS - ドメインネームシステム (DNS) は TCP/IP ネットワーク用にインターネットが提供するネームサービスです。DNS は、ホスト名から IP アドレスに変換するサービスを提供します。また、メール管理用のデータベースとしての働きもします。このサービスの詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。 resolver(3RESOLV) のマニュアルページも参照してください。
/etc ファイル - ホストベースの UNIX™ のネーミングシステムは、最初はスタンドアロンの UNIX マシン用に開発された後、ネットワークで使用されるように改良されました。UNIX オペレーティングシステムの旧バージョンの多くや UNIX マシンでは、現在でもこのシステムが使用されていますが、大規模で複雑なネットワークにはあまり適切ではありません。
NIS - ネットワーク情報サービス (NIS) は DNS とは独立して開発され、目的はやや異なっています。DNS は数値 IP アドレスの代わりにマシン名を使うことによって、通信を簡略化することに焦点を当てているのに対して、NIS の場合は、多様なネットワーク情報を集中管理することによりネットワーク管理機能を高めることに焦点を絞っています。NIS には、マシンの名前とアドレス、ユーザー、ネットワークそのもの、ネットワークサービスについての情報も格納されます。NIS 名前空間情報は NIS マップに格納されています。NIS アーキテクチャーと NIS 管理の詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。
NIS+ - NIS+ は、ホスト名から IP アドレスと Ethernet アドレスへのマッピング、パスワードの検査など、ネットワーク管理サービスに対する集中制御の機能を提供します。『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
FNS - フェデレーテッド・ネーミング・サービス (FNS) を使うと、単独の Solaris オペレーティング環境で複数の異なるネームサービスを使うことができます。FNS を使用すれば、ネットワーク上のさまざまなネームサービスすべてに、1 つの簡単なネーミングシステムインタフェースで対応できます。FNS は、X/Open federated naming (XFN) 規格に適合しています。FNS は、NIS+、NIS、DNS、/etc ファイルの代わりとして使用することはできません。FNS はむしろこれらのサービスの一番上に位置しており、共通の名前をデスクトップ上のアプリケーションで使用できるようにします。『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。

ディレクトリサービス

Solaris オペレーティング環境では、iPlanet Directory Server 5.x やその他の LDAP ディレクトリサーバーと関連して LDAP (Lightweight Directory Access Protocol) をサポートします。ネームサービスとディレクトリサービスの違いは、拡張機能の差です。ディレクトリサービスはネームサービスと同じ機能のほかに、追加機能を提供します。『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

ファイルサービス

NFS アプリケーション層プロトコルは、Solaris オペレーティングシステム用のファイルサービスを提供します。NFS サービスの詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』を参照してください。

ネットワーク管理

SNMP (Simple Network Management Protocol) を使うと、ネットワークのレイアウトを表示し、主要マシンの状態を表示できます。また、GUI ベースのソフトウェアで複雑なネットワーク統計情報を参照できます。多くの企業が、SNMP を実装するネットワーク管理パッケージを提供しています。SunNet Manager^TM はその一例です。

ルーティングプロトコル

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

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

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

送信側ホストの各層のプロトコルは、受信側ホストのそれぞれの対等プロトコルとの間で対話します。図 2–1に、この対話がどのように行われるかを示します。

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

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

図 2–1 パケットが TCP/IP スタックを通過する方法

この図では、送信側ホストから受信側ホストへ、パケットが TCP/IP スタックを通過する方法を示しています。

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

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

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

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

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

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

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

TCP のセグメンテーション

TCP はしばしば「接続指向型」プロトコルと呼ばれますが、これは、TCP が、受信側ホストにデータが正常に到達したかどうかを確認するからです。図 2–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 相ハンドシェークを使用しません。

インターネット層

図 2–1 に示したように、TCP と UDP はどちらもセグメントとパケットを下位のインターネット層に送り、セグメントとパケットはそこで IP プロトコルにより処理されます。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 は、RST パケットにより接続が終了したときに、TCP 通信のログを記録することで内部トレースをサポートします。 RST パケットが送信または受信されたときに、直前に送受信された最大 10 パケットの情報が接続情報とともにログに記録されます。

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

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 』 - インターネットを介して情報を検索するためのさまざまなツールの使用に関心がある方にとって最適です。

RFC と FYI

IAB (Internet Architecture Board) は、パブリックドメインで公開する前にすべての RFC を承認する必要があります。一般に、RFC の中の情報は開発者やその他の高度の専門知識を持つ読者を対象として設計されています。

一般に、FYI (For Your Information) 文書は RFC のサブセットとして発行されます。FYI には、インターネット規格を取り扱うような内容は含まれていません。むしろ、インターネットのもっと一般的な性格に関する情報を扱うものです。たとえば、FYI 文書には、TCP/IP の入門書や資料の目録、また、あらゆるインターネット関連のソフトウェアツールを網羅した要覧、インターネットと一般的なネットワーキングに関する用語集などが含まれています。

このマニュアルでも、また Solaris システム管理者セットに含まれる他のマニュアルでも、関連の RFC が参照されています。