コンピュータネットワークトップダウンアプローチ第3章 - トランスポート層（トランスポート層）0.1

3.1概要と輸送層サービス

　　論理的な通信（論理通信）機能を提供するために、異なるホスト上で実行中のアプリケーションプロセス間のトランスポート層プロトコル。

　　3.1.1関係輸送層とネットワーク層

　　ネットワーク層はトランスポート層が動作して、異なるホスト上の論理的な通信プロセスを提供し、ホスト間の論理的な通信を提供します。

　　インターネットトランスポート層の3.1.2概要

　　二つに、インターネット上のTCP（伝送制御プロトコル）とUDP（User Datagram Protocol）を提供

 3.2多重・分離

　　 プロセスは、ゲートウェイネットワークにプロセスからネットワーク及び転送データのデータ転送処理に対応する、一つ以上のソケット（ソケット）を有します。

• 受信側は、ソケットデマルチプレクサ（逆多重化）と呼ばれる（すなわち、異なるプロセス）作業を修正するためにトランスポート層データセグメントに配信されます。
• 異なるソース・ホスト・ソケット・データ・ブロックから収集し、セグメントを生成し、この作業の全てが多重化と呼ばれ、ネットワーク層にセグメントを渡すために、各データブロックのヘッダ情報をカプセル化します（多重化）しています。

　　1.分離に接続されませんマルチプレクサ

　　トランスポート層では、コネクションレスネットワーク伝送をUDPにより達成され、UDPソケットは、宛先IPアドレスと宛先ポート番号を含むタプルが完全に同定することです。

　　、同じ送信元IPアドレス/ポート番号の二つの異なるセグメントがある場合にホストがUDPセグメント検査部の宛先ポート番号、ガイド部を受信し、UDPソケットポート番号を結合し、UDPパケット宛先ポート番号は、2つのセグメントは、同じ目的を介して同じソケット目的プロセスに向けられます。

　　2.コネクション型の多重・分離

　　トランスポートネットワーク層は、多くの場合、接続指向のトランスポートTCPのために使用されるが、UDP及びTCPソケットソケットとの間のわずかな違いがあり、TCPソケットは、4タプル（送信元IPアドレス、送信元ポート番号であります識別するために、宛先IPアドレス、宛先ポート番号）。ネットワークからTCPセグメントがホストに到達すると、ホストは、セグメントの向き、適切なソケットに、すなわちデマルチプレクサにすべての4つの値を使用します。

　　UDPとは異なり、2つの異なるソースまたはソースIPポート番号を有するTCPセグメントは、二つの異なるソケットに到達するようにリダイレクトされています。

 

　　 TCPと3.Webサーバー

 

　　今日の高性能Webサーバーは、一般的に一つだけのプロセスを使用しますが、それぞれの新しい顧客のための新しいソケット接続を使用して新しいスレッドを作成するための接続。

 

3.3コネクションレストランスポート：UDP

　　UDP利点

•  より良好なアプリケーションレイヤの再送制御データが送信されると送信時間。
•  接続を確立する必要はありません。
•  いいえ接続状態ません。
•  小さなパケットヘッダのオーバーヘッド。

　　3.3.1 UDPセグメント構造

　　

　　UDPセグメント構造は、RFC 768、UDPヘッダのみ四つのフィールド、2バイトからなる各フィールドに定義されています。　　

• 送信元ポート番号：クライアントにデータを送信するために、このポート番号を使用することができ、サーバー側に対応するソケット（クライアント）アプリケーションプログラムにこのポート。
• 宛先ポート番号：ポート番号に対応するサーバ上のソケット・アプリケーション・プロセス、HTTPサーバのようなポート80。
• 長さ：、バイト単位で、即ち、ヘッダ+データセグメントのUDPパケットヘッダとデータ部の合計長さを示します。
• およびテスト：変更ビット場合項、すなわち、場合ソースから宛先にUDPセグメントを決定するためのテスト、エラー検出を提供します。

 　　3.3.2 UDPチェックサム

• 送信者
  • 段落の内容は、16ビットの整数とみなし
  • チェックサム計算：とは、吸気のビット値に加算し、それ以降、すべての整数は、チェックサムを取得するために、ビットごとの否定を得
  • チェックサム送信者とチェックサムフィールドに
• 受信者
  • そして、テスト、およびチェックサムフィールドの残りのセグメントが得比較することによって計算されます。
  • 等しくない場合、エラーをチェックしますが、同じ間違いがある可能性があります。

3.4信頼性の高いデータ伝送原理

　　3.4.1構成された信頼性の高いデータ転送プロトコル

　　信頼性の高いチャネルを介し1.完全に信頼性の高いデータ伝送：1.0 RDT

　　有限状態機械（FSM）は状態の有限数と、これらの状態間の遷移および動作等の挙動の数学的モデルを表すことができ、次の図は、その有限状態機械送信者と受信者を意味し、チャネルの底部は、送信者完全に信頼性が高いです各FSMと受信機は、各々が一つの状態FSMを有します。

　　（イラスト：FSMイベントが.FSM水平線の下に表示される初期状態で発生した場合に使用される動き、一つの状態から水平線上に表示されたイベントに起因する他の状態の変化にプロトコル記述変化を示す矢印。点線。）

　　

• チャネルが信頼性があるので、受信側は送信側に任意のフィードバックを提供する必要はありません。
• 想定レートは早く受信者が送信者にデータを送信するデータレートを受信すると、受信機は少し遅く送信するために送信者に依頼する必要はありません。

　　ビットエラーのあるチャネルを介して前記信頼性のあるデータ伝送：rdt2.0

　　RDT 2.0以下に図1で説明した有限状態機械を示している。、エラー検出、肯定応答及び否定応答を使用して、データ伝送プロトコル（自動再送要求プロトコル）。

　　

• 送信で終わる左側の初期状態を、上位層プロトコルから送信側がダウン渡されたデータを待っています。ときにトリガ  rdt_send(data) イベントは：
  • sndpkt = make_pkt(data, checksum) 送信するデータを含むパケットと生成されたチェックサムと
  • そして、パケットによって  udt_send(sndpkt) チャネルに送信されます
• 上記2つのアクションを実行した後、送信側は、ステータスが「ACKまたはNAKパケットの受信端の受信を待機」されている変更します 即ち、内右の形状状態、次に受信側の変化に応じて異なるプログラムに応じて異なるが存在するであろう。
  • ACKパケットを受信した場合（rdt_rcv(rcvpkt) && isACK(rcvpkt)）、送信者は、最新のパケットが正しく受信されている知っているので、プロトコルは、左の状態を返し、ダウン上位層のデータ送信要求によって次の送信時間を待ち続けます
  • あなたは（NAKパケットを受信した場合rdt_rcv(rcvpkt) && isNAK(rcvpkt)）、送信者が受信機で受信したパケットが破損している知っているので、呼び出しは  udt_send(sndpkt) 、パケットを再送するために、同じの状態は、ACKまたはNAKパケットの受信側の受信を待機し続けます。

　　送信側はACKまたはNAK状態を待って、上記プロトコルでは、上位レイヤからより多くのデータを得ることができません。このようなプロトコルは、サブと呼ばれ、停止などのプロトコル（待機および-STOP） 。

• 2.0 RDT終了を受信すると、まだ一つだけの状態です。状態遷移は、パケットが破損して受信されたかどうかに依存して、2つの方法があります。
  • 受信したパケットが損傷している場合、つまり  rdt_rcv(rcvpkt) && corrupt(rcvpkt)、NAKパケットが返されます
  • パケットがそのまま受信された場合、すなわち  rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)、ACKパケットが返されます
• このプロセスはまだ彼らの状態に復帰した後、パケットを受信し、下から処理された次回のために待ち続けます。

　　3.经具有比特差错的丢包信道的可靠数据传输 rdt 3.0

　　在现实的网络环境中，除了比特受损外，底层信道还会丢包；有很多可能的方法可以解决丢包问题，这里我们让发送方负责检测和恢复丢包工作。

　　假定发送端传输一个数据分组，该分组发生丢失 或者 接收端对该分组的 ACK 发生了丢失。在这两种情况下，发送端都收不到应当到来的接收端的响应。所以，如果发送端愿意等待足够长的时间以确定该分组缺失已丢失，则它只需要重传该数据分组即可。

　　从发送端的观点来看，重传是一个万能灵药。为了实现基于时间的重传机制，需要一个倒数计时器 (countdown timer)，在一个给定的时间量过期之后，可中断发送方。发送方需要做到：1）每次发送一个分组（包括第一次分组和重传分组）时，就启动一个定时器；2）相应定时器中断；3）终止定时器。

　　下图是rdt 3.0的发送方FSM，该协议运行在可能发生出错和丢失的信道上。

 

 

　　rdt 2.2 协议中的接收端有限状态机描述图仍然适用于 rdt 3.0 协议，下面我仍然用文字来简要描述一下上图中的发送端发送分组流程：

• 首先由较高层触发 rdt_send(data) 事件，通过 sndpkt = make_pkt(0, data, checksum) 产生一个序号为 0，包含待发送数据且带有校验和的分组，接着通过 udt_send(sndpkt) 将其发送到信道中并启动定时器，然后状态变迁为“等待接收接收端的 ACK 0”
• 当发送端在“等待接收接收端的 ACK 0”的时候：
  • 如果收到了受损的分组（即 corrupt(rcvpkt)）或者收到了 ACK 1（即 isACK(rcvpkt, 1)，也就是收到了自己发送的上一个分组的 ACK），则直接忽略
  • 如果定时器时间到，则由 udt_send(sndpkt) 重新发送该分组并重新启动定时器
  • 如果收到了完好的分组且 ACK 为 0，那么发送端知道接收端已经成功接收了刚才发送的序号为 0 的分组，直接停止定时器，此时发送端状态变迁到等待较高层传下来的数据发送请求
• 注意在继续等待从较高层传下来的数据发送请求的过程中，如果收到了任何分组数据包，都直接忽略，因为它们一定是冗余的

　　3.4.2 流水线可靠数据传输协议

　　停等协议可能会限制底层网络硬件所提供的能力

　　解决方法是：不使用停止等待方式，运行发送方发送多个分组而无需等待确认。由于许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中，因此这种技术被称为流水线 (pipelining)。当然，流水线会增加协议的复杂度：

• 　必须增加序号范围

　　因为信道中的分组要有一个唯一的序号，会有多个分组在信道中未被确认。

• 协议的发送方和接收方必须缓存多个分组

　　发送方至少应该缓存已经发送却还没有被确认的分组。接受方也许应该缓存已经正确接收的分组。

• 所需的序号范围和对缓存大小的要求取决于协议如何处理丢失、损坏及延时大的分组

　　解决流水线差错错误的两种基本思路：回退N步和选择重传。

　　3.4.3 回退N步

  　　GBN 协议被称为滑动窗口协议 (silding-window protocol)

　　3.4.4 选择重传

 　　选择重传协议让发送方仅重传那些它怀疑在接收方出错的分组，避免了不需要的重传。

 

参考:

https://www.cnblogs.com/hithongming/p/9379397.html

https://www.cnblogs.com/oxspirt/p/6496434.html

https://www.cnblogs.com/huahuahu/p/liu-shui-xian-ke-kao-shu-ju-chuan-shu-xie-yi.html