パケットの並べ替えと混同
TCPプロトコル「セレクティブリピート」について書かれた教科書を読んでいました。
送信者と受信者の間のチャネル内でパケットを並べ替えることはできないと想定しています。これは、送信者と受信者が単一の物理ワイヤで接続されている場合、一般的に合理的な仮定です。ただし、2つを接続する「チャネル」がネットワークの場合、パケットの並べ替えが発生する可能性があります。実際に採用されているアプローチは、送信者が以前に送信されたシーケンス番号xのパケットがネットワークに存在しないことを「確認」するまで、シーケンス番号が再利用されないようにすることです。これは、パケットが一定の最大時間より長くネットワーク内で「存続」できないと想定することによって行われます。
私は混乱しています。以下は私の2つの質問です。
Q1-「チャネルは、本質的にパケットをバッファリングし、将来の任意の時点でこれらのパケットを自発的に放出すると考えることができます」とは何ですか。平均？古いパケットをバッファリングする必要があるのはなぜですか？受信者がそれを無視する方が良いのではないですか？
Q2-ウィンドウサイズが2で、使用可能なシーケンス番号が0、1、2、3であるとしましょう。送信者は最初にパケット0、パケット1を送信しますが、パケット0は何らかの方法で攻撃されて到着するまでに時間がかかるため、タイムアウトが発生し、送信者はパケット0を再度送信する必要がありますが、今回はパケット0（新規）が時間どおりに到着します。次に、送信者はパケット2、パケット3を送信し、すべて受信者が受信します。そして、送信者はパケット0（新規）とパケット1（新規）を送信しようとしていますが、古いパケット0が受信者に到着したため、受信者はこのパケットが古いパケットか新しいパケットかを知ることができませんでした。では、「パケットが一定の最大時間より長くネットワーク内で「存続」できないと仮定する」ことで、この問題をどのように修正できるでしょうか。パケットヘッダーに送信時刻が含まれているということですか？
回答
「チャネルは、本質的にパケットをバッファリングし、将来の任意の時点でこれらのパケットを自発的に放出すると考えることができます」とは何ですか。平均？なぜ古いパケットをバッファリングする必要があるのですか？受信者がそれを無視するのは良いことではありませんか？
これが、パケット交換の重要な部分であるキューイングとバッファリングの性質です。受信したパケットは、入力時にキューに入れられ、バッファリングされ、転送されるとキューから削除されます。バッファリングが必要です。そうしないと、パケットが受信されるたびに出力リンクが常に空いている必要があります。これは、パケット交換ネットワークでは不可能であり、回線交換ネットワークでのみ可能です。
ウィンドウサイズが2で、使用可能なシーケンス番号が0、1、2、3であるとします。
ウィンドウはパケット/データグラムではなくバイトをカウントします。また、シーケンス番号は、32ビットフィールドがオーバーフローした場合にのみ繰り返されます。これは、4GiBのデータの後でのみ発生します。ただし、その制限は、あいまいさを回避するために、「飛行中」のデータが4ギビバイトを超えることはできないことを意味します。可能な最大ウィンドウは1GiB（に近い）なので、それは問題ではありません。
単純な累積ACKでは、前のセグメントがまだ欠落している場合、レシーバーは後のセグメントを選択的にACKできないことに注意してください。ACKは、以前のすべてのデータが受信されたことを意味します。
たとえば、セグメントサイズが1,000、ウィンドウサイズが10,000の場合、送信者はデータグラムD00〜D09（シーケンス0〜9,999）を送信します。D00とD02-D09は受信されますが、D01は失われます。受信者は引き続き1,000（次に予想されるデータシーケンス）をACKし、送信者がD0をウィンドウの外に移動し、1,000〜10,999に進め、D10を送信するようにトリガーします。
その間、受信者は問題があると判断したので、それを通知するために再度1,000をACKします。送信者はダブルACKを受信し、D01（リラクタントモード）またはD01から始まるすべてのデータ（アグレッシブモード）を再送信します。受信者はすでにD10（10,000-10,999）を取得しているため、11,000をACKし、送信者のウィンドウを11,000-20,999に移動します（アグレッシブモードの場合は、未処理の再送信を中止します）。
（私はプロセスをいくらか単純化しました。実際には、より多くの並列オーバーラップがあり、もちろん送信と受信の間に遅延があります。）
編集：ジェフが正しく指摘しているように（thx！）、選択的確認応答（SACK）のサポートは今日ほぼ与えられています。このオプションを使用すると、受信者は2,000〜9,999（D02〜D09から）をすぐにSACKできるため、送信者はそれらの再送信を開始しません。また、11,000〜20,999より早く送信を開始することもできます。