2

TCP高速回復アルゴリズムは次のように記述されています(TCP図解vol.1より)。ステップ 1 で理解できないのは、CWD ウィンドウがセグメント サイズの 3 倍になるのはなぜですか?

  1. 3 番目の重複 ACK を受信したら、ssthresh を現在の輻輳ウィンドウ cwnd の半分に設定します。欠落しているセグメントを再送信します。 cwnd を ssthresh にセグメント サイズの 3 倍を加えた値に設定します。
  2. 別の複製 ACK が到着するたびに、cwnd をセグメント サイズだけインクリメントし、パケットを送信します (cwnd の新しい値で許可されている場合)。
  3. 新しいデータを確認する次の ACK が到着したら、cwnd を ssthresh に設定します。これは、ステップ 1 からの再送信の ACK である必要があります。再送信の 1 ラウンドトリップ時間後です。さらに、この ACK は、失われたパケットと最初の重複 ACK の受信との間に送信されたすべての中間セグメントを確認する必要があります。このステップは、パケットが失われたときの速度の半分に減速しているため、輻輳の回避です。
4

1 に答える 1

2

[RFC 2001][1] より

3 回連続で重複 ACK を受信したら、ssthresh を設定します。

現在の輻輳ウィンドウ cwnd の半分ですが、2 セグメント以上です。欠落しているセグメントを再送信します。cwnd を ssthresh にセグメント サイズの 3 倍を加えた値に設定します。これにより、ネットワークを離れ、相手側がキャッシュしたセグメントの数だけ輻輳ウィンドウが膨らみます。

そのため、3 つの重複 ACK を続けて受信すると、cwnd を半分に減らして高速再送信を実行します。これからは、次の新しい ACK を待っている間、アイドル状態にならないようにします (せいぜい 1 RTT)。高速リカバリに入ると、次の方法で新しいデータを送信します

cwnd= 元の cwnd + 受信した重複 ACK の数

待っていたACKを受け取るか、そのACKのタイマーが切れるまで。

基本的に、その「+3」は、最初に高速回復に入った3つのackを考慮して、失われたバイト+レシーバーに到達したが破棄されたバイトに等しい数の新しいバイトを送信します。[1]: https://www.rfc-editor.org/rfc/rfc2001

于 2020-06-13T10:22:39.737 に答える