2

TCP スロー スタートは、インターネットが「輻輳の崩壊」を経験し始めたときに発生しました。Van Jacobson と Michael Karels の論文からの逸話的な例は次のとおりです。

During this period, the data throughput from LBL to UC Berkeley (sites separated
by 400 yards and two IMP hops) dropped from 32 Kbps to 40 bps.

輻輳の問題は、高速リンクから低速リンクへの移行と、このボトルネックでのバッファでのパケットのビルドアップ/ドロップによって引き起こされると説明されることがよくあります。
私が理解しようとしているのは、完全なバッファーにつながるリンクの高速部分で余分なアクティビティ/再送信を単に引き起こすのではなく、そのような蓄積がエンドツーエンドのスループットの低下を引き起こす方法です。例として、次のネットワークを考えてみましょう。

    fast       slow       fast
A ======== B -------- C ======== D

A と D はエンドポイント、B と C は高速ネットワークから低速ネットワークへの移行時のパケット バッファです。たとえば、A/B と C/D 間のリンクは 10Mbps で、B/C 間のリンクは 56Kbps です。ここで、A が大きな（理論的には無限としましょう）Dへのメッセージ、私が理解しようとしているのは、接続の途中で低速のリンク速度に適応するのではなく、TCP接続をデータで叩いた場合、通過するのに時間がかかる理由です. 私は、B は、A によってバッファがどれだけ大量に叩かれているかに関係なく、またバッファがいっぱいになったために破棄しなければならないパケットの数に関係なく、56Kbps の固定レートでバッファが消耗するものであると想定しています。したがって、A が常に B のバッファーをフル (場合によってはオーバーフル) に保ち、B が常に最大レートの 56Kbps で送信している場合、代わりにスロースタートを使用することで、スループットはどのように向上しますか?

私が考えられる唯一のことは、D が既に受信した同じパケットが、輻輳の下で低速の B/C リンクを介して再送信される必要があり、これが新しいパケットをブロックしているということでした。しかし、D は通常、受信したすべてのパケットに ACK を送信していないので、再送信されるパケットのほとんどは、B のバッファーでドロップされたために D によって正当に受信されなかったものである必要があります。

4

1 に答える 1

2

ネットワークには、複数のコンピューター間でのリソースの共有が含まれることに注意してください。非常に単純化すると、少数のTCPセッションによるルーターバッファーの枯渇を回避するためにスロースタートが必要です（図では、これはポイントBとCで発生する可能性が最も高いです）

RFC 2001、セクション1から：

古いTCPは、受信者によってアドバタイズされたウィンドウサイズまで、ネットワークに複数のセグメントを挿入する送信者との接続を開始します。2つのホストが同じLAN上にある場合、これは問題ありませんが、送信者と受信者の間にルーターがあり、リンクが遅い場合、問題が発生する可能性があります。一部の中間ルーターはパケットをキューに入れる必要があり、そのルーターのスペースが不足する可能性があります。[2]は、この単純なアプローチがTCP接続のスループットを大幅に低下させる方法を示しています。

..。

[2]  V. Jacobson, "Congestion Avoidance and Control," Computer

    Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
    ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

ルーターには有限のバッファーが必要です。リンク間の速度の不一致が大きいほど、スロースタートなしでバッファが枯渇する可能性が高くなります。バッファが使い果たされると、バッファリングによってTCPがリンクを利用する能力が向上するため、平均TCPスループットが低下します（瞬間的なリンク飽和のための不要なドロップを防ぎます）。

上記のRFC2001はRFC5681に取って代わられていることに注意してください。ただし、RFC 2001は、あなたの質問に対してより割り当て可能な答えを提供します。

あなたのOPから...

ここで、Aが大きな（たとえば理論的には無限の）メッセージをDに送信する場合、私が理解しようとしているのは、TCP接続をデータで叩いただけでは、遅いリンク速度に適応した場合に、通過するのに時間がかかる理由です。接続の途中で。

まず、TCPには無限のメッセージのようなものはありません。TCPは、スロースタートが発生する前の初期ウィンドウサイズによって制限されていました。

したがって、最初のTCPセグメントの長さが64KBだったとしましょう。TCPセグメント全体がBでルータのtxバッファをいっぱいにする場合、パケット損失、ACK、およびTCPバックオフに関連するダイナミクスにより、TCPは時間の経過とともに使用するリンクが少なくなります。個々の状況を見てみましょう：

  • Bのtx_buffer<64KB：AのTCPは、Bがパケットをデキューできるよりも速く送信しているため、再送信の時間が自動的に失われました。
  • Bのtx_buffer>=64KB：Aが送信している唯一のステーションである限り、悪影響はありません（Dが正しくACKされている限り）。ただし、56Kリンクを通過しようとしているAのLAN上で送信している複数のホストがある場合、56Kで単一の1500バイトパケットをデキューするのに200ミリ秒かかるため、おそらく問題があります。Aの64KB初期ウィンドウから44個の1500バイトパケットがある場合（44 * 1460 = 64KB、1460バイトのTCPペイロードしか取得できません）、ルーターにはAのトラフィックを処理するほぼ9秒間の飽和リンクがあります。

2番目の状況は公平でも賢明でもありません。TCPは、パケット損失を検出するとバックオフします...単一のリンクを共有する複数のホストは、状況を正常に保つためにスロースタートを使用する必要があります。

ところで、私はインターフェイスで9秒のバッファリングを備えたルーターを見たことがありません。この種の遅延を許容するユーザーはいないでしょう。ほとんどのルーターの最大秒数は約1〜2秒で、それは数年前のT-1速度でした。いくつかの理由から、今日のバッファはさらに小さくなっています。

于 2012-06-13T09:18:08.910 に答える