Transcript 第6章 TCPとUDP
Chapter 6 TCP と UDP 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6章 トランスポート層の役割 ポート番号 UDP TCP リアルタイム通信とRTP UDPヘッダフォーマット TCPヘッダフォーマット 編集 4403097 4403046 4403022 4403056 4403058 4403058 4403056 4403005 安松 良太 佐藤要太郎 鎌田 和真 背山 有梨 高田 真希 高田 真希 背山 有梨 石原 真樹 1 6.1 トランスポート層の役割 4403097 安松良太 2 トランスポート層とは… • OSI参照モデルの第4層に位置し、データ転送 の信頼性を確保するための方式を定めたもの • ネットワーク層を通して送られてきたデータの 整序や誤り訂正、および再送要求などをおこ なう。 • 送られてきたデータを要求したアプリケーショ ンに渡す。 3 通信の処理 • 多くのアプリケーションプロトコルは、一般に クライアント/サーバーモデルという形式で作 られる。 – データの送受信には、必ず要求する側（クライア ント）と対応する側（サーバー）とに分かれる。 – サーバー側は常に起動してクライアントからの要 求を待っていなければならない。 4 TCPとUDP • TCP（Transmission Control Protocol） – コネクション型 – 信頼性があるストリーム型プロトコル – 順序制御・再送制御・フロー制御・ふくそう回避制 御etc • UDP(User Datagram Protocol) – コネクションレス型 – 信頼性がないデータグラム型プロトコル – 対応はアプリケーションが行う 5 ソケット • TCPやUDPを利用する時に使われるAPI （Application Programming interface）の名 称。 • アプリケーションはソケットを利用して、通信 相手のIPアドレスやポート番号を設定したり、 データの送受信の要求をする。 6 TCPとUDPの使い分け • トランスポート層で信頼性のある通信を実現 する必要がある場合にはTCP • 同報通信、高速性やリアルタイム性重視の通 信にはUDP 7 6.2 ポート番号 4403046 佐藤 要太郎 8 6.2.1 ポート番号とは • トランスポートプロトコルにおけるアドレス • 同一コンピュータ内で通信を行っている複数のプロ グラムを識別する 9 6.2.2 ポート番号によるアプリケー ションの識別 • トランスポートプロトコルは、ポート番号を使って、通 信しているプログラムを識別する ホストA １７２．２３．１２．１４ TELNE T サーバー ポート番号 TCP２１ FTP SMTP HTTP FTP HTTP サーバー サーバー サーバー サーバー サーバー ポート番号 TCP２３ ポート番号 TCP２５ ポート番号 TCP８０ ポート番号 TCP２０００ ポート番号 TCP２００１ どの処理にデータを渡すのかな？ データ ＆ IP 宛先１７２．２３．１２．１４ 10 6.2.3 ＩＰアドレスとポート番号と プロトコル番号による通信の識別 • 宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポー ト番号、送信元ポート番号、プロトコル番号の ５つの数字を組み合わせて通信を識別 11 12 6.2.4 ポート番号の決め方 • 標準で決められている番号（ウェルノウン ポート番号) • ダイナミック(動的)割り当て方法 13 6.2.5 ポート番号とプロトコル • ポート番号は使用されるトランスポートプロト コルごとに決定 ex)TCPとUDPで同じポート番号を使用可能 • データがIP層に到着すると、IPヘッダ中のプ ロトコル番号がチェックされそれぞれのプロト コルのルーチンに渡される • ウェルノウンポート番号はプロトコルに関係な く同じ番号は同じアプリケーションに割り当て られる 14 6,3 UDP （User Datagram Protocol） 4403022 鎌田和真 15 6.3.1 ＵＤＰの目的と特徴 • ネットワークが混雑していたとしても、送信量 を制御しない。 • パケットが失われても、再送制御はしない。 • これらの制御が必要なら、ＵＤＰを利用するア プリケーションプログラムが制御しなければな らない。 16 ＵＤＰの用途 • 総パケット数が少ない通信 • 動画や音声などのマルチメディア通信 • ＬＡＮなどの特定のネットワークに限定したア プリケーションの通信 • 同報性が必要な通信（ブロードキャスト、マル チキャスト） 17 6.4 TCP (6.4.1 - 6.4.5) 4403022 Kazuma Kamata 18 TCP (Transmission Control Protocol) • 「伝送、送信、通信」を「制御」する「プロトコ ル」 データを送信するときの制御機能が充実し ている。 ・ネットワークの途中でパケットが喪失した場 合の再送、 ・順序が入れ替わった場合の制御、 ・パケットの到達を確認する確認応答 などをＴＣＰの中で行っている。 19 6.4.1 ＴＣＰの目的と特徴 • ＩＰデータグラムを利用して信頼性のある通信 を実現するために、データの破損やパケット の喪失、重複、順序の入れ替わりなどの問題 を考えなければならない。これらを解決できな ければ、信頼性を提供することはできない。Ｔ ＣＰでは、チェックサムやシーケンス番号と確 認応答、再送制御、コネクション管理、ウイン ドウ制御などにより信頼性のある通信を実現 する。 20 6.4.2 シーケンス番号と確認応答 で信頼性を提供 • ＴＣＰは肯定確認応答(ACK)でデータ転送の信頼性を 実現 データを送信したホストは、データの送信後に確認応 答を待つ。 ・確認応答あり →データは相手のホストに到着 ・確認応答なし →データ喪失の可能性 →一定時間応答なしならデータを失ったと判断し てもう一度データを送信する 21 確認応答がない場合 • データ喪失時 • 確認応答パケットが喪失した場合 データは届いているが、データを再送する • 何らかの理由で確認応答が遅れ、再送後に確認応 答パケットが到着する場合 →上位層のアプリケーションに、データ通信の信頼 性を提供するため、重複受信したパケットを破棄しな ければならない。このため、受信済みパケットを識別 し、必要かを判断することが必要 22 シーケンス番号を使用 確認応答処理や再送制御、重複制御などには、す べてシーケンス番号を使用 ・送信するデータをオクテット単位でカウントして送 信時にヘッダに番号をつけて送信する。 ・シーケンス番号の初期値は０からでなく、コネク ションの確立時に乱数で初期値を決める。 それ以降は、送信データをオクテット単位で数えて、 シーケンス番号にその値を加算していく。そして、受 信側では、受信したデータのシーケンス番号を調べ、 次に自分が受信すべき番号を確認応答として返送 する。 23 6.4.3 再送タイムアウトの決定 • 再送タイムアウト時間を経過しても確認応答が到着 しなかった場合データを再送する。 どのくらいの時間が適切か？ →パケットを送信するたびに ラウンドトリップ時間と、 その揺らぎの時間を計測する。 合計時間よりも少し大きな値を再送タイムアウト時 間とする。 24 6.4.4 コネクション管理 • ＴＣＰは通信前にコネクション確立要求のパ ケットを送信して確認応答を待つ。 相手から確認応答が送られてきた場合 通信が可能 確認応答が送られてこない場合 通信を開始することはできない 通信を終了したとき、コネクションの切断処理 25 6.4.5 ＴＣＰはセグメント単位で データを送信 • コネクションの確立時に、通信を行うデータ単 位を決定 最大セグメント長と呼ぶ (Maximum Segment Size) 大量のデータを送信するときには、このＭＳＳ の値ごとにデータが区切られて送信される。 再送処理も基本的にはＭＳＳ単位で行われる 26 6.4 TCP (Transmission Control Protocol) (6.4.6 - 6.4.11) 4403076 浜田 ちひろ 6.4.6 ウィンドウ制御で速度向上 6.4.7 ウィンドウ制御と再送制御 6.4.8 フロー制御 6.4.9 ふくそう制御 6.4.10 ネットワークの利用効率を高める仕組み 6.4.11 TCPを利用するアプリケーション 27 6.4.6 ウィンドウ制御で速度向上 時 間 データ １～１０００ パケットの往復時間が 長くなると通信性能が 悪くなる！ 確認応答 次は１００１ １００１～２０００ 次は２００１ ２００１～３０００ 次は３００１ ３００１～４０００ 次は４００１ ４００１～５０００ TCPの１セグメントごとに確認応答を行った場合28 ウインドウの概念 時 間 送信したセグメントに対す る確認応答を待たずに、複 数のセグメントを送信する ことで通信性能を改善 ウィンドウ サイズ データ １～１０００ １００１～２０００ ２００１～３０００ ３００１～４０００ ４００１～５０００ ５００１～６０００ ６００１～７０００ ７００１～８０００ 確認応答 次は１００１ 次は２００１ 次は３００１ 次は４００１ 次は５００１ 次は６００１ 次は７００１ 次は８００１ ８００１～９０００ スライディングウィンドウ方式で並列処理を行った場合 29 ホストA（送信ホスト） ０ １０００ ２０００ ３０００ ４０００ ５０００ ６０００ ７０００ ウィンドウ（４セグメント） ホストA ホストB シーケンス番号２００１のデータを 要求する確認応答が、 ホストAに到達 ホストA（送信ホスト） ０ １０００ ２０００ ３０００ ４０００ ５０００ ６０００ ７０００ ウィンドウ（４セグメント） ２０００までのデータを 破棄して右へ移動する •スライディングウィンドウ方式の図 30 6.4.7 ウィンドウ制御と再送制御 ウィンドウ制御を行わない 場合、確認応答が失われ るとデータは届いているに もかかわらず再送しなけ ればならない →ウィンドウ制御を行うと ある程度の確認応答が 失われても再送する必要 がなくなる 時 間 データ １～１０００ 確認応答 １００１～２０００ 次は１００１ ２００１～３０００ 次は２００１ ３００１～４０００ 次は３００１ ４００１～５０００ 次は４００１ ５００１～６０００ 次は５００１ 次は６００１ 31 高速再送制御 時 間 送信セグメントが失われた場合: 受信ホストが今までに受信した データの確認応答を返す ３つの重複応 答を受け取る と再送する データ １～１０００ １００１～２０００ ２００１～３０００ ３００１～４０００ ４００１～５０００ 確認応答 次は１００１ 次は１００１ 次は１００１ 次は１００１ 次は１００１ 次は１００１ 次は７００１ ５００１～６０００ ６００１～７０００ １００１～２０００ ７００１～８０００ ８００１～９０００ ９００１～１００００ ３つの重複 確認応答 次は８００１ 次は９００１ 高速再送制御の図 32 6.4.8 フロー制御（流動制御） ＊受信ホストが送信ホ ストに対して受信可能 なデータサイズを通知 する ＊受信側のバッファが 溢れそうになると値を小 さくして送信ホストの送 信量を抑制する 時 間 データ １～１０００ 確認応答 １００１～２０００ ２００１～３０００ ３００１～４０００ 次は１００１ ３０００ 次は２００１ 次は３００１ 次は４００１ ２０００ １０００ ０ ウィンドウ ロープを定期 的に送信する バッファが満 杯の状態 ４００１～５０００ ５００１～６０００ ウィンドウ更新通知が途切れ、通信不能 になるのを避けるためウィンドロープと 呼ばれる小さなデータを送信する。 ウィンドウ 次は４００１ ０ 次は４００１ ３０００ ウィンドウ更新通知 フロー制御の図 33 6.4.9 ふくそう制御(ネットワークの混雑解消) ＊ネットワークに、通 信開始時から大量の パケットを送信すると ネットワークがパンク する可能性がある ＊その危険性をな くすため、スロース タートと呼ばれるア ルゴリズムに従い 送信する ふくそう ウィンドウ １０００ データ １～１０００ ２０００ ２０００ １００１～２０００ ３０００ ４０００ ４０００ ４０００ ３００１～４０００ ４００１～５０００ ５００１～６０００ ６００１～７０００ 確認応答 次は１００１ ２００１～３０００ 次は２００１ 次は３００１ 次は４００１ 次は５００１ 次は６００１ 次は７００１ スロースタートの図 34 TCPのウィンドウの変化 ふくそうウィンドウ の大きさ タイムアウト パケットが往復するたび に、ふくそうウィンドウが 1・2・4と指数関数的に 急激に大きくなってしま うのを防ぐために、ス ロースタート閾値を用意 する タイムアウト 重複確認応答 半分 ふくそう ウィンドウ 半分 3セグメント 時間 スロースタート閾値 1セグメント 指数関数的 にウィンドウ が増加 ふくそうウィンドウ １セグメント 35 Nagleアルゴリズム • • 送信側に送信するべきデータがあったとし てもデータが少ない場合には送信を遅らす もの 下記の2点に当てはまるときのみTCPは データを送信する ・すべての送信済みデータが確認応答されている場合 ・最大セグメント長のデータを送信できる場合 36 遅延確認応答 ＊データを受信してもすぐには確認応答を 行わない方法 ＊具体的な遅延方法は下記の2点。 ・２×最大セグメント長のデータを受信するまで確認 応答をしない（OSによっては，データサイズによらず に2パケット受信すると確認応答をするものがある） ・そうでない場合は，確認応答を最大で0.5秒間遅 延させる（多くのOSでは，0.2秒程度） 37 ピギーバック ＊アプリケーションプロトコルによっては送信した データに対して相手が処理をして返事を出すこと がある Ex）電子メールのSMTP、POP FTPの制御コネクション ＊ピギーバックにより送受信するパケットの数を減ら すことができ、ネットワークの利用効率をあげるこ とができる 38 6.4.11 TCPを利用するアプリケーション ・ TCPの複雑な制御は時と場合により使い 分けることが必要 ・ アプリケーションが細かい制御をしたほう がよい場合は、UDPを用いたほうがよい ・ データの転送量が比較的に多く，信頼性が 必要としているが、難しいことを考えたくない 場合にはTCPを用いるのがよい 39 リアルタイム通信とRTP 学籍番号 4403058 名前 高田真希 40 リアルタイム通信とRTP • • • • リアルタイム通信とは UDPの問題点 音質や動画の再生 RTPとRTCP 41 リアルタイム通信とは • 送信したデータが出来るだけ速やかに 宛先のホストに届けられる通信 • TCPによる通信はセグメント単位の通信やフロー制御、 ふくそう制御のため送信したパケットが送信元や宛先の ホストでバッファリングされ速やかに宛先ホストまで 届けられない ∥ UDPを利用 42 UDPの問題点 • UDPは信頼性のないプロトコル – パケットの喪失 – 順番の入れ替わる可能性 パケットの順番を示すシーケンス番号を つけたりパケット送信時刻を書き込む必要 – パケット到着間隔の揺らぎ ∥ ジッター 他のパケットの影響で到着間隔が大きく変化する 43 音声や動画の再生 • パケットの到着時刻が変動しても同じ速度で 再生 ↓ バッファを用意して速度の吸収 大きいバッファ→ジッターの変動に対処可能 遅延時間大 小さいバッファ→遅延時間小 音質画像の乱れ 44 RTPとRTCP • RTP – リアルタイム通信で使用されるデータを 送信するためのヘッダ構造を決める – パケットにタイムスタンプとシーケンス番号 – RTCPとともに利用 • RTCP – RTPによる通信の補助 – パケット喪失率など通信回線の品質を 管理データ転送レートの制御に利用 45 タイムスタンプ • 音声や動画のデータを記録した時刻 • タイムスタンプの時刻を元に再生する タイミングを調整 46 シーケンス番号 • パケット1つ送信する毎に1つ増 • タイムスタンプが同じデータの順番を 並べ直す • パケットの抜けを知るのに利用 47 UDPヘッダフォーマット 学籍番号 4403058 名前 高田真希 48 UDPヘッダフォーマット • • • • • • • • • • UDPフォーマット 送信元ポート番号 宛先ポート番号 パケット長 チェックサム チェックサムの計算方法 UDP擬似ヘッダ チェックサムの再計算 チェックサムの利用を推奨 UDP擬似ヘッダの必要性 49 UDPのフォーマット 0 15 16 31 （ビット） 送信元ポート番号 宛先ポート番号 パケット長 チェックサム UDP ヘッダ データ 50 送信元ポート番号 • Source Port • 16ビット長のフィールド • 指定しないことも可 – 返事を必要としない通信で利用 51 宛先ポート番号 • Destination Port • 16ビット長のフィールド 52 パケット長 • Length • UDPヘッダの長さと データの長さの和が格納 • 単位はオクテット長 53 チェックサム • Checksum • UDPのヘッダとデータの信頼性を提供 • データを送受信するときの誤り検出法 – チェックサムを計算 – データとともに送信 – 受信側チェックサムを再計算 – 送信側との一致を検査 54 チェックサムの計算方法 • UDP擬似ヘッダをUDPデータグラムの 前につける • 全長が１６ビットの倍数になるように ０を追加 • チェックサムフィールドを０にする • １６ビット単位で１の補数の和を求める • 和の１の補数をチェックサムフィールドに入れ る 55 UDP擬似ヘッダ 0 15 16 31 （ビット） 送信元IPアドレス 宛先IPアドレス パディング（詰め物） プロトコル番号 ０ １７ UDPパケット長 56 チェックサムの再計算 • • • • UDPデータグラムを受信 IPヘッダからIPアドレスの情報を取得 擬似ヘッダを作成 チェックサムを再計算 チェックサムを含むすべてのデータを足した結果が 0になると正しい 57 チェックサムの利用を推奨 • 使用しないと・・・ – データの転送速度の向上 – UDPヘッダのポート番号の値が壊れると、他の通 信に悪影響を及ぼす 58 擬似ヘッダの必要性 • UDPのヘッダでは送信元ポート番号と宛先 ポート番号しか含まない • 残りの３つはIPヘッダに含まれる • 他の３つの情報が破壊された場合、 間違ったアプリケーションにデータを 渡す可能性が生じる 59 6.7 TCPヘッダフォーマット 学籍番号 氏名 ４４０３０５６ 背山有梨 60 • 送信元ポート番号 ・・・１６ビット長のフィールドで、送信元 のポート番号を示す • 宛先ポート番号 ・・・１６ビット長のフィールドで、宛先の ポート番号をしめす 61 シーケンス番号 • ３２ビット長のフィールドで、シーケンス番 号を示す • シーケンス番号は送信したデータの位置 を示す • データを送信するたびに、送信したデータ のオクテット数だけ値が加算される • コネクションを確立する時に初期値が乱 数値で決定され、SYNパケットで受信ホ ストに伝えられる 62 確認応答番号 • ３２ビット長のフィールドで、確認応答番号を 示す • 確認応答番号は次に受信すべきデータの シーケンス番号になっている • 送信側では、次に送るデータのシーケンス番 号と、返された確認応答番号が同じ場合には、 正常に通信が行われたことになる 63 データオフセット・予約 • データオフセット ・・・４ビット長のフィールドで単位は４バ イト長 • 予約 ・・・●将来の拡張のために容易されて いるフィールドで６ビット長 ●“０”にしておく必要がある 64 コントロールフラグ ６ビット長のフィールドで、各ビットは左からURG、ACK、PSH、 RST、 SYN、FINと名づけられている。それぞれの意味を以下に示す。 • URG・・・このビットが“１”の場合は緊急に処理すべきデータが含 ま れていることを示す • ACK・・・このビットが“１”の場合は、確認応答番号のフィールドが 有効であることを意味する • PSH・・・受信したデータについての判断ができる • RST・・・ • SYN・・・コネクションの確立に使われる • FIN・・・ 65 ウィンドウサイズ • １６ビット長のフィールドで受信可能なデータ のサイズを表す情報が入る ・・・データのサイズはオクテット • ここに示されているデータ量を超えて送信す ることは許されない • データの受信側のコンピュータがセットする 66 チェックサム • 途中のルーターのメモリの故障や往路グラム のハグなどによるデータの破壊がないことを 保障するためのもの 67 緊急ポインタ • １６ビット長のフィールド • 緊急を要するデータの格納場所を示すポイン タとして扱われる • データ領域の先頭からこの緊急ポインタで示 されているデータ（オクテット長）が緊急データ になる • 一般には、通信を途中で中断したり、処理を 中断する場合に使われる 68 オプション • TCPによる通信の性能を向上させるために 利用される • データオフセットフィールドによる制限のため、 最大で４０オクテットまで 69