トランスポート層プロトコル

311
第 12 章
トランスポート層プロトコル
IP は、媒体に対する透過的なインターフェイスと、ほかのノードに到達
するためのアドレス機構を提供する。これらのサービスを拡張して、アプ
リケーション層の適切なサービスにデータグラムを渡したり、必要なアプリ
ケーションに信頼性の高いストリームサービスを提供しなければならない。
このようなサービスは、UDP および TCP というトランスポート層プロトコ
ルにより、IP 層に提供される。
本章では、次の項目について説明する。
●
UDP が提供するサービス
●
TCP が提供するサービス
●
信頼性について
●
ポート
●
ソケット
●
設定のオプション
312
第 12 章トランスポート層プロトコル
ここまでは、データリンク層のフレームと IP 層のデータグラムについて
説明してきた。IP のデータは、IP データグラムにカプセル化され、さらに
フレームにカプセル化される。トランスポート層では、UDP または TCP と
。ユーザーアプリ
いう 2 つの異なるプロトコルが存在する（図 12-1 を参照）
ケーションで要求されるサービスの種類に応じて、この 2 つのプロトコルの
いずれかが IP データグラムのデータフィールドで伝送される。
アプリケーション
TCP
UDP
IP
データリンク
物理
図 12-1 UDP と TCP
IP が情報を適切なコンピュータに転送すると、そのコンピュータでアプリ
ケーション層の適切なサービスに情報を渡す。トランスポート層では、多数
のアプリケーションと IP 層の間でデータの多重化や多重分離を行ったり、適
切なアプリケーションにデータを渡す。また、アプリケーションに対して、
エラーがないフロー制御（つまりコネクション型）のデータストリームサー
ビスを提供したり、IP のコネクションレス型のサービスを単純に提供するの
もトランスポート層である。
UDP（ User Datagram Protocol ）は信頼性が低いコネクションレス型の
サービスを提供する。UDP では、接続を確立する必要がなく、1 台または複
数のコンピュータにデータを転送することができる。データグラムがリモー
トノードに送信されたときには、各データグラムの着信を示すために応答を
返す必要がない。特定の環境では、このような伝送方式がもっとも効率的に
なる。TFTP や NFS などのアプリケーションサービスは、UDP 方式で伝送
を行う。ブロードキャストが必要になる場合には、必ず UDP を使う。
TCP（ Transmission Control Protocol ）は、コネクション型のサービスを
提供する。接続は、2 つの点の間に流れるデータのパイプにたとえることが
できる。TCP には、ブロードキャストまたはマルチキャストの機能はない。
TCP は、2 台のコンピュータの間で、信頼性が高いサービスを提供するため
に必要な機能を備えている。TCP では信頼性を向上させるために、肯定応
答、フロー制御、タイマ、接続管理機能を管理する大量のオーバーヘッドが
付加される。要求される処理能力と利用するネットワークヘッダーのサイズ
12.2 ソケット
313
という観点から、TCP のオーバーヘッドは UDP よりも大きい。Telnet や
FTP などのアプリケーションでは、TCP を利用する。
12.1 ポート
UDP および TCP では、アプリケーション層の適切なサービスに情報を配
信するためにポートアドレスを利用する。これは既知のポートを示す 16 ビッ
トのアドレスで、0∼255 の範囲で定義される（図 12-2 を参照）
。言い換える
と、ポート番号は、Telnet や FTP などの一般的なアプリケーション層サー
ビスに割り当てられている。アプリケーションの開発時に UDP または TCP
上で動作するプログラムを作成する場合、利用するポートを定義するが、特
定のコンピュータ上でそのポート番号が一意であり、少なくとも既知のポー
ト番号として予約された値の範囲外であるように設定しなければならない。
このようにポートを固定的にバインドする方法に対して、動的にバインド
する方法もある。たとえば、NFS では、ポートのマッピングサービスを利用
する。このサービスでは、新しいポートの定義や登録を動的に行い、要求に
応じて特定のサービスに使われているポートを検出する。ポートのマッピン
グサービスについては、第 15 章「 NFS 」で詳細に説明する。
トランスポート層
FTP
Telnet
161
SMTP
111
TFTP
SNMP
アプリケーション層
Sun RPC
既知のポート番号は、付録 G「既知のポート」に掲載する。
69
25
21
23
UDP
TCP
サービスに
利用される
ポート番号
図 12-2 UDP および TCP で使われるポート
12.2 ソケット
ソケットという用語は、TCP/IP に関連して使われることが多く、非常に
単純だが、重要な概念である。ソケットとは、IP アドレスとポート番号を
連結したものだ。すべてのノードが登録された IP アドレスを利用する場合、
IP アドレスは原則として 1 つのノードに対して一意であり、ポートはその
ノード上で一意であるため、ソケットはアプリケーション層のサービスに対
して一意の ID を提供する。ソケットの参照が一意であるため、UDP および
TCP ではチェックサムの計算に IP アドレスとポート番号を含める。これは、
データグラムが不適切なホストに着信した場合、ポートが既知のものでホス
314
第 12 章トランスポート層プロトコル
ト上に存在する可能性があっても、そのホストのトランスポート層がデータ
＊1
グラムを受け入れないようにするためである。
アプリケーション層の多くのサービスでは複数のセッションを受け入れる
ため、各セッションを識別して、データを適切なコンピュータに送信する必
要がある。たとえば、複数のユーザーが Telnet（ポート番号は 23 ）を使って
同じホストに接続する場合、ユーザーはすべて同じ Telnet のポートを利用
してアクセスを行うことになる。異なるセッションを識別する場合、データ
グラムの発信元の IP アドレスを調べる方法があるが、同じホストから 2 人
のユーザーが 1 つのアプリケーションに接続する可能性もある。このような
場合、セッションの識別は非常に難しい。
この問題を解決するため、既知のポート番号は、サーバーのアプリケー
ション層のサービスにのみ使われる。クライアントアプリケーションは、対
象のコンピュータ上で使われていない一意のポート番号を選択する。この方
法により、1 つのクライアントから同一のサーバーに対して 2 つのセッショ
ンが確立されている場合でも、各セッションは一意であるために発信元のソ
ケットを利用して 2 つのセッションを簡単に区別できる。アプリケーション
層のサービスは発信元のソケットにデータを返すため、2 台のコンピュータ
間で行われる通信には発信元の IP アドレスとポートの両方が含まれる。
ピアツーピア方式で動作するサービスでは、送受信に同じポート番号を
利用するものもある。ルーティングや管理機能など、メッセージの返送時に
ポートを識別する必要がまったくないサービスにこのようなものが多い。
12.3 UDP
UDP は基盤となる IP のデータグラムサービスとほとんど変わらないが、
アプリケーション層の適切なサービスにデータを渡す処理を行う。UDP で
は、ヘッダーに含まれている発信元と送信先のポート番号に基づいてこの処
理を行う。UDP が IP に渡すデータブロックは UDP ヘッダーとアプリケー
ション層のデータから構成されるが、このデータブロックもデータグラムと
呼ばれる。図 12-3 に、UDP に付加されるフィールドを示す。次に、フィー
ルドの詳細を示す。
●
発信元ポート
データグラムが発信されたアプリケーション層サービスのポート番号で
ある。
＊1 IP ヘッダーに含まれる IP アドレスが破損し、誤ったコンピュータに着信する可能性
はある。IP のチェックサムが無視されると、トランスポート層に渡されてポートが調
べられる。
12.3 UDP
●
315
送信先ポート
データグラムの送信先になるアプリケーション層サービスのポート番号で
ある。
●
長さ
UDP データグラムの長さを示す。
●
チェックサム
UDP で伝送されるデータを保護するためのチェックサムを示す。
0
16
31
発信元ポート
送信先ポート
長さ
UDPチェックサム
データ
図 12-3 UDP ヘッダー
チェックサムはまったく基本的なもので、IP と同様に、ヘッダーとユーザー
データをすべて 16 ビットのワードに分割してそれぞれ 1 の補数を求め、そ
の結果を合計してさらに 1 の補数を求める。このチェックサムには、UDP の
フィールドだけではなく、IP 層の特定のフィールドに基づく擬似ヘッダーが
含まれるのが特徴的である（図 12-4 を参照）
。これは、チェックサムの計算
にポートだけでなくソケットも含めることを目的としている。
発信元IPアドレス
送信先IPアドレス
0
擬似ヘッダー
プロトコル
UDP長
発信元ポート
送信先ポート
長さ
0
UDPヘッダー
データ
データ
図 12-4 UDP のチェックサム
UDP データグラムの最大サイズを設定可能な製品もある。システム上に大
きなデータグラムを受信できないコンポーネントが存在する場合、サイズの
設定は必要だが、通常は最大サイズを設定することはない。MDS（ Maximum
Datagram Size ）を小さくするとホストに着信する UDP に必要なメモリの
容量は減少するが、同時に UDP を使うサービスのパフォーマンスが低下す
る。そのため、UDP データグラムの最大サイズのデフォルト値を変更する
必要はほとんどない。
316
第 12 章トランスポート層プロトコル
12.4 TCP
TCP は IP に信頼性を加え、UDP と同様にポートを使ってアプリケーショ
ン層のアドレスを指定する。TCP はコネクション型のプロトコルで、信頼
性が高く、あるコンピュータから別のコンピュータに通信を開始する場合に
接続を開く必要がある。送信が完了すると、接続は閉じられる。
TCP が IP に渡すデータブロックは一般的にセグメントと呼ばれ、TCP
ヘッダーとアプリケーション層のデータから構成されている。
高い信頼性を保持するために、次のような機能が要求される。
●
エラーの検出と訂正
●
フロー制御
●
シーケンスの調整
●
重複セグメントの削除
エラーの検出と訂正は、媒体や下位層のソフトウェアによるセグメントの
破損を処理する。フロー制御は、リソース上の制約により、送信側が受信側
の制限を超えないようにする。下位の IP 層は TCP セグメントが含まれる
データグラムを任意の順番で伝送する可能性があるため、シーケンスの調整
が必要になる。これは、連続するデータグラムが異なる経路で伝送される場
合に発生する。セグメントの重複は、TCP のエラー修復機能により発生す
ることがある。
TCP は次に示す方法でこれらの機能を実行する。
●
シーケンス番号を使ってデータを識別する。
●
正しい順序で受信されたデータにはポジティブ肯定応答が返される。
●
制限時間（設定可能）内に肯定応答が返されないセグメントを再送する。
続いて、各機能の詳細について説明する。
12.4.1 TCPヘッダー
前述の機能を実行するために、TCP ヘッダー（図 12-5 を参照）には UDP
より多くのフィールドが含まれ、はるかに複雑である。UDP と同様に、そ
して UDP と同じ理由から、このヘッダーにはアプリケーションを識別する
発信元と送信先のポート番号が格納される。そのほかのフィールドはほとん
どが、信頼性を維持し、接続を制御するために使われる。
12.4 TCP
発信元ポート
317
送信先ポート
シーケンス番号
肯定応答番号
データ
オフセット
予約
UA PRS F
R C S SY I
GKH TN N
ウィンドウ
緊急ポインタ
チェックサム
パディング
オプション
…
データ
図 12-5 TCP ヘッダー
●
シーケンス番号 32 ビット
エラー制御にシーケンス番号を利用するプロトコルでは、シーケンス番
号は送受信されたセグメント数＊2 を表すことが多い。しかし、TCP では、
シーケンス番号は送信されるストリームのオクテット数を表す。セグメン
トのヘッダーに含まれているシーケンス番号は、そのセグメントに格納さ
れているデータの最初のオクテットが、データストリーム全体で占める位
置を識別する。
接続の確立時に送受信を行うノード間で新しいシーケンス番号が決定され、
接続が開始する。コンピュータがクラッシュした場合にシステムの完全性
を維持するため、新しいシーケンス番号は 0 以外の値から開始する。
IP が必ず送信時と同じ順序でデータグラムを伝送する場合、データが常に
順番に着信するため、シーケンス番号は徐々に増加する。IP がデータを不
正な順序で伝送した場合にも、シーケンス番号により、TCP はセグメント
をデータストリームの正しい位置に組み込むことができる。
シーケンス番号は 32 ビットであるため、非常に高速なリンク上でもカウ
＊3
これ
ンタとして同じ値が再び利用されるまでの期間は非常に長くなる。
は、肯定応答が返されたセグメントと同じシーケンス番号を持つセグメン
トが受信された場合、そのセグメントがエラーの訂正処理による重複セグ
メントであることを意味する。重複セグメントは受け取られるが、処理せ
ずに廃棄される。
＊2 TCP では、セグメントという用語はトランスポート層における伝送の単位を示す。
ほかのプロトコルでは、パケットまたはフレームという用語が使われることが多い。
＊3 データを 2Mbps で連続的に送信した場合、2 の 32 乗分のオクテットを送信するため
には 9.5 時間を要する。
318
第 12 章トランスポート層プロトコル
●
肯定応答番号 32 ビット
肯定応答番号から 1 を引いた数のオクテットが、すべて正しく受信された
ことを示す。データの発信元が新しい値を受け取ると、再送に備えて保持
していたデータを破棄することができる。肯定応答番号は、ACK フラグ
が設定されている場合にのみ有効である。
肯定応答番号は、相手先から伝送されたシーケンス番号と正しい順序の
データが問題なく受信されたことを示す。肯定応答番号は、受信するデー
タストリームのうち、発信元が次にアプリケーションに渡すオクテットの
シーケンス番号が設定される（シーケンス番号が 0 であるオクテットは接
続の確立時にやり取りされる）
。このように、肯定応答番号は最後に受信さ
れた正しい順序のデータのオクテット数より 1 だけ大きくなる。したがっ
て、肯定応答番号は、次のセグメントで直接有効なデータを示すシーケン
ス番号と同じ値になる。
TCP では、一連のセグメントの中で次に位置する重要なセグメントが着
信に失敗したために、複数のセグメントが正しく受信されてはいるが、肯
定応答が返されていない状態も考えられる。この場合、低速なパス上で送
信されたために遅延が発生していたり、IP によって廃棄されたことが考え
られる。この場合、肯定応答番号は、再送タイマにより再送が行われ、必
要なセグメントが受信されるまで、値が変わることはない。詳細について
は、エラーの訂正と再送のタイムアウトの説明で取り上げる。
●
データオフセット 4 ビット
アプリケーションデータの開始位置の値を、32 ビットのワード単位で示す。
オプションを利用しない場合、この値は通常 5（ヘッダーが 20 オクテット
であることを意味する）になる。
●
フラグ 6 ビット
フラグは、ほかのフィールドが有効であることを示したり、接続を制御す
るために使われる。フラグには、次に示す 6 つのものが存在する。
●
URG 緊急ポインタフィールドが有効であることを示す。緊急ポインタ
フィールドは、データフィールドにおいて緊急データの末尾のオクテッ
トを指す。緊急データは、通常のデータストリームとはみなされず、そ
のほかのデータに優先して処理されなければならない。この機能は、な
んらかのシステムによって通常のデータの送受信が行われない場合を含
み、ネットワーク上で任意のメッセージをアプリケーションに渡さなけ
ればならない場合に利用することができる。プログラムの割り込みに使
うことも可能である。
●
ACK ほとんどのセグメント上に存在する肯定応答フィールドが有効で
あることを示す。肯定応答フィールドは、通常、接続の確立時に各ノー
ドがシーケンス番号と肯定応答番号に使う値を決定できるようになるま
での間のみ無効になる。肯定応答フィールドの値はセグメント間で変更
12.4 TCP
319
されることがないため、肯定応答フィールドが有効である場合にも新し
いデータの肯定応答が返されることはない。
●
PSH このフラグにより、リモートの TCP 層はこのセグメントを直ち
にアプリケーション層に引き渡す。TCP は、通常、受信したセグメント
のデータを保持し、大きなバッファに格納してからアプリケーションに
渡して処理のオーバーヘッドを軽減する。しかし、文字単位で端末を操
作する場合など、受信したデータが 1 オクテットだけでもバッファに蓄
積する処理が行われてはならない状況もある。
●
RST このフラグは、ほかのすべてが失敗した場合に使われる。エラー
が発生しており、接続を強制的に閉じる必要があることを示す（または、
接続を開く要求に対する応答として送信された場合、要求は拒否された
ことを示す）
。
●
SYN このフラグは、2 つのノード間で接続の確立を開始する際に使わ
れる。この段階では、どちらのノードも肯定応答番号に使われる値を認
識していない。接続の確立では SYN フラグを設定したセグメントを相
互にやり取りするが、それぞれのセグメントに対して ACK フラグが設
定されたセグメントにより肯定応答が返される。この後に、データの伝
送が可能になる。詳細については、後述する。
●
FIN このフラグは、接続の終了に使われる。接続の一方のノードで送
信するデータがなくなると、FIN フラグを設定したセグメントを送信す
る。接続上の両方のノードが FIN フラグのセグメントを送信すると、接
続が閉じられる。
●
ウィンドウ 16 ビット
ウィンドウは、ノードが接続に対して割り当てるバッファの総量を通知す
る。もう一方のノードは、肯定応答が返されていないデータを指定された
バッファ容量を超えて送信することはできない。
●
チェックサム 16 ビット
TCP のチェックサムは、ヘッダーとデータに対する基本的な検査方法であ
る。UDP の場合と同様に、ヘッダーとデータをすべて 16 ビットのワード
に分割して 1 の補数を求め、その結果を合計してさらに 1 の補数を求める。
●
緊急ポインタ 16 ビット
データフィールドにおいて、緊急とみなされ、直ちに対応しなければなら
ないデータの末尾を指す。このフィールドは、URG フラグが設定されて
いる場合にのみ有効である。
●
オプション可変長
一般的に TCP で使われる唯一のオプションは、MSS
（ Maximum Segment
Size ）である。MSS は、送信先の TCP 層に対して送信するセグメントの
最大サイズ（ TCP ヘッダーを含む）を通知する。
320
第 12 章トランスポート層プロトコル
このオプションの形式を図 12-6 に示す。種別の値が 2 の場合、MSS のオ
プションを示す。種別が 0 の場合にはオプション一覧終了を、1 の場合に
は操作なしを示す。長さフィールドは、オクテット単位でオプション全体
の長さ（種別フィールドおよび長さフィールドを含む）を示す。
●
パディング
オプションフィールドが有効な場合、パディングによりデータを 32 ビッ
ト境界に合わせ、データオフセットで正しい位置を示すように調整する。
（ a） 1オクテット
種別
または
1オクテット 1オクテット nオクテット
種別
（ b）種別
0
1
2
長さ
長さ
1
1
4
データ
説明
オプション一覧終了
操作なし
最大セグメントサイズ（MSS）
（ c）
000 0 0 0 1 0
00000100
00000100
00000000
種別 = 2（MSS）長さ = 4 データ = 0x0400
図 12-6 オプションの形式（ a ）、オプション（ b ）、使用例（ c ）
TCP の実装によっては、MSS を設定してノードが受信するセグメントの
最大サイズを構成することができる。この値は一般的に許容されている最大
値に設定され、小さなセグメントのオーバーヘッドを軽減する。しかし、受
信可能なフレームのサイズが限定されるハードウェアも存在するため、TCP
がハードウェアの処理能力を超えるようなオプションを受け取らないように
この値を設定する必要がある。
MSS の決定は、非常に複雑である。ルーターを含むシステムの場合、MSS の
（ Maximum
最大値として 556 を設定するために、576 オクテット以上の MTU
Transmission Unit ）
をサポートする必要がある
（ 556 は、576 から IP ヘッダー
の最小値である 20 オクテットを引いた値である）
。セグメントが小さいほど
応答は速くなるが、ネットワーク上のオーバーヘッドは非常に大きくなり、
特にルーティングが行われる接続では効率が下がる。フレームのサイズを大
きくすると効率は上がるが、バッファに蓄積する時間が原因で遅延が増大す
る。ネットワークのパス上でフレームが破損する傾向が見られる場合、サイ
ズが大きくなるほど破損の可能性は高くなる。したがって、フレームのサイ
ズを大きくすると、再送するデータ量が増え、ルーターおよびホストがフラ
グメント化と再組み立てを行うためにより多くの処理能力が必要になる。
12.5 TCP の動作
321
WAN 技術の改善により、エラーの発生率が大幅に低下すると、フレーム
の損失や破損の可能性も大きく減少する。これによって、セグメントの最大
サイズにより大きな値を設定することが可能になる。セグメントのサイズを
許容される最大値以外の値に変更しなければならない状況は、ごくまれで
ある。
12.5 TCPの動作
TCP の機能の動作を説明するために、TCP の接続の各フェーズについて
考えてみよう。128.1.0.1 と 128.1.0.9 という 2 つのノード間における接続の確
立を例に挙げる。ここでは、128.1.0.1 が 128.1.0.9 との間で接続を確立する。
12.5.1 接続の確立
TCP の接続の確立は、ノードのアプリケーション層の要求によって開始
する。図 12-7 に示すように、128.1.0.1 のノードが 128.1.0.9 という IP アド
レスに対して接続を要求する場合、TCP は、SYN フラグをオンに、シーケ
ンス番号を 921 に、ACK をオフに設定したセグメントを IP 層に送信する。
このセグメントは、接続の最初のセグメントであることを示す。この段階で
は、セグメントが IP 層に渡されたときに IP 層の ARP キャッシュに 128.1.0.9
という IP アドレスが格納されていない場合、IP 層は ARP 要求を発信して
128.1.0.9 というノードの MAC アドレスを取得する。MAC アドレスを取得
すると、そのセグメントが IP データグラムとして送信される。
128.1.0.9 のノードは、SYN フラグと ACK フラグをオンに、自分のシーケ
ンス番号を 302 に設定した同様のセグメントでこれに応答する。肯定応答番
号フィールドには、128.1.0.1 から送信されたシーケンス番号より 1 だけ大き
い値（ 921 + 1 = 922 ）が設定される。このセグメントでは、128.1.0.9 のノー
ドが 128.0.1.1 のノードからシーケンス番号を受信したことを確認し、自分の
シーケンス番号を提示している。
128.1.0.1 のノードは、ACK フラグをオンに、肯定応答番号を 128.1.0.9 の
ノードから送信されたシーケンス番号より 1 だけ大きい値（ 302 + 1 = 303 ）
に設定した 2 番目のセグメントを送信することにより、128.1.0.9 のノードか
らの応答を受信したことを確認する。
この時点で TCP の接続が確立される。両方のノードがシーケンス番号を
交換したため、データを送信する準備が整ったことになる。
322
第 12 章トランスポート層プロトコル
ネットワーク
ノード 128.1.0.1
SEQ=921
ACK=?
SYN
ノード 128.1.0.9
SEQ
SEQ=302
ACK=?
= 92
1 A
CKな
し
SEQ=302
ACK=922
K=
SYN
SEQ=922
ACK=303
SYN
SEQ
SEQ
C
A
922
02
=3
= 92
2 A
CK
= 30
3
SEQ=303
ACK=922
時間
図 12-7 TCP の接続の確立
12.5.2 データの送受信
128.1.0.1 のノードが 128.1.0.9 のノードにデータを送信する場合、セグメン
トのシーケンス番号は伝送されるデータの最初のオクテットを指す。また、
128.1.0.9 のノードからの応答には、受信したシーケンス番号 + 伝送された
オクテット数 + 1 の値に設定された肯定応答番号が含まれる。この肯定応答
番号は、128.1.0.9 のノードが次に受信することになるオクテットを示す。
アプリケーションが端末エミュレーションサービスで、リモートノード
（ 128.1.0.9 ）上のアプリケーションに文字のエコーを要求する場合、セグメン
トでは PSH フラグがオンに設定される。これにより、128.1.0.1 と 128.1.0.9
のノードの内部で TCP にデータを保持せずに、ネットワークを介してアプ
リケーションにすぐ渡され、できる限り速く文字のエコーが返される。
すべてのデータが送信されるまで、この処理が行われる。受信した最新の
セグメントにデータが存在する場合にのみ肯定応答が返され、データが含ま
れていない場合、TCP は次のデータが送信されるのを待つ。初期の実装以
降、TCP の標準にはキープアライブのセグメントが追加された。このセグ
メントは、接続が保持されていることを調べるために送信される。TCP の
接続は、送信するアプリケーションデータが存在しない場合には完全に初期
化状態になっていることが多い。キープアライブの詳細は後述する。
12.5 TCP の動作
323
ネットワーク
ノード 128.1.0.1
‘C’を入力する
SEQ
ノード 128.1.0.9
= 92
ACK
= 10
9 Da
ta =
C
C
C
ノードは‘C’の
受信の肯定応答を
出す
（ACK = SEQ + 1
= 109 + 1 = 110）
K=
SEQ
C
9A
93
=
ata
C
D
0
=1
SEQ
= 93
ACK
オペレーティング
システム
ホストのオペレーティング
システムは‘C’のエコー
を返し、肯定応答を出す
（ACK = SEQ + 1
= 92 + 1 = 93）
= 11
0
時間
図 12-8 単純な文字のエコーにおける TCP の肯定応答
データの送信と制御を行う場合、セグメントはすべて同じ形式であるため、
TCP はリモートノードから送られたデータに対して肯定応答を返し、同じ
セグメントで帯域外データを伝送することができる。TCP は、利用するセ
グメントの数という点では非常に効率が高い。Telnet を利用する端末接続
でリモートホストから文字のエコー＊4 を行う場合、TCP では入力された文
字ごとにセグメントを 3 つだけ使うことが多い。
図 12-8 は、Telnet などの端末接続がエコーを返すモードで動作してい
る場合の TCP の単純な例を示している。ユーザーが入力した文字は、コン
ピュータに渡された後、画面に戻されて表示される。ユーザーがキーを押し
てから画面に表示されるまで、文字は 2 回ネットワーク上で伝送される。
この例ではユーザーが‘ C ’という文字を入力すると、シーケンス番号に
92 が設定され、ネットワーク上に送信される。オペレーティングシステムは
その文字をエコーとして返すが、それは TCP プロトコルが 128.1.0.1 のノー
ドから‘ C ’を受信したことを示す肯定応答と同じフレームに収められてい
る。128.1.0.1 のノードは、続いて 128.1.0.9 から文字を受信したことを示す肯
定応答を返さなければならないため、データを含めずに肯定応答のセグメン
＊4 インタラクティブなシステムでは、文字のエコーを利用することが多い。文字が入力
されても、リモートホストから返送されるまでローカルコンピュータの画面には文字
が表示されない。これにより、リモートホストは任意の文字に応じて表示する文字を
決定することができる。初期のコンピュータでは、エラーをチェックする手法として
文字のエコーが利用されていた。
324
第 12 章トランスポート層プロトコル
トを返す。この場合、1 文字のデータを受信したため、肯定応答番号フィー
ルドには、受信したシーケンス番号に 1 を足した値が設定される。
リモートエコーを利用するシステムでは、送信先のコンピュータが負荷の
高い状態にある場合、文字が入力されるたびに 3 つ以上のセグメントが発生
する可能性がある。これは、1 文字を伝送する各セグメントに対して一定時
間以内に肯定応答が返されなければならないが、時間内に肯定応答が返され
ないとセグメントの再送が発生するためだ。アプリケーションのホストがタ
イムアウト時間内に応答を返すことができない場合、受信したセグメントに
対する肯定応答のセグメントをエコー文字を含めずに生成する。アプリケー
ションが、発信元に対して文字のエコーを返す準備が整うと、さらにセグメ
ントを送信し、続いて端末のコンピュータが返す肯定応答を受信する。このよ
うな状況では、4 つのセグメントが生成されることになる（図 12-9 を参照）
。
ネットワーク
ノード 128.1.0.1
‘C’を入力する
タイムアウト時間
が開始する
ノード 128.1.0.9
SEQ = 2
05 ACK
= 326 D
ata = C
受信時間が開始する
C
オペレーティング
システム
C
SEQ =
326
SEQ =
6 ACK
32
ACK =
= 206
ata = C
206 D
SEQ = 2
ホストは‘C’を返す
06 ACK
=3
27
ノードは‘C’の
受信の肯定応答を
出す
TCPはリモートノードが
タイムアウトし、データ
を再送する前に肯定応答
を出す
時間
図 12-9 ホストの遅延により文字ごとに 4 つのセグメントを生成する例
12.5 TCP の動作
325
このようにリモートからの文字のエコーを利用するアプリケーションが与
える影響は、入念に検討する必要がある。各セグメントには TCP ヘッダー、
IP ヘッダー、入力された 1 文字が含まれるが、すべてを合わせると 41 オク
テットになり、これがデータリンク層のフレームで伝送される。イーサネッ
ト上では各フレームが最小サイズの 64 オクテット＊5 でなければならないが、
これはユーザーが 1 文字を入力するたびに 3 つまたは 4 つのセグメントが送
信され、発信元と送信先の間でリモートコンピュータの負荷に応じて 192 オ
クテット（ 64 オクテット×3 ）または 256 オクテット（ 64 オクテット×4 ）が送
受信されることを意味する。アプリケーションを実行するコンピュータが負
荷の高い状態にある場合、1 文字が入力されるたびに 4 つのパケットが発生
し、肯定応答を余分に生成するためにコンピュータにより大きな負荷がかか
る。このような場合、このアプリケーションによるネットワークのトラフィッ
ク量は、最大 33％増加する。この問題によって発生するオーバーヘッドを軽
減する唯一の方法はホストコンピュータのリソースのボトルネックを解決す
ることだが、そのためにはより強力なコンピュータが必要になる場合もある。
また、このような問題が発生するコンピュータは、通常のタスクを実行する
際にも同様に処理は遅い可能性が高い。
負荷が高いホストでは、伝送するデータ量が 1 つのフレームでサポート可
能である場合にも、応答を複数のセグメントによって送信することがある。
これは、通常、通信ソフトウェアが高い優先順位で動作し、タイマに基づい
て送信するフレームを構築するために発生する。負荷が高いコンピュータで
は、タイムアウトが発生する前にアプリケーションに必要な情報をすべて集
めることができない。
毎秒 7,000∼14,000 個のフレームを送受信する純粋にローカルな LAN 上で
はリモートエコーの動作を受け入れ可能であるが、リモートブリッジやルー
ターを使う WAN の設計時には発生するトラフィック量を注意深く検討する
必要がある。1 文字が入力されるたびに 3 つまたは 4 つのフレームが発生す
る場合、サイト間の回線の速度を決めるときには必ずそのことを考慮する。
たとえば、64kbps の回線では、最小サイズのイーサネットフレームが毎秒
約 120 個伝送される。ユーザーが平均で毎秒 2 文字を入力する場合（これは
毎分 20 語にすぎないが、いまだにコンピュータのユーザーはキーボード操
作に慣れないことが多い）、文字ごとに 4 つのフレームが送受信されること
になる。この回線は、30 人のユーザーが入力を行うだけで送受信が過負荷
＊5 イーサネットフレームのオーバーヘッドは 18 オクテットであるため、入力された 1
文字を伝送する各フレームには 5 オクテットのパディングが付加される（ 18 + 41 +
。IEEE 802.3 のフレームでは、LLC と SNAP により 8 オクテッ
5 = 64 オクテット）
トが追加され、最小の TCP セグメントとして 67 オクテットのフレームが作成され
るため（ 18 + 8 + 41 = 67 オクテット）、パディングは不要である。
326
第 12 章トランスポート層プロトコル
＊6
状態になる。
これは、文字の入力の目的（通常は情報が画面に表示される
ことになる）をまったく計算に入れていない。アプリケーションを個別に設
計し、アプリケーションによって発生するトラフィックをネットワークの各
地点で検討する。トラフィックについては、毎秒あたり必要になるビット数
と、毎秒あたりのフレーム数またはパケット数という要素を考慮する。ボト
ルネックは、広域リンクに存在する可能性が高い。
特定のプロトコルの動作をスプレッドシートを使ってモデル化すると、非
常に便利である。ユーザーの操作パターンやデータの発信元のパフォーマン
スをモデル化することはできないが、特定の設計が機能するかどうかについ
ては適切な指標を提示することができる。
TCP によって発生するトラフィックの総量は大きくなることもあるが、ほ
かのプロトコルより少ないこともある。
12.5.3 接続の終了
あるノードが接続を閉じる場合、接続の終了フェーズでは FIN フラグが使
われる。インタラクティブな端末接続では、ユーザーがアプリケーションか
らログアウトし、続いてそのアプリケーションが TCP 層に対して接続のク
ローズを指示する。これにより、アプリケーションの存在するノードが FIN
フラグをオフに設定したセグメントの送信を実行する。端末のノードは、FIN
フラグの肯定応答として ACK を設定したセグメントでこれに応答し、自分
自身の FIN フラグを設定する。両方のノードから FIN フラグのセグメント
が送信され、FIN フラグを設定したセグメントの受信に対する肯定応答が返
されるまでは、接続は完全に閉じたとみなされない。しかし、終了フェーズ
でセグメントが損失しても、短いタイムアウト時間が過ぎると接続は閉じた
ものとみなされる。実際には、ノードのいずれかが FIN フラグを使って接続
の終了を開始する。
図 12-10 では、作業を終了したユーザーが“ logout ”と入力して接続のク
ローズを試みている。このメッセージはオペレーティングシステムに送られ、
オペレーティングシステムが閉じる接続を解放する。
“ logout ”というデータ
には、そのほかのデータと同様に肯定応答が返されることに注意する。続い
て、ホストは接続が閉じられることを TCP のスタックに指示し、その接続
を閉じる。結果として、TCP ソフトウェアは、FIN のコード値が設定され
たフレームを送信する。128.1.0.1 のノードも同様に作業が完了しており、送
信するデータがそれ以上存在しないと判断すると、肯定応答と FIN フラグ
を返して 128.1.0.9 に接続の終了を通知する。
＊6 優れたデータ圧縮アルゴリズムを備えたブリッジは役に立つが、ユーザーからエコー
の遅延に対して苦情が出る前に、伝送のラウンドトリップ遅延が拡大しないように注
意する。
12.5 TCP の動作
327
ネットワーク
ノード 128.1.0.1
ログアウト
を行う
SEQ
ノード 128.1.0.9
= 29
0 AC
K=
501
Dat
a=
a=
CK
SEQ
=
A
501
SEQ
接続終了
SEQ
SEQ
K=
=
CK
オペレーティング
システム
507
507
FIN
A
= 29
7 AC
=
out
Log
Logout
接続の
クローズ
6 AC
96
out
9
=2
= 29
=2
SEQ
at
6D
Log
K=
508
K=
AC
507
FIN
297
時間
図 12-10 TCP の接続の終了
12.5.4 エラーの訂正と再送のタイムアウト
TCP は、TCP/IP アプリケーションに必要に応じてエラーの訂正機能を提
供する。TCP/IP のアーキテクチャは、基盤となるネットワークのエラー訂
正機能に前提条件を設けないように、エラーの訂正をトランスポート層に委
任している。特定のアプリケーションに対してエラーの訂正を行わなければ
ならない場合、エンドポイントのノードのトランスポート層で一度実行する
だけでよいのではないだろうか。これには、TCP/IP のエラー訂正機能が、
X.25＊7 を実装したネットワークとは異なり、ホップごとではなくエンドツー
エンド＊8 で行われるという前提があることを意味する。
＊7 TCP/IP の開発時には、X.25 と異なり、一般にある程度のパフォーマンスを保証す
るデータ転送ネットワークのサービスを設計するだけでなく、アプリケーションに要
求されるパフォーマンスをより高い水準から検討することが可能であった。
＊8 TCP を X.25 などのエラー訂正機能を持つネットワーク上で運用する場合、本質的に
はエラーはないが、エラーの訂正が行われると突然に遅延が変化する。
328
第 12 章トランスポート層プロトコル
この前提条件には、管理上興味深い影響がある。基盤となるネットワーク
のエラー機能のパフォーマンスについては前提条件を設けないが、パフォー
マンスが低い場合にはエラーが発生するとすべてのリンク上のエンドツーエ
ンドで TCP セグメントが再送される。X.25 のネットワークの場合、エラー
が発生したリンクにおいてのみ再送が行われる。しかし、TCP のエラー訂
正機能は、実行される機会が少ないほど有効に動作する。幸い、WAN 回線
上のエラーの発生率は光ファイバ通信システムの導入により大幅に改善され
たため、TCP/IP の設計者の考えは裏付けられることになる。
TCP におけるエラー訂正は、単純な手法で行われる。特定のセグメント
のシーケンス番号に対応する肯定応答が一定のタイムアウト時間内に受信さ
れなかった場合、そのセグメントは再送される。これが、エラーの訂正を行
う唯一のしくみだ。そのほかのエラー訂正手法とは異なり、受信側が特定の
箇所から強制的に再送を行う方法はない。順序が不正な場合にはデータを再
送するという概念が存在しないことが、その理由の 1 つである。受信側は、
発信元のタイムアウトを待たなければならない。
セグメントは順序が正しい場合にのみ肯定応答が返されるため、タイムア
ウトが発生すると一連のセグメントが再送されることもある（ウィンドウの
サイズと MSS に、複数のセグメントの肯定応答に十分な値が設定されてい
る場合）。実装によっては 1 つのセグメントだけが再送され、多数のセグメ
ントに対する肯定応答が返されないこともある。TCP の標準では、どちら
の手法も容認されている。したがって、実際に行われるエラー訂正処理は、
実装の設計者の考え方に依存する。
図 12-11 では、最後に 128.1.0.1 のノードに通知されたウィンドウのサイ
ズにより許可されたデータの量に基づき、複数の TCP セグメントが送信さ
れている。シーケンス番号が 39 であるセグメントは、その後のセグメント
（シーケンス番号は 49 ）が着信したにもかかわらず、送信先への着信に失敗し
た。TCP は、シーケンス番号が 49 のセグメントに対し、これより前のデー
タを受信していないため、肯定応答を返さない。これにより、シーケンス番
号が 39 のセグメントの肯定応答を待つ再送タイマが起動し、セグメントの
再送が発生する。
図 12-12 では、セグメントに対する肯定応答が返されない場合、その後に
セグメントが着信したことによって、肯定応答が返されなかったセグメント
に対する再送は行われていない。この場合、シーケンス番号 72 以降のすべ
てのデータとそのセグメントに含まれているシーケンス番号 170 のデータが
128.1.0.9 に着信したことを意味する。
12.5 TCP の動作
329
ネットワーク
タイマ
ノード 128.1.0.1
9
21
35
49
ノード 128.1.0.9
SE
Q=
SE
Q=
SE
Q=
SE
Q=
SE
Q=
9
21
35
K=
39
AC
K=
49
AC
K
AC
タイムアウト
による再送
21
35
9
=3
SE
Q=
39
K=
57
AC
時間
図 12-11 着信に失敗したデータを伝送するセグメントの例
再送のタイムアウトとして設定する値は重要である。タイムアウト値は、使
われているパス上のラウンドトリップ遅延または RTT（ Round Trip Time ）
に依存する。LAN 上では、1∼100 ミリ秒の間に肯定応答が返される。低速
な衛星回線を使う WAN の場合、肯定応答が返されるまでに数秒を要するこ
とがある。ネットワーク上で発生する遅延の特徴をあらかじめ調べるのは難
しく、1 つの接続の有効期間中に経路や負荷に応じて大幅に変化する可能性
がある。そのため、再送のタイマとして 1 つのタイムアウト値のみを設定す
ることはほとんど不可能だ。タイマとして設定された値が小さすぎる場合、
肯定応答が返される前にタイムアウトが発生し、不必要にセグメントが再送
され、トラフィックが増加する。逆に、値が大きすぎる場合、タイムアウト
が発生して再送が行われるまで待機するために遅延が大きくなり、1 つのセ
グメントの損失がスループットを大幅に低下させることになる。
330
第 12 章トランスポート層プロトコル
ネットワーク
ノード 128.1.0.1
ノード 128.1.0.9
タイマ
72
SE
Q=
97
72
SE
Q=
97
SE
Q=
101
Q=
110
101
01
110
K
AC
SE
Q=
97
K=
AC
SE
=1
10
150
K
AC
150
=1
50
K
AC
=1
K=
170
AC
時間
図 12-12 着信に失敗した肯定応答のセグメントの例
TCP の最新の実装では、RTT の許容値の範囲でさまざまなタイマ値に対
応する機能を備えている。この問題を解決するために、現在、TCP の実装は
接続の遅延の平均値を計算し、さまざまな遅延に対応するしきい値を設定す
る機能を利用する。タイムアウト値を動的に設定することにより、接続上で
タイムアウト値を現状に合わせて調整し、プロトコルの構築を強化する。こ
れにより、不要な再送の数が減少し、再送が開始されるまでの待機時間は短
くなる。
動的なタイマの実装方法については、問題がいくつか存在する。もっとも
強力な手法の 1 つは、パケット無線のネットワーク上で利用するために Phil
Karn（ KA9Q ）によって開発された。この手法では、セグメントの損失の有
無に関係なく RTT を正確に評価する。現在、TCP/IP 製品の一部にこの機
能が実装されている。このアルゴリズムが登場する以前には、すべてを 2 回
ずつ送信することによって信頼性を向上するような手法も存在した。
TCP の実装には、さまざまな再送アルゴリズムが使われているため、タ
イムアウトのアルゴリズムの基礎と、負荷が高く、セグメントの損失が多く
発生する状況における安定性を理解することが重要である。
12.5 TCP の動作
331
現在でも、TCP/IP のすべての実装において動的なタイムアウトのアルゴ
リズムが利用されているわけではない。タイマ値が固定されていたり、設定
可能な場合もある。また、テーブルを使ってホストごとにタイマ値を設定す
ることができるものもある。ネットワークのトポロジーが非常に単純な場合
を除き、このようなタイマは動的なタイマほど満足とは言いがたい。
ウィンドウの通知、
フロー制御
12.5.5 スライディングウィンドウ、
遅延が大きいネットワークでは、ポジティブ肯定応答を利用するプロトコ
ルによりスループットが劇的に低下することがある。この場合、次のセグメ
ントが送信可能になるまで、各セグメントが肯定応答の返送を待つ可能性が
ある。媒体や回線の処理能力に対する負荷はわずかだが、ラウンドトリップ
遅延の増加とともに処理能力は劇的に低下する。この状況を改善するために、
TCP はスライディングウィンドウという手法を利用する。
スライディングウィンドウにより、それぞれの肯定応答を待たずに複数の
セグメントを送信することができる。スライディングウィンドウでは、ある
ノードで肯定応答を送信する準備が整う前に複数のセグメントを受信した場
合、最後に受信したセグメントに対してのみ肯定応答を返すだけで済むため、
すべてのセグメントに対する肯定応答を返す必要がなくなる。そのため、ス
ループットが向上し、帯域幅をより効率的に利用することができる。
ブリッジやルーターを経由するパス上で、特にリモートリンクが存在する
場合には、スライディングウィンドウを適切に利用することが非常に重要で
ある。ローカルブリッジだけが存在する LAN 上でも、ブリッジのバッファ
によって遅延が発生する。ウィンドウのサイズを適切に設定すると、直接回
線を接続した場合とほぼ同様のパフォーマンスが得られる。スライディング
ウィンドウは、UDP やそのほかの LAN プロトコルとは対照的に、遠距離の
WAN 上で TCP を運用する際に有効である。
受信側が各接続に対して用意するバッファには制限があるため、送信可能
な情報の総量も制限されることになる。この制限がウィンドウのサイズであ
り、TCP ではオクテット単位で表される。ウィンドウのサイズと MSS には、
関連性がある。ウィンドウのサイズが新たに設定される場合、通常その値は
MSS の整数倍になる（パーソナルコンピュータなどメモリの容量が制限され
ているシステムでは MSS と同じ値になることが多い）
。ウィンドウのサイズ
は一般的に 1,024∼4,096 だが、MSS が 1,024 、MTU が 1,500 であるイーサ
ネット上ではわずか 1∼4 のセグメントに相当する。
受信側では、送信する各 TCP セグメントでウィンドウのサイズを通知す
る。肯定応答が返されていないデータが通知されたウィンドウのサイズと同
じである場合、ウィンドウとして 1 つの最大セグメント以上のサイズを通知
する肯定応答が受信されるまで、データが送信されることはない。
332
第 12 章トランスポート層プロトコル
パフォーマンス上の問題が発生している場合、各セグメントで通知される
ウィンドウが便利な監視機能を提供する。データの伝送中にウィンドウのサ
イズに小さな値が設定されたり、0 になることが多い場合、装置がバッファ
に十分なメモリを割り当てていないことを意味する。バッファを増加するこ
とができる場合、パフォーマンスが改善される可能性は高い。
受信側では、ウィンドウのサイズを 0 にしてデータフローを完全に停止す
ることも可能である。これは、フロー制御を意味する。ウィンドウに接続上の
有効なデータがサイズ分格納されている場合にのみ、ウィンドウのサイズを
小さくすることができる。受信側では、事前に通知されたウィンドウにデー
タが含まれていない場合、ウィンドウのサイズを小さくすることはできない。
続いて、Telnet におけるフロー制御について説明する。
CTRL
キーと s が
同時に押されると、それ以降は情報が端末の画面に表示されない。この場合、
CTRL
+ s によって ASCII 制御文字の DC3（ XOFF ）が発生する。このイベン
トでは、TCP 上で動作している Telnet のターミナルサーバーは、バッファ
がオーバーフローしてデータの損失が発生しないように、リモートホストの
送信を停止しなければならない。データの受信が継続し、あらかじめ通知さ
れたウィンドウのサイズに達すると、TCP はウィンドウのサイズが最終的
に 0 になるまで、ウィンドウのサイズを小さくしてセグメントを送信する。
CTRL
と q を同時に押すと ASCII 制御文字の DC1（ XON ）が発生し、デー
タフローが有効になると、端末に対して再びデータが流れ始め、バッファが
解放されるため、リモートホストに送信されるセグメントによりターミナル
サーバーのウィンドウのサイズが大きくなったことが示される。
効率を考えると、新しく通知されるウィンドウは、最大サイズのセグメン
トの 1 つ分以上でなければならない。
図 12-13 では、128.1.0.9 のノードのバッファがあふれ、ウィンドウのサ
イズが 200 になり、続いて 0 になる接続の例を示す。128.1.0.9 のノードは、
データの処理が可能になると受信バッファをクリアし、ウィンドウのサイズ
として 1,024 を通知するため、データのフローが再開する。
12.5.6 TCPのキープアライブ
TCP の初期の実装では、アプリケーションが長時間データの送信を行わ
ない場合、TCP または IP の情報がまったく生成されなかった。パーソナル
コンピュータで TCP/IP アプリケーションを利用すると、クライアントのコ
ンピュータが TCP の接続を閉じずにシャットダウンする可能性が高くなる。
たとえば、ユーザーはログアウトせずにコンピュータの電源を切ることも多
い。アプリケーションがクライアントとの通信の有効性を定期的にチェック
しない場合、サーバー上には開かれたままハングした接続が残される可能性
がある。この接続は、システム管理者が手動で閉じなければならない。
12.5 TCP の動作
333
ネットワーク
ノードA
ノードB
100
オク
ow
d
Win
テッ
トの
デー
タ
00
=2
200
オク
テッ
トの
デー
タ
バッファに空きなし
dow
=0
Win
200オクテットの空き
w=
do
Win
4
102
100
オク
テッ
トの
デー
タ
時間
図 12-13 TCP のウィンドウの通知
サーバーではこの問題を解決するために、TCP のキープアライブ機能を稼
働する。キープアライブにより、定期的に TCP セグメントを送信して、ほ
かのコンピュータから肯定応答の返送を要求する。TCP セグメントの送信
を数回繰り返しても肯定応答が返送されない場合、TCP の接続がリセット
される。アプリケーションにはキープアライブのセグメントを渡すことはで
きないが、キープアライブ機能では直前に肯定応答が返されたデータの最後
のバイトだけを含むセグメントが送信される。システムはこのセグメントの
再送を無視し、肯定応答を繰り返し返送して稼働中であることを確認する。
334
第 12 章トランスポート層プロトコル
TCP のキープアライブは、通常、ホストで利用される。キープアライブの
間隔は 90 秒程度であるが、それ以上の時間に設定されることも多い。キー
プアライブの間隔を設定することも可能だ。プロトコルアナライザによって
は、誤ってキープアライブのセグメントを TCP セグメントの再送として表
示する。キープアライブのセグメントは、遅延が大きいこと、規則的に送信
されること、データが 1 バイトだけ存在することから、通常の TCP セグメ
ントの再送と簡単に区別することができる。
12.5.7 TCPのウィンドウとスロースタート
TCP は、リモートノードに対してウィンドウのサイズを通知し、バッファ
がオーバーフローすることなく受信できるデータの量を指示する。これは、
2 つのノード間でエンドツーエンドのフロー制御を行う方法としては有効に
機能するが、ノードの間にあるネットワークにおけるフロー制御は行われな
い。そのため、ノード間のネットワークで輻輳が起こると問題が発生する。
ノードは輻輳をまったく認識しないため、受信側のノードで許容可能な最大
サイズのデータを送信するが、それによってさらに輻輳が発生する。
この問題を解決するために、スロースタートという手法を使う。この手法
では、輻輳ウィンドウに肯定応答が返されていないセグメントに関する情報
を保持する。接続の開始時には、輻輳ウィンドウの値は 1 セグメントである。
最初のセグメントに対して肯定応答が返されると、輻輳ウィンドウはそのサ
イズに合わせて増加する。再送が発生すると、輻輳ウィンドウはそのサイズ
に合わせて減少する。輻輳ウィンドウは、過負荷状態にならないように、2
つのノード間のリンクの状態を追跡する。
この機能は、Telnet や FTP など、接続を確立して長時間数多くのセグメ
ントを送受信するようなアプリケーションプロトコルに有効である。一方、
最初のバージョンの HTTP（ WWW で利用される）など、接続時間が短いプ
ロトコルではこの機能によって問題が発生する。これはスロースタートによ
り最初からスループットが抑えられるためであるが、一方では所要時間や受
信する肯定応答の数は改善される。接続時間が短い場合、最適なスループッ
トが得られない。
■ TCP の TIME_WAIT
クライアントとサーバーの間の接続が閉じられると、サーバーはしばらく
の間（通常は 240 秒程度まで）その接続を記憶する。これは、大幅に遅延し
たセグメントが、同じポート番号を使う同じクライアントとサーバーの間で
後続のセッションに影響する可能性があるからだ。これを防止するために、
サーバーは TIME_WAIT 状態に移行する。TIME_WAIT 状態の間は接続
を記憶して、そのポート番号を使う新しい接続をすべて拒否し、閉じられた
以前の接続に着信するセグメントを拒否する。
12.5 TCP の動作
335
この場合、サーバー上のリソースを保持するという問題がある。TIME_WAIT
状態の間は、以前の接続に使われたポート番号を再利用することができない。
そのため、非常にアクセスが多く、また、短い接続が多いサーバーでは、利
用可能なポート番号が不足し、TIME_WAIT 状態が終わるまで新しい接続
が拒否される可能性がある。
クライアントとサーバーの間の新しい接続ではクライアント側は異なるポー
ト番号を使うため、以前の接続と識別可能であることから、TIME_WAIT
状態の問題はそれほど重要ではないと考えるかもしれないが、常に異なる
ポート番号が使われるわけではない。一部のプロトコルまたは実装では、利
用するクライアントのポート番号が固定されている。また、アプリケーショ
ンソフトウェアの実装によっては、クライアントの発信元ポート番号として
一定の範囲の値を利用し、ランダムな値を選択しないものもある。ポート番
号に基づいてアクセス制御を実装する場合、この方式にはいくつかの利点が
あるが、送信先のホストが TIME_WAIT 状態にある間は、一定の範囲での
み利用可能なポート番号を再利用することができない。
サーバーが数多くの短い接続を受け入れる場合、これは重大な問題に発展
する可能性がある。クラッカーが TCP/IP システムのこの機能を利用して、
利用可能なポート番号をすべて TIME_WAIT 状態にすることにより特定の
ホスト上のサービスを使用不能にすることもある。
12.5.8 構成の問題点
一般的に、TCP で変更可能な設定は少ない。また、UDP では変更は必要
ない。しかし、TCP の一部の設定を変更可能な実装も存在する。
■ 接続のタイムアウト
コンピュータとの接続の確立を試みる時間である。この値を変更すると、
ホストと接続できない場合に接続の確立が失敗するまでの時間に影響する。
■ 再送のタイムアウト
TCP セグメントを再送するまでの待機時間である。最新の実装では、実
際にはこの値をネットワーク管理者の選択に委任するべきではない。
再送のタイムアウト値は、評価が難しい。まず、ping ユーティリティを利
用する方法が考えられる。ping によって、ホストに対するラウンドトリップ
遅延が表示されることが多い。ping ユーティリティをもっともアクセスが多
い時間帯を含めて長期間にわたりシステム上で実行した際に、検出される最
大の遅延を参考情報として利用したり、ある程度のゆとりを持たせて使うこ
とができる。ゆとりとして加える値は遅延の範囲によって異なるが、1.5∼2
倍にするのが一般的である。
336
第 12 章トランスポート層プロトコル
■ MSS
許容される TCP セグメントの最大サイズである。MSS でもっとも注意が
必要になるのは最大値で、これによりホストでもっともよく利用される接続
においてフラグメント化の発生を防ぐ。LAN のみの環境で運用する場合、
1,024 が一般的な値である。
■ 受信ウィンドウ
通知される受信ウィンドウの最大サイズである。通常は、MSS の倍数を
＊9
設定する。
メモリが制限されている場合、この値は最大サイズのセグメン
トの 1∼2 倍になる。
ウィンドウのサイズにより大きな値を設定すると、ブリッジやルーターを
介する TCP 接続のパフォーマンスを改善することができる。たとえば、2
台のローカルブリッジを備えた経路上では、受信側のウィンドウが送信側の
MSS の 3 倍である場合にパフォーマンスが最大になる。この場合、エンド
ポイントで 1 つのセグメントを受信したときには、2 番目のブリッジでは 2
番目のセグメントを受信している。また、ウィンドウのサイズに達する 3 番
目のセグメントも、同時に最初のブリッジで受信されるが、肯定応答が返さ
れることによって、後続の送信用にウィンドウが解放される。
LAN と WAN が混在し、速度もさまざまである場合には、この値を異な
る方法で計算する。
■ TCP のキープアライブ
一部のシステムでは、TCP のキープアライブについて次のような調整が
可能である。
●
キープアライブの有効化と無効化
●
キープアライブのセグメントを送信する間隔
●
応答がない場合にキープアライブのセグメントを再送するまでの時間
●
接続を閉じるまたはリセットするまで再送するセグメントの数
＊9 MSS は送信時に、ウィンドウのサイズは受信時に適用される。この 2 つの値には、
実際には関係がない。すべてのシステムで MSS が 1,024 程度に、最大のウィンドウ
サイズが MSS の 2∼4 倍に設定されていれば、ネットワークのリソースを効率的に
活用することができる。
12.5 TCP の動作
337
■ TCP と UDP で使う既知のポート
10 進表記
キーワード
説明
0
予約
1
TCPMUX
TCP ポートサービスの多重化
5
RJE
リモートジョブエントリ
7
Echo
エコー
9
Discard
廃棄
11
Users
アクティブなユーザー
13
Daytime
日付時刻
17
Quote
今日の一言
19
Chargen
文字ジェネレータ
20
FTP-data
ファイル転送
（デフォルトのデータ）
21
FTP
ファイル転送
（制御）
23
Telnet
Telnet
25
SMTP
簡易メール転送
247∼255
予約
ポート番号の完全な一覧については、付録 G「既知のポート」に掲載する。
12.5.9 TCPのトレース
続いて、運用中のネットワークで記録した TCP プロトコルの実際のトレー
スを例として示す。この例では、イーサネットのフレーム（プリアンブルま
たは CRC を除く）を 16 進数で示す。16 進数で表されたフレームの下には、
フレームのフィールドごとに詳細な値をまとめた表を示す。この例の形式の
詳細については、付録 F「プロトコルのトレース」を参照してほしい。ここ
では、補足としてデータリンクと IP を網かけで示す。
この例では、TCP のセッションを開始するために送信された最初の 3 つ
のセグメントを示す。この 3 つのセグメントにより、シーケンス番号と肯定
応答番号を同期させる。
フレーム 1
AA00
002C
0063
0400
0400
0002
19CB
015D
0104
0000
0017
0000
0260
FF06
0000
0204
8C0A
7F66
3E38
0400
C49D 0800 4500
1E00 0001 1E00
0000 0000 6002
0000
.......‘......E.
.,.......f......
.c......>8....‘.
...]........
338
第 12 章トランスポート層プロトコル
データリンク層
送信先 MAC
AA0004 000104
種類
（長さ）
0800
IP
発信元 MAC
02608C 0AC49D
バージョン
4
IHL
5
TOS
00
長さ
002C
ID
0002
フラグ
0
フラグメント
0
有効時間
FF
プロトコル
06
チェックサム
7F66
発信元 IP
30.0.0.1
送信先 IP
30.0.0.99
TCP
発信元ポート
19CB
送信先ポート
Telnet
（ 0017 ）
シーケンス
00003E38
肯定応答
なし
オフセット
6
コード
02
（ SYN ）
ウィンドウ
0400
チェックサム
015D
TCP オプション
MSS
（ 0400 ）
フレーム 2
0260
002C
0001
0400
8C0A
0B0B
0017
B5B7
C49D
0000
19CB
0000
データリンク層
AA00
3C06
11E7
0204
0400
375E
39AD
0400
0104 0800 4500
1E00 0063 1E00
0000 3E39 6012
0000
送信先 MAC
02608C 0AC49D
種類
（長さ）
0800
IP
.‘............E.
.,....<.7^...c..
........9...>9‘.
............
発信元 MAC
AA0004 000104
4
IHL
5
TOS
00
長さ
002C
ID
0B0B
フラグ
0
フラグメント
0
有効時間
3C
プロトコル
06
チェックサム
375E
発信元 IP
30.0.0.99
送信先 IP
30.0.0.1
バージョン
TCP
発信元ポート
Telnet
（ 0017 ）
送信先ポート
19CB
シーケンス
11E739AD
肯定応答
00003E39
オフセット
6
コード
12
（ SYN 、ACK ）
ウィンドウ
0400
チェックサム
B5B7
TCP オプション
MSS
（ 0400 ）
12.5 TCP の動作
339
フレーム 3
AA00
0028
0063
0400
0400
0003
19CB
CBB8
0104
0000
0017
0000
データリンク層
0260
FF06
0000
0001
8C0A
7F69
3E39
0800
C49D 0800 4500
1E00 0001 1E00
11E7 39AE 5018
0604
.......‘......E.
.(.......i......
.c......>9..9.P.
............
AA0004 000104
種類
（長さ）
0800
IP
発信元 MAC
送信先 MAC
02608C 0AC49D
バージョン
4
IHL
5
TOS
00
長さ
0028
ID
0003
フラグ
0
フラグメント
0
有効時間
FF
プロトコル
06
チェックサム
7F69
発信元 IP
30.0.0.1
送信先 IP
30.0.0.99
TCP
発信元ポート
19CB
送信先ポート
Telnet
（ 0017 ）
シーケンス
00003E39
肯定応答
11E739AE
オフセット
5
コード
18
（ PSH 、ACK ）
ウィンドウ
0400
チェックサム
CBB8
TCP オプション
なし
次に示す 4 つのフレーム（ n-3∼n ）は、セッションの終了を通知する。ユー
ザーは“ logout ”と入力して、接続のクローズをホストに通知する。接続の終
了処理は、ホストが FIN フラグをオンに設定したセグメント（フレーム n-3 ）
を送信すると開始する。ワークステーションは、このセグメントの受信の肯
定応答（フレーム n-2 ）を返した後、同様に FIN フラグを設定したセグメン
ト（フレーム n-1 ）を送信する。ホストは、これに対して肯定応答（フレーム
n ）を返す。ここで、接続の切断が完了する。ワークステーションは、ホスト
からの FIN フラグの肯定応答と自分自身からの FIN フラグを送信するため
に、フレーム n-2 とフレーム n-1 の代わりに 1 つのフレームを利用できる点
に注意する。この例の場合、TCP/IP の実装ではある理由によって 2 つのフ
レームを利用している。
340
第 12 章トランスポート層プロトコル
フレーム n-3
0260
0028
0001
0001
8C0A
0B54
0017
C6E5
C49D
0000
19CB
0000
AA00
3C06
11E7
0000
データリンク層
0400
3719
4256
0000
0104 0800 4500
1E00 0063 1E00
0000 3E62 5019
0000
.‘............E.
.(.T..<.7....c..
........BV..>bP.
............
送信先 MAC
02608C 0AC49D
種類
（長さ）
0800
IP
発信元 MAC
AA0004 000104
バージョン
4
IHL
5
TOS
00
長さ
0028
ID
0B54
フラグ
0
フラグメント
0
有効時間
3C
プロトコル
06
チェックサム
3719
発信元 IP
30.0.0.99
送信先 IP
30.0.0.1
TCP
発信元ポート
Telnet
（ 0017 ）
送信先ポート
19CB
シーケンス
11E74256
肯定応答
00003E62
オフセット
5
コード
19
（ PSH 、FIN 、
ACK ）
ウィンドウ
0001
チェックサム
C6E5
TCP オプション
なし
フレーム n-2
AA00
0028
0063
0400
0400
006D
19CB
C2EE
0104
0000
0017
0000
データリンク層
0260
FF06
0000
0000
8C0A
7EFF
3E62
0000
C49D 0800 4500
1E00 0001 1E00
11E7 4257 5010
0000
送信先 MAC
AA0004 000104
種類
（長さ）
0800
IP
.......‘......E.
.(.m....~.......
.c......>b..BWP.
............
発信元 MAC
02608C 0AC49D
4
IHL
5
TOS
00
長さ
0028
ID
006D
フラグ
0
フラグメント
0
有効時間
FF
プロトコル
06
チェックサム
7EFF
発信元 IP
30.0.0.1
送信先 IP
30.0.0.99
バージョン
12.5 TCP の動作
TCP
341
発信元ポート
19CB
送信先ポート
Telnet
（ 0017 ）
シーケンス
00003E62
肯定応答
11E74257
オフセット
5
コード
10
（ ACK ）
ウィンドウ
0400
チェックサム
C2EE
TCP オプション
なし
フレーム n-1
AA00
0028
0063
0400
0400
006E
19CB
C2E5
0104
0000
0017
0000
0260
FF06
0000
0000
データリンク層
8C0A
7EFE
3E62
0000
C49D 0800 4500
1E00 0001 1E00
11E7 4257 5019
0000
送信先 MAC
AA0004 000104
種類
（長さ）
0800
IP
.......‘......E.
.(.n....~.......
.c......>b..BWP.
............
発信元 MAC
02608C 0AC49D
4
IHL
5
TOS
00
長さ
0028
ID
006E
フラグ
0
フラグメント
0
有効時間
FF
プロトコル
06
チェックサム
7EFE
発信元 IP
30.0.0.1
送信先 IP
30.0.0.99
バージョン
TCP
発信元ポート
19CB
送信先ポート
Telnet
（ 0017 ）
シーケンス
00003E62
肯定応答
11E74257
オフセット
5
コード
19
（ PSH 、FIN 、
ACK ）
ウィンドウ
0400
チェックサム
C2E5
TCP オプション
なし
フレーム n
0260
0028
0001
0000
8C0A
0B55
0017
C6ED
C49D
0000
19CB
0000
AA00
3C06
11E7
0000
0400
3718
4257
0000
0104 0800 4500
1E00 0063 1E00
0000 3E63 5010
0000
.‘............E.
.(.U..<.7....c..
........BW..>cP.
............
342
第 12 章トランスポート層プロトコル
データリンク層
送信先 MAC
02608C 0AC49D
種類
（長さ）
0800
IP
発信元 MAC
AA0004 000104
バージョン
4
IHL
5
TOS
00
長さ
0028
ID
0B55
フラグ
0
フラグメント
0
有効時間
3C
プロトコル
06
チェックサム
3718
発信元 IP
30.0.0.99
送信先 IP
30.0.0.1
TCP
発信元ポート
Telnet
（ 0017 ）
送信先ポート
19CB
シーケンス
11E74257
肯定応答
00003E63
オフセット
5
コード
10
（ ACK ）
ウィンドウ
0000
チェックサム
C6ED
TCP オプション
なし
12.6 関連RFC
675 Specification of Internet Transmission Control Program
700 Protocol experiment
721 Out-of-band control signals in a host-to-host protocol
761 DoD standard Transmission Control Protocol
768 User Datagram Protocol
793 Transmission Control Protocol
794 Pre-emption
814 Name, addresses, ports and routes
816 Fault isolation and recovery
817 Modularity and efficiency in protocol implementation
872 TCP on a LAN
879 TCP maximum segment size and related topics
889 Internet delay experiments
896 Congestion control in TCP/IP internetworks
964 Some problems with the specification of the Military Standard
Transmission Control Protocol
1006 ISO transport services on top of the TCP: Version 3
1072 TCP extensions for long-delay paths
1078 TCP port service Multiplexer（ TCPMUX ）
1106 TCP big window and NAK options
12.7 まとめ
343
1144 Compressing TCP/IP headers for low-speed serial links
1323 TCP extension for high performance
1692 Transport Multiplexing protocol（ TMux ）
12.7 まとめ
UDP と TCP は、TCP/IP のプロトコルスタックにおいてトランスポート
層プロトコルを提供する。UDP は、アプリケーション層プロトコルのデー
タの送信先を定義するために必要になる、ポートのアドレス指定だけを付加
したデータグラムサービスを提供する。TCP は、アプリケーション層のア
ドレス指定機能と同時に、信頼性の高いデータストリームを提供する。TCP
ではウィンドウを利用するため、ほとんどの媒体システムで効率的に機能す
るだけでなく、ウィンドウの通知によるフロー制御機構を提供する。
TCP/IP のプロトコルスタックを使う接続は、IP アドレスとポート番号を
合わせたソケットによって一意に定義される。広く普及したアプリケーショ
ン（通常はサーバーソフトウェア）は、共通に定義された既知のポート番号を
利用する。クライアントソフトウェアは、ホストに対して一意なポート番号
から、ホスト上のほかのアプリケーションが使っていないものを利用する。
これにより、接続を明示的に区別することができる。
セグメントの最大サイズとウィンドウの最大サイズを適切に設定すると、
バッファ処理を行うネットワーク上では TCP のパフォーマンスが大幅に改
善される。UDP の場合、必要に応じてデータグラムの最大サイズを変更す
ることができる。

Download Report