一般的に言えば、私たちは常にデータをより速く転送することを望んでいます。ただし、送信者の送信速度が速い場合、受信者はそれを受信する時間がない可能性があり、データ損失が発生します。いわゆるフロー制御は、受信者が時間内に受信できるように、送信者の送信が速すぎるのを防ぎます。
スライディング ウィンドウはフロー制御の実装に使用されます。次のスライディング ウィンドウ フロー制御の例を示します。
上の図では、A が送信者として機能し、B が受信者として機能します。A が 3 つのデータグラムを送信するとき (3 番目のデータグラムが失われる)、各データグラムの長さは 100 バイトであり、B は最初のフローの後に送信します。制御では、返された rwnd (受信ウィンドウ) を介した受信ウィンドウのサイズは 300 バイトであり、送信者にさらに 300 バイト送信できることを伝えます。201 ～ 300 バイトのデータは一時的に受信されないため、ack=201、 ACK は受信が確認されたことを示す 1 に設定され、このとき確認番号フィールド ack のみが意味を持ちます。
同様に、後ほど 2 つのフロー制御があります。受信者がデータグラムを受信者に送信するたびに、3 つの主要な情報フィールドが存在します。1 つは ACK の確認で、もう 1 つは ACK の確認です。確認番号フィールドは 1 の場合にのみ有効です。 2 番目は確認番号フィールド ack で、受信が予想される次のデータグラムの開始バイト シーケンス番号を示します。 3 番目の rwnd は、受信側がまだ送信できるデータ セグメントのバイト範囲を示します。
特殊なケースを考えてみましょう。受信者が rwnd=0 のデータグラムを送信者に送信しましたが (おそらく、受信するためのバッファ スペースがまだないため)、余分なバッファ スペースがあり、受信したい場合です。送信者のデータからさらに多くのデータを取得します。次に、B は rwnd=400 のデータグラムを A に送信しますが、このデータグラムは送信プロセス中に偶然失われます。このとき、A は B からの非ゼロ ウィンドウ通知を待ち、B は A から送信されるデータを待ちます。この場合、両者はお互いを待っているため、行き詰まりの状況が形成されます。
解決策は次のとおりです: TCP には接続ごとに継続タイマーがあります。A がゼロ ウィンドウ通知を受信している限り、連続タイマーが開始されます。時間が経過すると、A はゼロ ウィンドウ検出メッセージ セグメントを B に送信し、B はウィンドウ値を A に送信できます。まだ 0 の場合は、連続タイマーをリセットします。 0 の場合、デッドロック状況が解消され、A はデータを送信できるようになります。
私の理解: TCP 接続が確立されているため、ほとんどの場合、データを送信する必要があります。送信しないと接続が閉じられる可能性があるため、受信側が受信ウィンドウを 0 に設定する場合があっても、多くの場合、これは、キャッシュがあまり混雑していないためであるため、送信者はしばらくすれば情報を送信できると信じる理由があります。なぜなら、上記の状況のように、送信者がデータを送信することを目的としたメッセージが失われる可能性があるからです。
参考書籍：『コンピュータネットワーク（第七版）』謝西仁著