1 / 56

トランスポート層

トランスポート層. UDP TCP ポート番号. 2004 年 1 月 8 日 情報ネットワーク論 新村太郎. TCP/IP からみたインターネット層. データの送信元から送信先へ正しくデータを届ける －　識別、経路制御、通知　－. TCP/IP からみたトランスポート層. 所定のアプリケーションにデータを渡す・・・ポート TCP は確実にデータを届ける・・・コネクション. TCP と UDP. Transmission Control Protocol User Datagram Protocol. フラグメント & カプセル化.

kameko-stone
Télécharger la présentation

トランスポート層

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. トランスポート層 • UDP • TCP • ポート番号 2004年1月8日 情報ネットワーク論 新村太郎

  2. TCP/IPからみたインターネット層 データの送信元から送信先へ正しくデータを届ける －　識別、経路制御、通知　－

  3. TCP/IPからみたトランスポート層 所定のアプリケーションにデータを渡す・・・ポート TCPは確実にデータを届ける・・・コネクション

  4. TCPと UDP Transmission Control Protocol User Datagram Protocol

  5. フラグメント & カプセル化 フラグメント ・・・ アプリケーションデータを MSS (Maximum Segment Size) の大きさでばらばらにする アプリケーションデータ アプリケーション データ1 アプリケーション データ2 アプリケーション データ3 アプリケーション データ4 アプリケーション データ5 TCPセグメント トランスポート層　・・・・・ TCPヘッダ アプリケーション データ IPパケット (IPデータグラム) インターネット層　・・・・・ IPヘッダ TCPヘッダ アプリケーション データ

  6. フラグメント & カプセル化 カプセル化　・・・　上位層のデータにヘッダを付けて１つのデータにして、下位層に受け渡す アプリケーションデータ アプリケーション データ1 アプリケーション データ2 アプリケーション データ3 アプリケーション データ4 アプリケーション データ5 TCPセグメント トランスポート層　・・・・・ TCPヘッダ アプリケーション データ IPパケット (IPデータグラム) インターネット層　・・・・・ IPヘッダ TCPヘッダ アプリケーション データ

  7. TCP と UDP 共通の機能 • ポート番号の管理 • 上位層（アプリケーション層）と下位層（インターネット層）とのデータの受け渡し 違い • TCP • コネクションを確立した通信管理（コネクション指向） • 確実なデータ確認（確認の返事、再送請求） • UDP • コネクションレス • TCPのようなデータ確認なし

  8. TCPヘッダ アプリケーション データ UDP ヘッダ アプリケーション データ TCP と UDP セグメント化されたアプリケーションデータに TCPヘッダが付いたもの TCPセグメント UDPヘッダが付いたもの UDPセグメント

  9. TCPヘッダ TCPヘッダ アプリケーションデータ 32ビットごと 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  10. UDPヘッダ UDP ヘッダ アプリケーションデータ 32ビットごと 0 8 16 24 31 送信元ポート番号 あて先ポート番号 長さ チェックサム

  11. TCP と UDP • TCP • ヘッダがデータに比べて大きい • データ確認の処理のために正確であるが送受信が遅くなる場合がある 　→　速度より確実性を重んじるデータ転送 • UDP • ヘッダの大きさの比率がTCPに比べて小さい • TCPのような確認処理がないために送受信が高速 　→　正確さより速度・・・リアルタイム性が必要 　　　なデータ転送（マルチメディア）

  12. ポート番号 0 8 16 24 31 送信元ポート番号 あて先ポート番号 長さ チェックサム 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  13. アプリケーションとプロトコル アプリケーションの機能によって対応するプロトコルがある 例） 　メール送信 SMTP (Simple Mail Transfer Protocol) 　メール受信 POP (Post Office Protocol) 　ホームページデータやりとり HTTP (Hyper Text Transfer Protocol) 　ファイル転送 FTP (File Transfer Protocol) 　遠隔操作 TELNET, SSH

  14. アプリケーションとプロトコル 異なるアプリケーションでも、機能が同じであれば同じプロトコルを使用する 例） Internet Explore, Netscape Navigator → HTTP Outlook Express, Al-Mail, Eudora → SMTP & POP

  15. アプリケーション、プロトコルとポート番号 • コンピュータはネットワーク上で様々なアプリケーション、プロトコルを使用して通信を行う • 相手にパケットが届いた後、所定のアプリケーションにデータを受け渡す必要がある 送信元 送信先 ホームページのリクエスト メールのデータ ?! ホームページのリクエスト ホームページのリクエスト

  16. アプリケーション、プロトコルとポート番号 アプリケーションごと（プロトコルごと）に所定の番号（ポート番号）を付けて相手にどのアプリケーション（プロトコル）のデータかを明示する 送信元 送信先 宛て先ポート番号は80番 ホームページのリクエストのデータだから 80番にあてる 80番あてだから、 ホームページのリクエストだ！

  17. アプリケーション、プロトコルとポート番号 • ポート番号はUDPやTCPのヘッダに格納される • 送信先のポートだけでなく、送信元にも受け取りのためにポート番号が決められる 送信元 送信先 ポート番号 1280番 から 80番へ 送信元ポート番号 1280番 送信元ポート番号 80番 ポート番号 80番 から 1280番へ

  18. ポート番号の区分け(IANAが管理 http://www.iana.org/) 0 ～ 1023 Well Known Port Numbers • プロトコルごとに番号がすでに決まっている • サーバ機能で使われる 1024 ～ 65535Ephemeral Port Numbers • データ通信の際に適宜自由に使用できる • クライアントで送信元ポート番号として使われる • 1024 ～ 49151Registered Port Numbers IANAにプロトコルと番号を登録することができる • 49152 ～ 65535Dynamic/Private Port Numbers ユーザが全く自由に使用できる

  19. 代表的な Well Known Port

  20. アプリケーション層からトランスポート層へ リクエスト側・・・クライアント データ提供側・・・サーバ URLの入力 ホームページデータのリクエスト ポート番号1280番から80番へ

  21. アプリケーション層からトランスポート層へ リクエスト側・・・クライアント データ提供側・・・サーバ ポート番号1280番から80番へ ホームページデータのリクエスト

  22. アプリケーション層からトランスポート層へ リクエスト側・・・クライアント データ提供側・・・サーバ リクエストに対する処理 80番あてだから HTTP !! ホームページデータのリクエスト

  23. アプリケーション層からトランスポート層へ リクエスト側・・・クライアント データ提供側・・・サーバ リクエストされたデータ発信 ポート番号80番から1280番へ ホームページデータの送信（リクエストへの返答）

  24. アプリケーション層からトランスポート層へ リクエスト側・・・クライアント データ提供側・・・サーバ 1280番は HTTP で使っていたからHTTP で利用しよう !! ホームページデータの送信（リクエストへの返答）

  25. アプリケーション層からトランスポート層へ リクエスト側・・・クライアント データ提供側・・・サーバ 所定のアプリケーションでデータ処理 ↓ ホームページが表示される ホームページデータの送信（リクエストへの返答）

  26. TCP • コネクション • シーケンス番号 • ウィンドウコントロール • フローコントロール 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  27. シーケンス番号 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 • TCPセグメントの送った順番　・・・　受け取った際に、順番の確認に利用 • セグメントサイズごと（単位はオクテット）に増やす　・・・　一連のデータであることの確認 • 相手が受け取り確認に利用　・・・　領収書の品名 ? 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  28. 確認応答番号 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 • シーケンス番号と連動して、相手に、次に送ってもらいたいデータの位置を示す • 確認応答番号が送られてきたということは、その直前のデータは受け取られたということを意味する • ACK信号（データ受取確認信号）で利用 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  29. 制御ビット 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 • コネクション開始、終了要求、受取確認などの特殊な目的の信号（TCPセグメント）を送る際に使用 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  30. 制御ビット URG ACK PSH RST SYN FIN • ６種類の制御ビットからなる • それぞれ１ビットずつ割り当て • 該当の場合は１、それ以外では０が入る URG:緊急処理 ACK:確認応答 PSH:転送強制 RST: 強制切断 SYN: コネクション確立要求 FIN: コネクション終了要求

  31. ウィンドウ 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 • 一度にまとめて送って良い最大のデータ量“ウィンドウサイズ”を入れる（単位はオクテット） 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  32. チェックサム 0 8 16 24 31 送信元ポート番号 あて先ポート番号 シーケンス番号 確認応答番号 • データが正しく送られているかどうかをチェックするための演算の結果が入る • チェックサムで合わない場合は、データは壊れているものとして破棄される • TCPもUDPもチェックサムの扱いは同様 予約 データ オフセット 制御ビット ウィンドウ チェックサム 緊急ポインタ オプション パディング

  33. コネクション 　数多くのコンピュータが存在するネットワークの中で、相手をきちんと確認してから、その相手であることを確認しつつデータの送受信をする。 A E 物理的な通信路 B D C

  34. コネクション 信号には互いにシーケンス番号という数字を付けて、続きであることを明示する Cさん通信しましょう 1. 相手の確認 A E SYN信号 B D C

  35. コネクション 2. 相手の確認と返事 A E B SYN信号 ＋ ACK信号 はいいいですよ。 Aさん通信しましょう。 D C

  36. コネクション はい、いいですよ。 3. 返事 A E ACK信号 B D C

  37. コネクション 4. コネクション確立、データ転送（詳細は後述） A E データのやりとり コネクション (仮想的、確実な通信路) B D C

  38. コネクション 5. コネクション終了の合図（どちらからでも可能） A E FIN信号 B D Aさん、これで終わりましょう。 C

  39. コネクション 承知しました。 6. コネクション終了の返事 A E ACK信号 B D C

  40. コネクション 承知しました。 Cさんこれで終わりましょう。 7. コネクション終了の合図と返事 FIN信号 ＋ ACK信号 A E B D C

  41. コネクション 承知しました。 8. コネクション終了の返事 A E ACK信号 B D C

  42. コネクション 9. コネクション終了 A E B D C

  43. 時系列で見たコネクションとデータ転送 A C 1. コネクションの開始 SYN(100) 時間の流れ ( ) の中の数字はシーケンス番号 SYN(1000), ACK(101) ACK(1001) コネクション確立 データ転送開始

  44. 時系列で見たコネクションとデータ転送 A C 2. コネクション確立後のデータ転送 データ(101) 時間の流れ いくつかまとめてばらばらになったデータを送る（ウィンドウ制御） データ(201) データ(301) ACK(201) 個々のデータごとに受け取った返事(ACK信号)を送る ACK(301) ACK(401)

  45. シーケンス番号 (1) A C 　　データのシーケンス番号はコネクションの確立でランダムに決められ、その後は、データの転送量(単位はオクテット）を加えた数字となる（ここでは100オクテットごと） データ(101) データ受け取り通知としてのACKでは、データのシーケンス番号に受け取ったデータ量（ここでは100オクテット）を加え、さらに１を加えた（つまりその次の数字）をシーケンス番号として使用する 受け取り確認であるとともに、次のデータの要求でもある ACK(201)

  46. 時系列で見たコネクションとデータ転送 A C 3. データの再送 (1) データ(401) 時間の流れ 送ったはずだが、なかなか着かない・・・ もしくは途中で消えた ! データ(401) 一定時間後にも返事(ACK)がなければ再度送信する ACK(401)

  47. 時系列で見たコネクションとデータ転送 A C 3. データの再送 (2) データ(401) 時間の流れ データが届いたが壊れている →　破棄、返事しない データ(401) 一定時間後にも返事(ACK)がなければ再度送信する ACK(401)

  48. シーケンス番号 (2) A C データ(101) 　　一部のデータが届かなくて再送信された場合などでは、送った順番と届いた順番が違ってくる。 　シーケンス番号を見ることによって、正しい順番に直して、アプリケーションに渡す。 ① ① データ(201) ② データ(301) ③ ③ データ(401) ④ ① ③ ④ ② ④ (101) (301) (401) (201) データ(301) ② ② ① ② ③ ④ (101) (201) (301) (401)

  49. フローコントロール A 　ウィンドウ制御で許される一度に送信する量（ウィンドウサイズ）で最初から送信しないで、徐々に増やしていき、処理が滞ったら減らす。 　これをフローコントロールという。データ送信が相手の処理に合うようにするための工夫。 時間の流れ

  50. 時系列で見たコネクションとデータ転送 A C 4. コネクションの終了 FIN(800) 時間の流れ ACK(801) FIN(1500), ACK(801) ACK(1501) コネクション終了

More Related