この記事では、信頼性の高いデータ伝送プロトコルRDTの3つのバージョンと有限状態マシンの説明の主な関係を説明します。

自己学習型コンピュータネットワークシリーズ。エラーが発生した場合は、修正してください。

前に書く:これはXiao Wangの成長ログです。普通の大学生が学習後に彼の研究ノートを共有し、彼の成長軌道を記録し、それを必要とするかもしれない人々を助けたいと思っています。通常、ブログのコンテンツは主にいくつかのシステムです研究ノート、実用的なプロジェクトノート、いくつかの技術的探求、および私自身の考えのいくつか。誰でも注意を払って大歓迎です、私はあなたが好きで、フォローするすべてのコメントを注意深く読んでいきます。ご不明な点がございましたら、お気軽にお問い合わせください。


0.紹介する

  • 信頼性の高いデータ伝送の問題は、トランスポート層だけでなく、リンク層やアプリケーション層にも現れます。ネットワークには多くの「一般的な問題」が発生しますが、信頼性の高いデータ伝送は特に重要です。
  • 信頼性の高いデータ送信によって提供されるサービス:データは信頼性の高いチャネルを介して送信できます信頼性の高いチャネルによって、データ・ビットの伝送は、(0から1へ、またはその逆)が破損することができない、または損失、および、すべてのデータがあるラインへのそれらの送信順序配信に従って
  • 議論全体の次の仮説は、パケットは送信された順に配信され、一部のパケットが失われる可能性があるということです。これは、基礎となるチャネルがパケットを並べ替えないことを意味します。
  • 定義は明確です。
    有限状態オートマトンとしても知られる有限状態機械(有限状態機械、FSM)は、状態機械と呼ばれ、有限数の状態と、これらの状態間の遷移およびアクションの動作を表す数学モデルです。次に、信頼できるデータ伝送を実現するための送信側と受信側の有限状態マシンについて引き続き説明します。

1.完全に信頼できるチャネルを介した信頼できるデータ伝送:rdt 1.0

1.1)rdt1.0の仮定と2つの有限状態機械の凡例

最初に、基礎となるチャネルが完全に信頼できると仮定します。この場合のプロトコルは非常に単純で、すぐ上にあります

ここに画像の説明を挿入

  • 上の図は、rdt 1. 0の送信側と受信側の有限状態マシン(FSM)の定義を示しています。
  • rdt送信者は、rdt_send(data)イベントを介して上位層からのデータのみを受け入れ、(make_pkt(data)アクションを介して)データを含むパケットを生成し、そのパケットをチャネルに送信します
  • 受信端、RDTはrdt_rcv(パケット)イベントによって、基礎となるチャネルからのパケットを受信し(抽出物(パケットデータ)演算を介して)パケットからデータを除去し、上位層にデータをアップロード((データ)deliver_dataによって操作しました)。

1.2)まとめ

この単純なプロトコルでは、データの単位はパケットと同じです。さらに、すべてのパケットは送信側から受信側に流れます。完全に信頼できるチャネルを使用すると、エラーを心配する必要がないため、受信側は送信側フィードバックを提供する必要がありません!受信側もデータを受信すると想定しています。レートは、送信者がデータを送信するレートと同じくらい速くすることができます。したがって、受信者は送信者に減速を要求する必要はありません!

2.ビットエラーチャネルを介した信頼性の高いデータ伝送:rdt 2.0

2.1)rdt2.0の前提

rdt 2.0では、パケット内のビットが破損している可能性があると想定しています(これは正常であり、通常はネットワークの物理部分に表示されます)。送信されたすべてのパケット(破損している可能性があります)が引き続き順序どおりに受信されると想定しています。

したがって、破損したパケットについては、再送信する必要があります。これは、コンピュータネットワーク環境で非常に重要なプロトコルです。自動再送要求(ARQ)プロトコル(再送信メカニズムに基づく信頼性の高いデータ送信プロトコル)

ARQと協力してビットエラーに対処するには、他に3つのプロトコル関数が必要です。

    1. エラー検出
      -レシーバーがパケットのビットエラーを検出し、場合によっては訂正できるようにします。
      -一般的なエラー検出および修正技術には、UDPチェックサムがあります。チェックサムセクション他のブログの最後にあり計算方法とその理由を紹介しています。
    1. 受信機フィードバック
      • 私たちのrdt 2.0プロトコルは、ACKパケットとNAKパケットをレシーバーからセンダーに送り返します。そして理論的には、これらのパケットは1ビットの長さしか必要としません;たとえば、NAKには0を、ACKには1を使用します。
    1. 再送
      • 受信者が誤ったパケットを受信すると、送信者はパケットを再送信します。

rdt2.0の2つの有限状態マシン

ここに画像の説明を挿入

送信者には2つの状態があります
  • 左:rdt_send(データ)イベントが生成されると、送信者は送信するデータを含むパケット(sndpkt)を生成し、チェックサムを付けてから、udt_send(sndpkt)オペレーションを介してパケットを送信します。

  • 右:送信側プロトコルは、受信側からのACKまたはAKパケットを待ちます。

    • ACKパケットが受信された場合(シンボルrdt_rcv(rcvpkt)&& IsACK(rcvpkt)は図のイベントに対応)、送信者は最後に送信されたパケットが正しく受信されたことを認識しているため、プロトコルは上位層のデータを待機する状態に戻ります。
    • NAKパケットが受信されると、プロトコルは最後のパケットを再送信し、再送信されたパケットに応答して受信側から返されたACKとNAKを待ちます。
  • ACKまたはNAK応答パケットを待っている間、送信側は上位層からこれ以上データを取得できないことに注意する必要があります

受信側にはまだ1つの状態しかない
  • パケットが到着すると、受信したパケットが再び破損しているかどうかに応じて、受信者はACKまたはNAKに応答します

    • これは致命的な欠陥のあるACKまたはNAKパケット損失につながります!
  • ACKまたはNAKパケット損失処理方法

    • 可能な解決策

      • 送信者が問い合わせを送信する

        • 新しいグループが必要
      • 送信者がエラーを検出できるだけでなく、エラーを回復できるように、十分なチェックサムビットを追加してください。

        • エラーを生成するが、パケットを失わないチャネルの場合、これは問題を直接解決できます。
      • ACK / NAKパケットビットの受け入れまたは損失がない場合、送信者は現在のデータパケットを直接再送信します。

        • パケットの重複を引き起こす
        • 受信者は、前回送信したACKまたはNAKが送信者によって正しく受信されたかどうかはわかりません。したがって、受信したパケットが新しいものか再送信かを事前に知ることはできません!
    • 実用的なソリューション

      • (ACK / NAK)パケットを確認するには、新しいフィールドを追加し、番号を付け、送信者(ACK / NAKを受信)でシーケンス番号を確認します
      • したがって、rdt2.1の改訂版があります。

rdt2.1の2つの有限状態マシン

ここに画像の説明を挿入
ここに画像の説明を挿入

送信者
  • 状態数は2.0の2倍です。

    • これは、現在送信されている(送信側から)パケットのシーケンス番号、または受信したい(受信側で)パケットのシーケンス番号が0または1のどちらであるかを反映する必要があるためです。
    • パケット番号0の送信または受信を予期している状態でのアクションは、パケット番号1の送信または受信を予期している状態でのアクションと同様であり、唯一の違いはシーケンス番号処理の方法です。
  • 受信者から送信者への肯定的および否定的な確認を使用する

    • シリアル番号に対応するNAKを送信するか、以前のシリアル番号のACK(冗長ACK)が同じ役割を果たすことができます
  • 2.0との微妙な違い

    • レシーバーは、ACKメッセージで確認されたパケットシーケンス番号を含める必要があります(これは、レシーバーFSMのmake_pkt()にパラメーターACK 0またはACK 1を含めることで実現できます)
    • 送信側は、受信したACKメッセージの確認済みパケットシーケンス番号を確認する必要があります(これは、送信側FSMのisACKOにパラメーター0または1を含めることで実現できます)。
  • rdt2.2送信者の凡例
    ここに画像の説明を挿入

3.ビットエラーのあるパケット損失チャネルを介した信頼性の高いデータ伝送:rdt 3.0(ビット交互プロトコル)

rdt3.0の前提

3.0において、我々は、ビットだけが損傷されると仮定し、また、下層チャネル損失(これは正常である)、3.0我々はそう検出処理とパケット損失に対処しなければならない
の損失の場合の動作後に検出及びパケット損失を以下を検討します。

  • 方法1:応答を受信せずに一定時間待機した後、パケットを再送信する

    • 確かに作品

    • 待機時間は、送信側と受信側の間の少なくとも1つの往復遅延(中間ルーターのバッファー遅延に含まれる場合があります)と、受信側がパケットを処理するために必要な時間です。

    • しかし、この種の再送信を一定時間待機すると、問題が発生する可能性があります。

      • 1.最悪の場合の最大遅延を決定することは困難であり、決定する要因はほとんどありません。
      • 2.時間がかかる場合があります
      • 3.冗長データパック(重複データパック)を生成します。前述のシリアル番号でこの問題に対処できます。
  • 方法2:カウントダウンタイマー

    • 一定の時間が経過すると、送信者が中断される可能性があります。
    • したがって、送信者は次のことができる必要があります。
      • ①パケットが送信されるたびに(最初のパケットと再送信パケットを含む)、タイマーが開始されます。
      • ②タイマー割り込みに応答する(適切な処置をとる)。
      • ③終了タイマー
    • これは、rdt3.0でパケット損失を「検出」する実際の方法であります。パケット損失に対処するための対策は、明らかに再送信です。

RDT3.0の有限状態マシンの凡例

ここに画像の説明を挿入

rdt3.0の問題

ここで説明しているrdtプロトコルには、さらに深刻な問題があり、効率は十分ではありません。つまり、前のレポートが完了し、ステータスが受信されるのを確認してから次のパケットを送信するまで待機する必要があるため、多くの無駄が発生します。 !このモードでは、一度に複数のパケットを送信し、複数のパケットが確認されたら次の数パケットを送信します。詳細については、しばらくお待ちください。

4.関連記事の推奨:


トランスポート層のUDPプロトコルを理解していませんか?-ああ、なぜそれを見に来ませんか?この


記事では、多重化と逆多重化の方法を説明します。


私はここで見ました、私の兄弟、姉妹、叔父、そして叔母はシャオワンにコメントを与え、コメントを残します。シャオワンで育ち、あなたの注意が私の最大のサポートです。
是非、何をすべきかを確認してください:Xiao Wangのブログディレクトリインデックス


上記の内容に誤りや欠落がある場合、またはより良い意見がある場合は、コメントを残してお知らせください。できる限りお答えします。

25件の元の記事を公開 賞賛382件 10,000件以上の表示

おすすめ

転載: blog.csdn.net/weixin_45761327/article/details/105698959