第 7 章トランスポート層（TCP と UDP）

第 7 章トランスポート層（TCP と UDP）
7.1 トランスポート層の機能
トランスポート層の主な機能は以下の 3 点である。
1. 上位層データのセグメントによるカプセル化とアンカプセル化
2. プロセス間通信の実現
3. 高信頼性通信のサポート
トランスポート層では，上位層データをセグメントでカプセル化・アンカプセル化する
ことにより，ネットワーク上の通信機器（ノード）内のプロセス（プログラム）とのプロ
セス間通信を実現する。
ネットワーク層の機能を使用すると他のネットワーク上の通信機器（ノード）とのデー
タ（パケット）交換が可能となるが，この層の機能を使用することにより，始めてノード
内のプロセス（プログラム）との直接的なデータ交換が可能となる。
さらに，トランスポート層では，このプロセス間通信をより信頼性の高いものにするた
めの様々な機能もサポートしている。
TCP/IP プロトコルのトランスポート層のプロトコルは TCP（Transmission Control
Protocol）と UDP（User Datagram Protocol）である。TCP と UDP は非常に対照的なプロト
コルで，UDP はトランスポート層のプロトコルであるにもかかわらず，高信頼性通信の機能
を全くサポートしない。逆に TCP は高信頼性のプロトコルであり，現在では信頼性が高す
ぎて「重いプロトコル」であるとさえ言われている。
TCP/IP は 1982 年には既に，現在使用されているものとほぼ同機能のものが完成しており
（Version4）
，非常に古いプロトコル（ソフトウェア）であると言える。TCP/IP の IP 部分
は現在，次期バージョンである IPv6 への移行が進められているが，TCP と UDP に関する根
本的な改良は殆ど進められていないのが現状である。
また，TCP/IP にはセッション層とプレゼンテーション層の上位層が存在しないため，TCP
および UDP ではアプリケーションデータがセグメントにより直接カプセル化される。
7.2 TCP（Transmission Control Protocol）
TCP はコネクション指向のストリーム型通信を行うプロトコルである。つまり，通信を行
う際にはプロセス間に仮想的な通信路が形成され，その通信路を介してコネクションが張
られる。TCP による通信は，よく電話に例えられ，絶えず相手との確認を取りながら通信が
行われる。
TCP では，高信頼性通信を実現するために，以下の機能がサポートされている。
1. 確認応答によるセグメントの再送処理
2. ウィンドウサイズによるフロー制御
3. シーケンス制御
4. エラー検査
7.2.1 TCP におけるコネクションの確立
TCP では 3 方向ハンドシェイク（Three Way Handshake）と呼ばれる方法により，相手と
のコネクションを確立する。3 方向ハンドシェイクの手順を以下に示す（図 7.2.1）
。なお，
下記説明文中のコードビットとは TCP セグメントの種類を示す 6bit のフラグで，それぞれ
のビットは URG（緊急データ），ACK（確認応答)，PSH（直にアプリケーションへデータを渡
すことを要求），RST（コネクションのリセット），SYN（問い合わせ），FIN（コネクション
の終了）を表している。
3 方向ハンドシェイクの手順
1. 接続側から被接続側に，コードビットの SYN フラグが ON になったセグメントを送信す
る。（例えば，電話の「もしもし。ＸＸさんのお宅ですか？」に相当）
2. 被接続側から接続側に，コードビットの SYN フラグと ACK フラグが ON になったセグメ
ントを返信する。（例えば，電話の「はい。どちら様ですか？」に相当）
3. 接続側から被接続側に，SYN セグメントに対する返答である ACK セグメントを送信する。
（例えば，電話の「はい。私はＸＸと申します。
」に相当）
以上の計 3 回のやりとり（3 方向ハンドシェイク）によりコネクションが確立する。また
これらの通信中に，以降の通信で使用する最大セグメント長（MSS: Maximum Segment Size）,
初期シーケンス番号，初期ウィンドウサイズが決められる。最大セグメント長とは，一つ
のセグメント内に格納可能な，アプリケーションデータの最大長のことである（シーケン
ス番号，ウィンドウサイズについては後述）。
被接続（サーバ）側
接続（クライアント）側
CLOSE
SYN_SENT
LISTEN
① SYN
② SYN + ACK
SYN_RCVD
PiggyBack
ESTABLISHED
③ ACK
ESTABLISHED
図 7.2.1 3 方向ハンドシェイク
図 7.2.1 の PiggyBack（ピギーバック）とは，他の通信データ（セグメント）に確認応答
（ACK）の信号を相乗りさせて返す手法である。この場合は，問い合わせ（SYN）用のセグ
メントに，一つ前の SYN の対する確認応答（ACK）を相乗りさせて，一つのセグメントとし
て送信している。TCP は重いプロトコルなので，なるべく通信量を減らすためにこのような
手法が用いられる。
また図中の CLOSE や LISTEN などの英字は TCP の状態変化を示している（TCP の状態遷移
については，図 7.2.13 を参照）
。
7.2.2 TCP におけるコネクションの終了【中級】
コネクションの一般的な終了は以下の手順で行なわれる（図 7.2.2）
。なお，切断のリク
エストを発信した切断側の処理をアクティブクローズと呼び，リクエストを受けた被切断
側の処理をパッシブクローズと呼ぶ。
一般的なコネクションの終了手順
1. 切断側から被切断側に，コードビットの FIN フラグが ON になったセグメントを送信す
る。
2. 被切断側から切断側に，FIN セグメントへの返答である，コードビットの ACK フラグが
ON になったセグメントを返信する。もしこの時，被切断側に未送信のデータが残ってい
れば，引き続き切断側に残りのデータが送信される。このときの切断側の状態をハーフ
クローズ状態（FIN_WAIT_2 状態）と呼ぶ。ハーフクローズ状態とは，データの送信は終
了しているが，受信は可能な状態のことである。
3. 被切断側から切断側に，コードビットの FIN フラグが ON になったセグメントを送信す
る。もし 2 で被切断側に未送信のデータがなければ，PiggyBack により，2 の最初の ACK
と合わせて FIN + ACK のセグメントを送信してもよい。この場合，切断側はハーフクロ
ーズ状態（FIN_WAIT_2 状態）になることはない。
4. 切断側から被切断側に,FIN 対する ACK の返答セグメントを返す。ただし，この ACK セグ
メントが被切断側に届かない場合を考慮し，切断側は最大セグメント寿命（MSL：Maximum
Segment Lifetime：セグメントを送信するのに必要な最大時間）の 2 倍の時間だけ，3
における被切断側からの FIN セグメントの（あるかどうか分らない）再送を待つ
（TIME_WAIT 状態）
。なお，TCP のソケットオプションにより，この待ち時間を 0 にする
ことも可能である（推奨はされない）。
5. 切断側は，被切断側からの FIN セグメントの再送待ちがタイムアウトすれば，そのまま
コネクションを切断する。FIN セグメントの再送があれば，ACK の返答セグメントを返
して，再び，FIN セグメントの再送を 2MSL だけ待つ（TIME_WAIT 状態）。
6. 最後の ACK セグメントが被切断側に届けば，被切断側はコネクションを切断する。
被切断側
切断側
ESTABLISHED
ESTABLISHED
アクティブクローズ
① FIN
FIN_WAIT_1
パッシブクローズ
CLOSE_WAIT
② ACK
残Data の送信
FIN_WAIT_2
残Data
ハーフクローズ状態
残Dataに対するACK
切断処理
③ FIN
LAST_ACK
④ ACK
TIME_WAIT
⑤ FIN
2MSL
⑥ ACK
CLOSE
CLOSE
図 7.2.2 一般的な TCP コネクションの終了
コネクションの終了において，特別な場合として，通信を行っている両者が（ほぼ）同
時にクローズ処理を行う（FIN セグメントを送信する）場合がある
（同時クローズ。図 7.3.3）。
この場合は，お互いに CLOSING 状態と呼ばれる状態に移行した後，相手の ACK セグメン
トの受信により TIME_WAIT 状態（相手の再送を 2MSL だけ待つ状態）に遷移し，タイムアウ
トにより通信をクローズする。
切断側
切断側
ESTABLISHED
ESTABLISHED
アクティブクローズ
FIN_WAIT_1
CLOSING
① FIN
② ACK
① FIN
② ACK
TIME_WAIT
アクティブクローズ
FIN_WAIT_1
CLOSING
TIME_WAIT
2MSL
2MSL
CLOSE
CLOSE
図 7.2.3 TCP の同時クローズ
7.2.3 ウィンドウ制御による通信の効率化とフロー制御【中級】
TCPでは，送信したデータセグメントについては，ACKセグメントによる確認応答を期待
する。ACKセグメントによる確認応答では，受信側が次に期待するデータのバイト番号（何
バイト目から送信して欲しいか）を指定する確認応答番号が送信側に伝えられる。
送信側では，データセグメントを送信後，再送タイムアウト（RTO: Retransmission Time
Out）の時間内に確認応答が返って来なければ，データセグメントの再送を行う。ただし，
この確認動作を1セグメント毎に行っていたのでは，通信効率が非常に悪くなってしまう
（図7.2.4）
。
そこで，確認応答を待たずに処理可能なデータのサイズを決めて，先送りでデータを転
送してしまう手法が用いられる（図 7.2.5）
。これはウィンドウ制御と呼ばれ，確認応答を
待たずに処理可能なデータのサイズをウィンドウサイズ（バイト単位）と呼ぶ。ウィンド
ウ制御によって，一度に転送できる最大セグメント数は
ウィンドウサイズ / 最大セグメント長（MSS）
となる。
受信側
送信側
データ①を送信
データ①のACK，
データ②の要求
データ②を送信
再送タイム
アウト（RTO）
×
データ②を再送信
データ②のACK，
データ③の要求
図 7.2.4 確認応答とデータの再送
図 7.2.5 では，一度に転送できるセグメント数は 5 であり，送信側が①～⑤のセグメン
トを送信後に，③に対する転送要求（②に対する ACK）を受信した段階で，⑥，⑦のセグメ
ントが送信可能になる。この時のウィンドウの様子を図 7.2.6 に示す。
ウィンドウ制御におけるウィンドウは送信バッファに付けられた処理用の窓のようなも
のである。送信バッファ内のデータはこのウィンドウ（窓）を通して操作される。送信側
は，転送要求の ACK を受信する度にウィンドウを右方向に移動（スライド）させ，それに
従って新たなデータが次々に送信可能となる。このようにして，ウィンドウをスライドさ
せる手法をスライディングウィンドウと呼ぶ（図 7.2.5）。
ウィンドウがスライドした直後の状態では，ウィンドウに対応する送信バッファ中のデ
ータは，「送信済みであるが ACK を未受信」か「送信可能」の何れかになる。また，ウィン
ドウの左端は，必ず直近に受信側から要求されたセグメントが対応する。
また，ウィンドウ制御では，ウィンドウサイズを動的に変化させることにより，TCP によ
るフロー制御を実現することができる。
例えば，送信側からのデータ転送のスピードを遅くしたい場合には，ウィンドウサイズ
を小さくして送信側に通知すればよい。またウィンドウサイズを 0 にして送信側に通知す
れば，送信側からのデータ転送を中断させる事が可能である。
送信側
⑤を送信後に，②の
ACK（ ③の要求）を
受信した時点で，⑥
⑦が送信可能になる
受信側
①を送信
②を送信
③を送信
④を送信
⑤を送信
①のACK,②の要求
②のACK,③の要求
③のACK,④の要求
④のACK,⑤の要求
⑤のACK,⑥の要求
⑥を送信
⑦を送信
⑧を送信
⑨を送信
⑩を送信
⑥のACK,⑦の要求
⑦のACK,⑧の要求
⑧のACK,⑨の要求
⑨のACK,⑩の要求
⑩のACK,⑪の要求
図 7.2.5 ウィンドウ制御下でのデータ転送
直近の要求（確
認応答番号が指
す）セグメント
データ
ウィンドウの位置と重なる
バッファのデータは，ACK
未受信か送信可能な状態に
ある
ウィンドウ
ウィンドウサイズ
送信バッファ
①
ACK を受信する度
に右方向へスライ
ドさせる
②
ACK受信済み
③
④
⑤
ACK未受信
⑥
⑦
⑧
送信可能
⑨
⑩
送信不可
図 7.2.6 ウィンドウ（前図で②の ACK を受信した直後の状態）
7.2.4 TCP の確認応答と不着処置【中級】
送信側からデータが送信された後に，受信側からの ACK セグメントが送信側に到着しな
い原因としては，1) 受信側からの ACK セグメントが途中で欠落（ロス）した場合と，そも
そも 2)送信側からのデータが受信側に届いていない場合が考えられる。
1) 受信側からの ACK セグメントが送信側に届かない場合
TCP のウィンドウ制御では，受信側からの任意の ACK セグメントが送信側に届かなくとも，
その後のいずれかの ACK セグメントが送信側に届けば，特に問題は発生しない（ただし通
信の効率は落ちる。図 7.2.7）。これは直近に受信した ACK の確認応答番号によりウィンド
ウがスライドするためである（図 7.2.8）。
簡単に言えば，ウィンドウ制御では，送信側が任意の送信データに対する ACK セグメン
トを受信した場合には，それ以前の送信データも全て正しく受信側に受信されたと認識さ
れるのである。
ただし，最終データの送信の場合は，その ACK が送信側に届かなければ，送信側では再
送タイムアウト後にデータの再送が行われる。受信側では同じものを複数受信することに
なるが，重複したデータは破棄される。
受信側
送信側
①を送信
②を送信
③を送信
④を送信
⑤を送信
④のACK（⑤の要求）
を受信した時点で，⑧
⑨が送信可能となる
①のACK,②の要求
②のACK,③の要求
③のACK,④の要求
④のACK,⑤の要求
⑤のACK,⑥の要求
×
⑥を送信
⑦を送信
⑧を送信
⑨を送信
×
⑦のACK（⑧の要求）
を受信した時点で，
⑩～⑫が送信可能と
なる
⑥のACK,⑦の要求
⑦のACK,⑧の要求
×
図 7.2.7 ACK が不着の場合
直近の要求（確認
応答番号が指す）
セグメントデータ
ウィンドウ
送信バッファ
①
②
ACK受信済み
ACK未受信
③
④
ACK受信済み
⑤
⑥
ACK未受信
⑦
⑧
⑨
送信可能
⑩
送信不可
図 7.2.8 前図で④の ACK を受信した状態でのウィンドウ
2) 送信側からのデータセグメントが受信側に届かない場合
送信側からのデータセグメントが受信側にと届かない場合，受信側は送信側に，ACK セグ
メントの確認応答番号を使用して，届かなかったセグメントの送信（再送）を届くまで繰
り返し要求する。
送信側では，任意のデータセグメントについて，受信側から連続して 3 回の送信要求を
受信した時点でデータの再送を行う（図 7.2.9）
。受信側では，再送要求を出したデータセ
グメントを受信した場合，（シーケンス制御により）既に受信を完了しているデータに統合
し，次のデータの要求を載せた ACK セグメントを返す。
図 7.2.9, 図 7.2.10 では，送信側に⑦の要求を含んだ ACK セグメントが返ることによっ
て，ウィンドウのスライディングが発生し，⑦～⑪までのセグメントが送信可能に変化し
ている。
受信側
送信側
①を送信
②を送信
③を送信
④を送信
⑤を送信
②の要求を３回受
信したので，②を
再送する
×
①のACK,②を要求
⑥を送信
③のACK,②の要求
④のACK,②の要求
⑤のACK,②の要求
②を再送
⑥のACK,②の要求
⑦の要求を受信した
時点で，⑦～⑪が送
信可能となる
②のACK,⑦の要求
⑦を送信
⑧を送信
⑨を送信
⑩を送信
⑪を送信
図 7.2.9 送信データが不着の場合
ACK受信済
み
①
ACK未受信
②
ACK受信済み
③
④
ACK未受信
⑤
⑥
送信可能
⑦
⑧
⑨
⑩
⑪
前図で②を再送した時点でのウィンドウ
前図で⑦の要求を受信した時点でのウィンドウ
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩
⑪
送信可能
ACK受信済み
図 7.2.10 前図におけるスライディングウィンドウ
TCP の確認応答は非常に厳密な処理であるが，これは開発当時のネットワークの回線状態
が現在のよりも非常に悪く，ノイズによる誤りが発生し易いものであったためである。現
在のネットワーク回線の品質を考えれば，TCP の確認応答処理は厳密すぎる（オーバースペ
ックである）と言われている。
7.2.5 シーケンス制御とエラー処理
TCP 通信においては，図 7.2.9 に見られるように，セグメントの順番が前後して受信側に
届く場合がある。この場合，受信側ではシーケンス番号を元に，データの並べ替えを行う。
この並べ替えの機能をシーケンス制御と呼ぶ。
なお，シーケンス番号とは TCP のコネクションを維持するためのセグメントの順序番号
のことであるが，その一部に転送データ全体に対するそれぞれのセグメントデータのバイ
ト位置を示す情報が含まれている。シーケンス制御ではこの情報を利用してセグメントデ
ータの並び替えを行う。
また，TCP では TCP チェックサムと呼ばれる独自のエラーチェックが行われる。TCP チェ
ックサムは通常のチェックサムではなく，CRC とも違う独自のものである。
もし，TCP チェックサムによりエラーが検出された場合には，
（そのデータは受信側に届
かなかったのと同等であるので）7.2.4 節の「2) 送信側からのデータセグメントが受信側に届
かない場合」と同じ手法により，データの再送処理が行われる。
7.2.6 シーケンス番号によるコネクションの制御【中級】
TCP 通信では，通信相手との間にコネクションを張ってストリーム型の双方向通信を行う。
しかしながら，通信相手とのコネクションは仮想的なものであり，電話回線のように物理
的な接続回線が存在するわけではない。
仮想的なコネクションを維持するために，TCP では前節のシーケンス番号と確認応答番号
を使用する。TCP では，セグメントをやり取りする際に，シーケンス番号と確認応答番号を
順次増加させて行き，一連のシーケンス番号と確認応答番号を持つセグメントを同じコネ
クションとして認識する（図 7.2.11）
。
シーケンス番号は受信側の受信済みデータの分だけ増加する（受信済みデータ量は ACK
の確認応答番号より知る）ので，前節のようにセグメントを正しく並べ替える際にも利用
される。
簡単に言えば，シーケンス番号は送信するデータのバイト番号（+自分の初期シーケンス
番号）であり，確認応答番号は次に送信して欲しいデータのバイト番号（+相手の初期シー
ケンス番号）である。
即ち，（データ通信中では，）自分が送信したセグメントの確認応答番号と，相手から送
られてきたセグメントのシーケンス番号が一致することにより，コネクションが維持され
る（図 7.2.11）。
被接続（サーバ）側
接続（クライアント）側
CLOSE
SEQ: 80000
SYN_SENT
LISTEN
SYN
初期シーケンス
番号
SYN + ACK
SEQ: 80001
ACK: 60001
初期シーケンス
番号
SEQ: 60000
ACK: 80001
SYN_RCVD
ACK
ESTABLISHED
ESTABLISHED
SEQ: 80001
ACK: 60001
Request
300Byte送信
SEQ: 60001
ACK: 80301
ACK
Response
SEQ: 80301
ACK: 61001
SEQ: 60001
ACK: 80301
1000Byte送信
ACK
SEQ: 80301
ACK: 61001
Request
400Byte送信
ACK
………
SEQ: シーケンス番号
ACK: 確認応答番号
SEQ: 61001
ACK: 80701
図 7.2.11 シーケンス番号，確認応答番号の推移
TCP のコネクションはシーケンス番号（と確認応答番号）により維持される。従って，も
し第 3 者がシーケンス番号を予測することが可能であるなら，TCP のコネクションはこの第
3 者に乗っ取られてしまう可能性がある。TCP のシーケンス番号を予測して，コネクション
を乗っ取る攻撃法を TCP シーケンス番号予測攻撃と呼ぶ。
短い時間内に接続を繰り返すような TCP 通信を行っている場合，通信中のネットワーク
盗聴により，シーケンス番号を予測することは一般には困難である（TCP のコネクションが
十分長い時間維持されるような場合には，予測および攻撃は可能）
。しかしながら，初期シ
ーケンスの生成パターンを予測することができれば，以降の通信でのシーケンス番号を予
測することは比較的容易となる。
従って，現在の TCP の実装では，初期シーケンス番号の生成アルゴリズムとして，容易
に推測することが困難なアルゴリズムが使用されている。
7.2.7 TCP セグメントの構造【中級】
TCP/IP での TCP セグメントの構造を以下に示す。
( ) 内は該当データのビット長。
送信元ポート番号(16)
宛先ポート番号(16)
シーケンス番号(32)
確認応答番号(32)
ヘッダ長(4)
予約(6)
コードビット(6)
TCP チェックサム(16)
ウィンドウサイズ(16)
緊急ポインタ(16)
ヘッダオプション(可変長)
アプリケーションデータ（可変長）
 シーケンス番号：転送するデータの順序番号。
 確認応答番号：受信側が次に期待するデータのバイト番号（何バイト目から送って欲しいか
指定する）
 ヘッダ長：ヘッダの長さ（4O バイト単位）
。ヘッダオプションがない場合は 5（200Byte）
。
 予約：将来のための予約領域。通常は 0。
 コードビット：セグメントのタイプ（USG, ACK, PSH, RST, SYN, FIN）を示すフラグ。
 ウィンドウサイズ：一度に受信可能なウィンドウのサイズ（バイト単位）。
 TCP チェックサム：TCP セグメント全体のチェックサム（特殊な計算方法によるチェックサム。
CRC ではない）
 緊急ポインタ：緊急データ(URG)を処理中の場合，緊急データの終わりを表す。
 ヘッダオプション：最大セグメント長（MSS）の通知に使用される。長さは最大 40 バイト.
 アプリケーションデータ：アプリケーションが使用するデータ。
図 7.2.12 TCP セグメントの構造
7.2.8 TCP State Diagram 【中級】
以下に TCP の状態遷移の図を示す。TCP では，SYN,ACK,FIN のコードビットが設定された
セグメントの送受信により，図のように状態が変化する。
Active Open, or send SYN
CLOSED
Close
Close
received SYN, send SYN + ACK
Passive Open
send SYN
LISTEN
received SYN, send ACK
SYN_RCVD
received ACK of SYN
SYN_SENT
received SYN+ACK,
send ACK
ESTABLISHED
send FIN
send FIN
FIN_WAIT_1
received FIN,
send ACK
received FIN, send ACK
received FIN+ACK,
send ACK
received ACK
of FIN
FIN_WAIT_2
received FIN,
send ACK
CLOSE_WAIT
CLOSING
received ACK
of FIN
send FIN
LAST_ACK
TIME_WAIT
Passive Close
Active Close
CLOSED
2SML time out
received ACK of FIN
図 7.2.13 TCP の状態遷移図
7.3 UDP（User Datagram Protocol）
7.3.1 UDP のコネクションレス指向通信
UDP は TCP と違い，コネクションレス指向のデータグラム型通信のプロトコルである。そ
のため UDP での通信はコネクションを張らず，それぞれの通信は１回限りの送信または受
信のみで終了する。
信頼性の全く無い，ベストエフォート型（最大努力型：努力はするが，結果は保証でき
ないということ）で，相手がセグメントを受信したかどうかの確認は一切行われない。無
論エラー検査も行われない。UDP の通信は，しばしば手紙に例えられ，ポストへの投函以降，
手紙の配達状況を全く知ることができない状況に良く似ている。
しかしながら，TCP のように一々確認応答を行わないので，単純で動作が軽く，高速に大
量のデータを転送することが可能である。その特性のため，データの品質より速度が優先
されるような状況で使用される。
例えば音声や動画データの通信では，大量のデータを高速に転送する必要があるが，途
中でデータが少しばかり欠落（ロス）しても，相手が人間であれば十分に理解可能である
ので，信頼性はあまり問題にならない場合が多い。
UDP を使用する代表的なプロトコルとしては，インターネット上の最も重要なシステムで
ある DNS（Domain Name System）やセッション管理用の SIP（Session Initiation Protocol)，
音声や映像をストリーミング再生するための RIP（Real-time Transport Protocol）などが
ある（詳細については「第 8 章ネットワーク上のアプリケーション」の章を参照）
。
7.3.2 UDP セグメントの構造【中級】
TCP/IP での UDP セグメントの構造を以下に示す。TCP セグメントに比べてかなり単純な
構造となっている。
( )内は該当データのビット長
送信元ポート番号(16)
宛先ポート番号(16)
UDP データ長(16)
UDP チェックサム(16)
アプリケーションデータ(UDP データ：可変長)
 UDP データ長：アプリケーションデータのデータ長 (バイト単位)。
 UDP チェックサム：UDP セグメント全体のチェックサム（特殊な計算方法によるチェックサム。
CRC ではない）
 アプリケーションデータ：アプリケーションが使用するデータ。
図 7.3.1 UDP セグメントの構造
7.4 ポート番号
7.4.1 ポート番号によるプロセスの識別
TCP や UDP でプロセス間通信を行う場合，相手のプロセス（接続しようとするプロセス）
はポート番号と呼ばれる番号（0～65535:16bit の符号なし整数）で識別される。ポート番
号のイメージとしては，ノード内のプロセスはそれぞれポートと呼ばれる通信データ用の
入出力口に繋がっており，そのポートを介して通信が行われるような状況を思い浮かべれ
ば良い（図 7.4.1）.この場合，それぞれのポートには識別用の番号が割り振られており，
それがポート番号である。
また，TCP と UDP では別々のポートが使用されるため，同じ番号のポートを TCP と UDP で
同時に使用することも可能である。
なお，ここでのポートは論理的な通信データの入出力口であり，スイッチングハブなど
の物理的な通信ポートとは全く別物である。
プロセス空間
プロセス空間
ポート
図 7.4.1 ポートを介したプロセス間通信のイメージ
あるノード内の任意のプロセスは IP アドレスとポート番号が分れば，ネットワーク上で
一意的に識別する事が可能となる。特定のプロセスを指定するのに，IP アドレスとポート
番号を：（コロン）で繋げて，IP アドレス：ポート番号の形で指定する場合もある。例え
ば，IP アドレス 202.26.158.1 のノード上で 80 番のポート番号を持つプロセスは
202.26.158.1:80
と表される。
なお，特定のプロセスとの通信は，そのプロセス専用の通信プロトコルを使用して行わ
れるので，プロセスとプロトコルを同一視して，ポート番号をプロトコルを表す番号とし
て用いる場合も多い。
7.4.2 ポート番号の割り当て
ポート番号と実際のプロセスとの対応付けはノード管理者の責任であるが，勝手に対応
付けを行うと他のマシンから接続できない状況が発生するので，特別な場合を除いては標
準的な番号が割り振られる。
特にポート番号が 1023 番以下のポートはウェルノンポート（well known port）と呼ば
れ，代表的なサーバプロセスがそれらのポートを使用することになっている（例えば WEB
サーバは 80 番，メールサーバは 25 番など）。なお，ウェルノンポートに割り当てられるポ
ート番号の管理は，ICANN の IANA によって行われている。
（IACNN,IANA については「5.2 IP
アドレス」の注釈を参照）
ポート番号の 1024～49151 番は，各ソフトウェアベンダーが自社のソフトウェア用に
INANA（ICANN）に申請したもので，登録ポート（Registered Port）と呼ばれる。
また，それ以上の 49152～65535 番のポートは，ダイナミック/プライベートポートと呼
ばれている。ダイナミックポートはエフェメラルポート（Ephemeral Port：短命ポート）
とも呼ばれ，システムが使用するポートであり，クライアント（接続）側などで，特にポ
ート番号を明示的に指定しないでポートをオープンした場合などに，この範囲のポート番
号が自動的に割り振られる（次節参照）
。プライベートポートのポート番号は，一般のユー
ザが自由に使用しても良いポート番号である。
INANA（ICANN）の http://www.iana.org/assignments/port-numbers には INANA（ICANN）
が管理するウェルノンポートおよび登録ポートの一覧が記載されている。また，Linux や
Unix では， /etc/services と言うファイルにも，主なプロセスとそのポート番号の対応が
記述されている。
表 7.4.2 に代表的なプロセス（プロトコル）とその標準的なポート番号を示す。
ポート番号
プロトコル
説
明
20
FTP-data
21
FTP
ファイル転送用プロセスのコントロール
22
SSH
暗号化されたリモートシステムへの接続
23
TELNET
25
SMTP
メールサーバ
53
DNS
ドメインネームシステム
80
HTTP
WWW サーバ
110
POP3
メールの受信
443
HTTPS
暗号化された WWW サーバ
ファイル転送用プロセスでのデータの送受信
リモートシステムへの接続
表 7.4.2 代表的なプロセス(プロトコル)のポート番号
7.4.3 クライアント・サーバ（C/S）モデルでのポート番号
サーバプロセスは，ネットワーク上でサービスを提供するプログラムであり，クライア
ントプロセスは，サーバプロセスからのサービスを利用するプログラムである.一般的に，
この通信体系をクライアント・サーバ（C/S）モデルと呼ぶ。
ネットワーク上のサーバプロセスは，その起動時に，明示的に指定された番号を持った
ポートを開いて，クライアントプロセスからの接続を待ち受ける（例えば WEB サーバなら
ば 80 番）
。従って，クライアントプロセスがサーバプロセスに接続するためには，ノード
（サーバ）の IP アドレス注）とプロセスのポート番号が予め必要となる。
（以後，サーバプ
ロセスをサーバ，クライアントプロセスをクライアントと記述する）
クライアントが IP アドレスとポート番号を使用して，サーバに接続した場合，クライア
ントがオープンしたポートには，通常では，システムにより自動的にポート（ダイナミッ
クポート/エフェメラルポート）番号が割り振られる（プログラミングの段階で明示的に番
号を指定することもできる）
。サーバ側では，クライアントからの最初の接続時に，その通
信データからクライアントの IP アドレスとポート番号を知ることができるので
（図 7.4.3），
これらを利用してクライアントに返答を返す。
結局のところ，クライアント・サーバモデルでのクライアント側では，自身の IP アドレ
スとポート番号についは，全く気にする必要は無いことになる
サーバ
クライアント
サーバの IPアドレスとポート番号
を指定して接続
クライアントの IPアドレスと
ポート番号も通知される
ポート番号は，通常はシステムが
自動的に付与する
サーバポートのポート番号は
明示的に指定される。
図 7.4.3 クライアント・サーバモデルでのポート番号
注）ドメイン名（正確には FQDN）を指定してもネットワーク上のノード（サーバ）を指定
可能であるが，ドメイン名（FQDN）は結局は IP アドレスに変換されるので，ここではドメ
イン名（FQDN）の事は考慮しないこととする。
7.5 ポートスキャン
7.5.1 ポートスキャナ
サーバマシンで稼動しているサーバプロセス（ポート）のチェックを行う行為をポート
スキャンと呼び，ポートスキャンを行うプログラムをポートスキャナと呼ぶ。
ポートスキャナは，通常ではサーバマシンを攻撃する場合に，事前にそのマシンの情報
収集を行うために実行される（自分の管理するサーバマシンのセキュリティホールを検査
するために用いられる場合もある）。ポートスキャナは，サーバに接続ログ（記録）を残さ
ないようにしたり，ちょっとした反応からサーバプロセスのバージョンを割り出すなど，
非常に巧妙な手法でサーバマシンの情報を収集する。
従って，サーバ上では不要なサーバプロセスは必ず停止するようにしないと，クラッカ
ー（攻撃者）に有益な情報を与えてしまうことになる。
7.5.2 telnet コマンドによる手動 TCP ポートスキャン【中級】
telnet コマンドを利用すると，TCP のポートに直接接続することが可能となる。TCP ポー
トに接続して，サーバプロセスに対してコマンドを入力することも可能だが，単に指定し
た TCP ポートでサーバプロセスが作動しているかどうかの確認としても使用できる。
例えば，サーバ名 www.tuis.ac.jp，ポート番号 80 番（WWW サーバ）に接続する場合は，
telnet www.tuis.ac.jp 80
とする。
接続に失敗した場合は，接続失敗のエラーメッセージが表示される。接続に失敗したと
言うことは，指定したポートでサーバプロセスが稼動していないことになる。
一方，接続に成功した場合は，何も表示されないか，またはエラーメッセージ以外のメ
ッセージが表示される（メッセージの内容はサーバプロセスの種類による）
。接続に成功し
た場合は，指定したポートでサーバプロセスが稼動していることになる。
接続に成功した場合は，その後，クライアントからのキー入力（リクエスト）待ちとな
る場合が多い。大抵の場合は，この状態で何か入力すると，コマンドエラーで telnet コマ
ンドから抜けるが，どうしても telnet コマンドから出られない場合は，Ctrl+] とキー入
力し，telnet> のプロンプト（入力要求）が表示されたら，quit と入力すれば telnet か
ら抜けることができる。
例） telnet> quit
【MS Windows】
MS Windows では，コマンドプロンプトから telnet コマンドを入力する。
ただし，MS Widows の Vista は標準では telnet コマンドを使用できない。Vista で telnet
コマンドを使用できるようにするには，コントロールパネルから「プログラム」を選択し，
さらに「プログラムと機能」を選択する。コントロールパネルをクラシック表示にしてい
る場合は，コントロールパネルから直接「プログラムと機能」のアイコンをクリックする。
「プログラムと機能」が起動したら，タスクの「Windows 機能の有効化または無効化」を
クリックし，次に表示された画面で「Telnet クライアント」にチェックを入れ，OK をクリ
ックする。
図 7.5.1 に MS Windows の telnet で接続に失敗した例を示す。接続に成功した場合は，
前節にあるように接続エラー以外の何らかの反応が返る（反応の内容はサーバプロセスに
よって異なる）。
C:\Users\guest> telnet 192.168.27.7 30
接続中: 192.168.27.7...ホストへ接続できませんでした。ポート番号 30: 接続に失敗しました
図 7.5.1 MS Windows で telnet が接続に失敗した場合
【Linux/Unix】
Linux/Unix の場合はそのままコンソールから telnet コマンドを起動することができる。
図 7.5.2 に Linux での接続失敗の例を示す。接続に成功した場合は，接続エラー以外の
何らかの反応が返る。
$ telnet 192.168.27.7 30
Trying 192.168.27.7...
telnet: connect to address 192.168.27.7: Connection refused
telnet: Unable to connect to remote host: Connection refused
図 7.5.2 Linux で telnet が接続に失敗した場合
7.6 練習問題
【問題】
1. トランスポート層の機能を 3 つ選択しなさい。
□ a. 違うネットワークのマシンにセグメントを転送する
□ b. 暗号化と復号化
□ c. 上位データをセグメント化する
□ d. 通信経路の決定
□ e. プロセス間通信
□ f. 高信頼性通信
2. TCP 通信でフロー制御を行うために動的に変化させるパラメータは何か？
○ a. UNIX サイズ
○ b. Linux サイズ
○ c. Mac サイズ
○ d. Window サイズ ○ e. BSD サイズ
3. TCP, UDP において，通信相手のプロセスを識別する手段は何か？
○ a. プロセス番号
○ b. MAC アドレス
○ c. ポート番号
○ d. プロセス名
○ e. IP アドレス
4. TCP 通信において，データ通信に先だって行われるハンドシェイクの方法を俗に何と呼
ぶか？
○ a. 3 方向ハンドシェイク
○ b. 2 方向ハンドシェイク
○ c. 1 方向ハンドシェイク
○ d. TCP ハンドシェイク
○ e. デュアルハンドシェイク
5. TCP/IP において，トランスポート層で接続を維持しない低信頼性のプロトコルは何
か？
○ a. RIP ○ b. TCP ○ c. UDP ○ d. イーサネット
○ e. IP
6. トランスポート層の高信頼性通信を保障する機能を 3 つ選択しなさい。
□ a. トークンパッシング
□ b. CSMA/CD
□ c. 伝送データの訂正機能
□ d. 伝送データの誤り検出と再送要求
□ e. データフロー制御
□ f. シーケンス制御
7. 【中級】自組織内のサーバに対して，次に示すポートへ telnet でアクセスし，サーバ
プロセスが作動しているかどうか確認せよ（必要なら事前に管理者に連絡を入れておく
こと）
21, 22, 23, 25, 80, 110, 443, 3306
【解答】
1. c, e, f
2. d
3. c
4. a
5. c
6. d, e, f
7. -

Download Report