6．1 トランスポート層の役割

６章まとめ
４４０６０１１岩瀬彰宏
６．１トランスポート層の役割
トランスポート層とは・・・
 次にどのアプリケーションにパケットを渡せばよいか識別する
 通信をする「プログラム」を指定する役割
この役割を実現する手法
－ポート番号という識別子
宛先の判断
通信の処理（１）
クライアントがサーバにサービスなどを要求
サーバーが要求を処理してサービスを提供
この際に、サ－バープログラムが起動されて
いる必要がある
通信の処理（２）
 サーバープログラム
・UNIX・・・デーモン（Demon）
HTTPでは、httpd（HTTPデーモン）
TELNETでは、telnetd（テルネットデーモン）
 さらに、この代表として、inetdというスーパーデーモンも
存在
通信の処理（３）

要求がどのパケットに向けられたものかは宛先ポート番号で識
別
ex）TCPの接続要求パケット受信
ポート番号が２３番
telnetd
８０番
ｈｔｔｐｄ

ＴＣＰ、ＵＤＰのトランスポートプロトコルは、受信したデータの宛
先をポート番号で特定
ＨＴＴＰの接続要求
TCPとUＤP（１）
 代表的なトランスポートプロトコルには、
「TCP」と「UＤP」が存在
TCPはTransmission Control Protocol
UDPはUser Datagram Protocol
の略
TCPとUＤP（２）
 TCP
－コネクション志向で、信頼性のある
ストリーム（切れ目がないデータ構造）型
プロトコル
－送信した順に相手にデータが届く
だが、データの切れ目が不明
TCPとUＤP（３）
 TCPでは、信頼性の提供
・順序制御
・再送制御
・フロー制御（流量制御）
・ふくそう回避制御
このほかに、ネットワークの利用効率を向
上させる仕組みなど、多機能
TCPとUＤP（４）
 ＵＤＰ
－信頼性のないデータ型プロトコル
－細かい処理は上位層のアプリケーションが決定
－データの大きさは保たれるが、パケットが到達
する保障はない
再送処理が必要な場合もある
ソケット（１）
 TCPやUDPを利用する時に使われるAPI
（Application Programming Ｉｎｔｅｒｆａｃｅ）の名称。
 アプリケーションはソケットを利用して、通信相手のIP
アドレスやポート番号を設定したり、データの送受信
の要求をする。
ソケット（２）
TCPとUDPの使い分け
 トランスポート層で信頼性のある通信を実現する必
要がある場合にはTCP
 同報通信、高速性やリアルタイム性重視の通信には
UDP
6.2 ポート番号
16
ポート番号とは
 トランスポートプロトコルにおけるアドレス
 同一コンピュータ内で通信を行っている複数のプロ
グラムを識別する
17
ポート番号によるアプリケーションの識別
 トランスポートプロトコルは、ポート番号を使って、
通信しているプログラムを識別する
ホストA １７２．２３．１２．１４
TELNET
FTP
SMTP
HTTP
FTP
HTTP
サーバー
サーバー
サーバー
サーバー
サーバー
サーバー
ポート番号
TCP２１
ポート番号
TCP２３
ポート番号
TCP２５
ポート番号
TCP８０
ポート番号
TCP２０００
ポート番号
TCP２００１
どの処理にデータを渡すのかな？
データ
＆ IP
18
宛先１７２．２３．１２．１４
ＩＰアドレスとポート番号とプロトコル番号による通信の識別
 宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート番号、
送信元ポート番号、プロトコル番号の５つの数字を組み
合わせて通信を識別
19
20
ポート番号の決め方
 静的な割り当て方法
アプリケーションごとに、ポート番号を固定的に割り
当てる方法。（ウェルノウンポート番号）
 動的な割り当て方法
サービスを受ける側のアプリケーションが、自分のポー
ト番号を決定せずに、OSが割り当てる方法。
21
ポート番号とプロトコル

ポート番号は使用されるトランスポートプロトコルごとに決定。
ex)TCPとUDPで同じポート番号を使用可能
データがIP層に到着すると、IPヘッダ中のプロトコル番号がチェックされ、
それぞれのプロトコルのルーチンに渡される。
 ウェルノウンポート番号はプロトコルに関係なく同じ番号は同じアプリ
ケーションに割り当てられる。

22
6.3.1 ＵＤＰの目的と特徴
 ネットワークが混雑していたとしても、送信量
を制御しない。
 パケットが失われても、再送制御はしない。
 これらの制御が必要なら、ＵＤＰを利用する
アプリケーションプログラムが制御しなければ
ならない。
23
ＵＤＰの用途
 総パケット数が少ない通信
 動画や音声などのマルチメディア通信
 ＬＡＮなどの特定のネットワークに限定したア
プリケーションの通信
 同報性が必要な通信（ブロードキャスト、マ
ルチキャスト）
24
ＴＣＰ
TCPの目的と特徴
 伝送、送信、通信を制御するプロトコル。
 送信時の制御機能が充実。
 ＩＰというコネクションレス型のネットワーク上で
高い信頼性。
シーケンス番号と確認応答
 受信ホストが送信ホストに到達
したことを知らせる。
 無事に届いたときのみ応答。
A
時
間
一
定
時
間
B
×
喪失
再送タイムアウト時間の決定
 再送せずに確認応答を待つ時間のこと。
 パケットを送信するためにラウンドリップ時間とその揺
らぎを計測し順応。
 ＵＮＩＸやWindowsは０．５秒単位で制御。
時
間
揺らぎが大きい場合
再送タイムアウト時間
RTT
コネクション管理
 ＴＣＰはコネクション指向の通信
を提供。
 ヘッダの制御用のフィールドを使
用。
セグメント単位でデータを送信
 コネクション確立時にデータ単位を決定。
 この最大データ長でデータが区切られて送信される。
ウィンドウ制御で速度向上
 １セグメントではなく大きな単位で。
6.4.8-11 TCP
（ＴＲＡＮＳＭＩＳＳＩＯＮＣＯＮＴＲＯＬＰＲＩＴＩＣＯＬ）
６.４.８フロー制御（流動制御）
•受信ホストが送信ホ
ストに対して受信可
能なデータサイズ
（ウィンドウサイズ）を
通知するようにする。
時
間
データ
１～１０００
確認応答
１００１～２０００
２００１～３０００
３００１～４０００
•受信側のバッファが
溢れそうになるとウィウィンドウ
ンドウの値を小さくしロープを定期
的に送信する
て送信ホストの送信
量を抑制する。このよ
４００１～５０００
うな処理をフロー制
５００１～６０００
御という。
ウィンドウ更新通知が途切れ、通信不能
になるのを避けるためウィンドロープと
呼ばれる小さなデータを送信する。
ウィンドウ
次は１００１
３０００
次は２００１
次は３００１
次は４００１
２０００
１０００
０
バッファが満
杯の状態
次は４００１
０
次は４００１
３０００
ウィンドウ更新通知
フロー制御の図
6.4.9 ふくそう制御(ネットワークの混雑解消)
＊ネットワークに、通
信開始時から大量の
パケットを送信すると
ネットワークがパンク
する可能性がある
＊その危険性をな
くすため、スロース
タートと呼ばれるア
ルゴリズムに従い
送信する
ふくそう
ウィンドウ
１０００
データ
１～１０００
２０００
２０００
１００１～２０００
３０００
４０００
４０００
４０００
３００１～４０００
４００１～５０００
５００１～６０００
６００１～７０００
確認応答
次は１００１
２００１～３０００
次は２００１
次は３００１
次は４００１
次は５００１
次は６００１
次は７００１
スロースタートの図
TCPのウィンドウの変化
ふくそうウィンドウ
の大きさ
タイムアウト
パケットが往復するたび
に、ふくそうウィンドウが
1・2・4と指数関数的に
急激に大きくなってしま
うのを防ぐために、ス
ロースタート閾値を用意
する
タイムアウト
重複確認応答
半分
1セグメント
ふくそうウィンドウ
ふくそう
ウィンドウ
半分
 １セグメント
3セグメント
スロースタート閾値
指数関数的
にウィンドウ
が増加
時間
6.4.10 ネットワークの利用効率を高める仕組み（１）

Nagleアルゴリズム
送信すべきデータがあっても、そのデータが少ない場合には
送信を遅らせる処理
・全ての送信済みデータが確認応答されている場合
・最大セグメント長（MSS）のデータを送信できる場合
以上の状態に当てはまる場合にTCPはデータを送信する
6.4.10 ネットワークの利用効率を高める仕組み（２）
 遅延確認応答
データを受信してもすぐに確認応答を行わないで
遅らせる方法
・２×最大セグメント長のデータを受信するまで確認
応答をしない
・そうでない場合は確認応答を最大で0.5秒遅延さ
せる
6.4.10 ネットワークの利用効率を高める仕組み（３）
 ピギーバック
確認応答と返事のデータパケットを1つのパケットで
送り、送受信するパケット数を減らすことができる
アプリケーションがデータを処理して返事のデータを
送信するまで確認応答が遅延されなければピギー
バックは起こらない
6.4.11 TCPを利用するアプリケーション
・
・
TCPの複雑な制御は時と場合により使い分けることが必要
アプリケーションが細かい制御をしたほうがよい場合は、UDP
を用いたほうがよい
・データの転送量が比較的に多く，信頼性が必要としているが、
難しいことを考えたくない場合にはTCPを用いるのがよい
6.5.その他のトランスポートプロトコル
6.5.1.UDP-LITE (LIGHTWEIGHT USER
DATAGRAM PROTOCOL)
ＵＤＰではチェックサムエラーが発生すると、パケット
全体が廃棄される
 映像や音声のデータフォーマットアプリケーションの
性能を低下させてしまう。
 ＵＤＰでチェックサムを外すと、ＵＤＰヘッダ中のポー
ト番号が壊れたパケットや、ＩＰヘッダ中のＩＰアドレス
が壊れたパケットを受信してしまう恐れがある。
それらの問題を解決するため、UDP-Liteでは・・・
UDP-Liteでは、チェックサムを計算する範囲をアプ
リケーションで決めることができる。
 パケット全体、ヘッダ、疑似ファイル、データの先頭
から途中まで、などの範囲が指定可能。
 エラーの発生してはいけない部分に関してのみ、
チェックサムで検査することができる。
6.5.2.SCTP (STREAM CONTOROL TRANSMISSION
PROTOCOL)
ＴＣＰと同様。特徴は
 メッセージ単位の送受信
 マルチホーミングに対応
 複数のストリームの通信
 メッセージの生存時間を定義できる
6.5.3.DCCP (DATAGRAM CONGESTION
CONTROL PROTOCOL)
ＵＤＰと同様に、データの到達性に関する信頼性は
ない。
 コネクション指向で、コネクションの確立と切断処理
がある。コネクションの確立と切断の処理には信頼
性がある。
 ネットワークの混雑に合わせた輻輳制御を行うこと
ができる。ＤＣＣＰを利用するアプリケーションの特
性により、「ＴＣＰライクな輻輳制御」と「ＴＣＰフレン
ドリーなレート制御」のどちらかの方法を選択できる。
 輻輳制御を行うため、パケットを受信した側は確認
応答（ＡＣＫ）を返す。この確認応答を使って再送
をすることも可能。

6.6.UDPヘッダのフォーマット
６．６UDPヘッダのフォーマット
１６bit
１６bit
送信ポート番号
Source Port
宛先ポート番号
Destination Port
パケット長
Length
チェックサム
Checksum
データ
data
UDP
ヘッダ
送信元ポート番号（SOURCE PORT）
 16ビット長のフィールドで、ポート番号を示す。
 指定しないことも可能（返事を必要としない通
信で利用）。
宛先ポート番号（ DESTINATION PORT ）

16ビット長のフィールドで、宛先のポート番号を示す。
パケット長（ LENGTH ）

UDPヘッダの長さとデータの長さの和が格納される。

単位はオクテット長。
チェックサム

UDPのヘッダとデータに信頼性を提供するためのもの。
チェックサムの計算方法
①
②
③
④
⑤
UDP擬似ヘッダをUDPデータグラムの前に付ける。
全長が１６ビットの倍数になるようにデータの最後
に”0”を追加する。
UDPヘッダのチェックサムフィールドを”0”にする。
16ビット単位で1の補数の和を求める。
求めた和の1の補数をチェックサムフィールドに入れる。
チェックサムの計算に利用するUDP擬似ヘッダ
８bit
８bit
１６bit
送信元IPアドレス
宛先IPアドレス
パディング
（詰め物）０
プロトコル番号
１７
UDPパケット長
6.7.TCPヘッダフォーマット
ＴＣＰのセグメントフォーマット
0
３１ビット
伝送元ポート番号
宛先ポート番号
シーケンス番号
確認応答番号
Ｄａｔ
ａ
Ｏｆ
ｆ
ｓｅｔ
予約
コントロー
ルフラグ
チェックサム
ウィンドウサイズ
ＴＣＰヘッダ
緊急ポインタ
オプション
パディング
データ
ＴＣＰ
ペイロード
送信元ポート番号・宛先ポート番号
 送信元ポート番号(Source
Port)
・・16ビット長のフィールドで、送信元
のポート番号を示す。
 宛先ポート番号(Destination Port)
・・・16ビット長のフィールドで、宛先の
ポート番号を示す。
シーケンス番号(SEQUENCE NUMBER)
 32ビット長のフィールドで示す。
 送信したデータの位置を意味する。
 データを送信するたびに、送信したデータのオクテット
数だけ値が加算される。
 コネクションを確立する時に初期値が乱数値で決
定され、SYNパケットで受信ホストに伝えられる。
確認応答番号
(ACKNOWLEDGEMENT NUMBER)
 ３２ビット長のフィールドで、確認応答番号を示す。
 確認応答番号は、次に受信すべきデータのシーケ
ンス番号になっている。
 送信側では、返された確認応答番号より前の
データまでは正常に通信が行われたと判断できる。



データオフセット(Data Offset)
４ビット長のフィールド、で単位は４バイト長である
予約(Reserved)
将来の拡張のために用意されている4ビット長の
フィールド
”0”にしておく必要があるが、0になっていないパ
ケットを受信したとしても破棄してはいけない
コントロールフラグ(CONTROL
FLAG)
8ビット長のフィールドで、制御ビットと呼ばれる。各ビットは
左からCWR,ECE,URG,ACK,PSH,RST,SYN,FINと名づけ
られる。

CWR：ECEフラグが1のパケットを受け取り、ふくそうウィンド
ウを小さくしたことを相手に伝える。

ECE：通信相手に、相手側からこちら側へのネットワーク
がふくそうしていることを伝える。
コントロールフラグ(CONTROL
FLAG)
 URG：このビットが”1”の場合は、緊急に処理
すべきデータが含まれていることを意味する。
 ACK：このビットが”1”の場合は、確認応答番
号のフィールドが有効であることを意味する。
コントロールフラグ(CONTROL
FLAG)
 PSH：このビットが”1”の場合は、受信したデータを
すぐに上位のアプリケーションに引き渡す。 “0”の
場合は、バッファリングが許される。
 RST：このビットが”1”の場合は、コネクションが強
制的に切断される。
コントロールフラグ(CONTROL
FLAG)
 SYN：このビットが”1”の場合は、コネクションの確
立したい意思表示を表し、シーケンス番号の初
期化が行われる。
 FIN：このビットが”1”の場合は、今後送信する
データがないことを意味し、コネクションを切断した
いと意思表示を意味する。
ウィンドウサイズ(WINDOW)
 １６ビット長のフィールドで、受信可能なデータのサ
イズを通知するのに使われる
・・・データのサイズはオクテット
 ここに示されているデータ量を超えて送信すること
は許されない
チェックサム(CHECKSUM)
 途中のルーターのメモリの故障やプログラムの
バグなどによるデータの破壊がないことを保障
するためのもの
 チェックサムを含むすべてのデータを足した結
果が０になると正しい値となる
緊急ポインタ(URGENT POINTER)
 １６ビット長のフィールドで、
“１”の場合に有効となる
 緊急を要するデータの格納場所を示すポインタとし
て扱われる
 一般には、通信を途中で中断したり、処理を中断
する場合に使われる
オプション(OPTIONS)
TCPによる通信の性能を向上させるために利用される
 データオフセットフィールドによる制限のため、最大で４０
オクテット

オプション(OPTIONS)
オプション(OPTIONS)
タイプ２は、コネクションの確立時に最大セグメント
長の決定で利用される
 タイプ３は、ＴＣＰのスループットを改善するためのオ
プションである
 タイプ８は、高速通信時のシーケンス番号の管理
に利用される
 タイプ４と５は、選択確認応答に利用される


Download Report