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

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 パケットの情報が、接続情報とともにログに記録されます。