ウィンドウサイズがSRプロトコルのシーケンス番号の半分以下になるのはなぜですか？
選択的繰り返しプロトコルでは、ウィンドウサイズはSRプロトコルのシーケンス番号スペースのサイズの半分以下でなければなりません。なぜそうなのですか？
これは、パケットが正しく認識されないようにするためです。
ウィンドウサイズがシーケンス番号スペースの半分より大きい場合、ACKが失われると、送信者は受信者が再送信であると信じている新しいパケットを送信できます。
たとえば、シーケンス番号の範囲が0〜3で、ウィンドウサイズが3の場合、この状況が発生する可能性があります。
A-> 0-> B
A-> 1-> B
A-> 2-> B
A <-2ack <-B（これは失われます）
A-> 0-> B
A-> 1-> B
A-> 2-> B
失われたパケットの後、Bは次のパケットがシーケンス番号3、0、および1を持つことを期待します。
しかし、Aが送信している0と1は実際には再送信なので、Bはそれらを順不同で受信します。
この例ではウィンドウサイズを2に制限することで、Bが2と3を期待し、再送信できるのは0と1だけなので、この問題を回避します。
シーケンススペースは、最大数に達するとゼロに折り返されます。 all ACKが失われるというコーナーケースを考えてみます。送信側はウィンドウを移動しませんが、受信側は移動します（送信側がACKを取得していないことに気付かないため）。ウィンドウサイズをシーケンススペースの半分に制限しない場合、送信側は「送信されたが確認応答されていない」と受信側は「有効な新しい」シーケンススペースが重複することになります。これにより、再送信が新しいパケットとして解釈されます。
それは、受信側が古いパケットと新しいパケットを区別できないためです。受信者はシーケンス番号に基づいてパケットを識別し、接続ごとに有限数の一意の番号があります。あなたは無限のバッファを持つことはできません。
明らかな失敗シナリオを見てみましょう：
ウィンドウサイズがシーケンス番号スペースよりも大きい。シーケンス番号が0、1、2であるとします。また、ウィンドウサイズは4です。これは、ウィンドウに0が2回出現することを意味します。
0、1、2、0 <-モジュロラップ。 seqが0のパッケージを取得したとき。最初のパケットですか、それとも4番目のパケットですか。全く分からない。この問題は、ウィンドウサイズがシーケンス番号スペースの半分よりも大きい場合に発生します。どうして？それは、受信者がNEWまたはOLDである送信者からのパケットに含まれている可能性のあるシーケンス番号を見ている可能性が常にあるからです。それは常に起こりますか？いいえ。ただし、その場合、次のことが起こります。
ケース1：
パケット0、1、2を正しく受信した後のレシーバーウィンドウ。 0,1,2、[3,0,1]、2しかし、送信されたACKが失われた場合はどうなりますか？さて、送信者は0,1,2を再送信します。しかし、0,1は古いのですか、それとも新しいのですか？レシーバーにはわかりません。
ケース2：
受信側の同じウィンドウ。 3つのパケットが受信されます。
0、1、2、[3、0、1]、2
これで、受信側はすべての確認応答を正しく受信しますが、1つは正しく受信します。 2つ目（1）を選択してみましょう。さて、1を再送信します。しかし、レシーバーは1を見ています。それで、これは期待どおりの新しいものですか（いいえ）、または古いものですか？
したがって、ウィンドウが潜在的な未解決のパケット（通常の送信または欠落したackの再送信からのパケット）によって使用される可能性のあるシーケンス番号を決して期待しないようにするには、ウィンドウサイズを小さくするか、シーケンス番号を大きくする必要があります。
シーケンス番号のスペースを6に増やすとどうなるか見てください。
0、1、2、3、4、5。
どのようにウィンドウを配置しても、古いシーケンス番号のパケットを受信する危険はありません。
0,1,2、[3,4,5] 0,1 ...
ウィンドウが一周するまでに、前のウィンドウが順番に受信されていることを確信しています。
このリンクには、ウィンドウサイズが重要である理由を説明するために、プロトコルの各ステップを説明するアニメーションがあります。
http://webmuseum.mi.fh-offenburg.de/index.php?view=exh&src=7
基本的に、ウィンドウサイズが大きすぎる場合、送信の破損により誤った仮定が生じ、最終結果のデータが破損する可能性があります。