26

そのため、Nagle のアルゴリズムに出くわし、小さいサイズのパケット (1 バイト データ) の ACK を遅延させたとき、TCP の処理を​​行っていました。その理由は、ネットワーク上で小さなパケットを大量に送信すること (Nagle) と、データをピギーバックすること (Delayed ACK) を回避するためです。ただし、バルク データのこれらのアルゴリズムについては言及されていません。つまり、8000 バイトを超える書き込みを行います。4 つの質問:

  1. これらのアルゴリズムは小さなサイズのパケットにのみ適用できますか?

  2. たとえば、write(8000) を実行すると、TCP は最初に 1500 バイトを送信します (1500 が MSS であり、スロー スタートが発生していると仮定します)。ACK が最初に受信される前に、別の 1500 バイトのデータを送信できます。ネーグルズに違反していませんか？

  3. 受信者は、遅延 ACK を送信するためにタイムアウトを待ちますか、それとも 1500 バイトのデータを受信した直後に送信しますか?

  4. ACK を遅らせるタイミングをどのように知るのでしょうか? 受信バッファ内のバイトに基づいていますか?

ありがとう！

4

3 に答える 3

77

Nagle アルゴリズムの考え方は、サイズの小さい複数のパケットが一度に転送されるのを防ぐことでした。遅延 ACK (バークレーに由来) のアイデアは、リモート エコーを使用して Telnet 接続を介して入力するときに受信した文字ごとに 1 つの ACK を送信することを回避することであり、逆方向のトラフィックを一定期間待機することで、ACK をピギーバックすることができました。 .

2 つのアルゴリズムの相互作用はひどいものです。ビッグセンド、ビッグセンド、ビッグセンドを行うと、うまくいきます。送信して返信を取得し、送信して返信を取得すると、正常に機能します。小さい送信、小さい送信、返信を取得すると、短いストールが発生します。これは、2 回目の小さな送信が Nagle アルゴリズムによって ACK が返ってくるまで遅延され、遅延 ACK アルゴリズムがそれが発生する前に 0.5 秒程度追加されるためです。

遅延 ACK は賭けです。TCP 実装は、データがすぐに送信されることに賭けており、単一の ACK を送信する必要がなくなります。遅延 ACK が実際に送信されるたびに、その賭けは失われます。TCP 仕様では、遅延 ACK をオフにすることなく、実装が毎回その賭けを失うことができます。適切には、遅延 ACK は、ピギーバックされた可能性のあるいくつかの不要な ACK が連続して送信された場合にのみオンにする必要があり、遅延 ACK が実際に送信されるたびに、遅延 ACK を再びオフにする必要があります。これにはカウンターがあったはずです。

残念ながら、私が 1986 年にネットワークから離れた後、ACK の遅延が発生しましたが、これは修正されませんでした。もう手遅れです。

ジョン・ネーグル

于 2013-05-21T06:06:09.220 に答える