TCPスロースタート、混雑制御、ECNノート

7428 ワード

TCPスロースタート、混雑制御、ECNノート


1,TCPスロースタート


TCPは接続プロセスの3回の握手が完了した後、データの転送を開始し、最初はネットワークチャネルに大量のパケットを送信するのではなく、ネットワーク内のルータキャッシュ空間が消耗しやすく、混雑が発生する.初期のcwndサイズに基づいて送信データ量を徐々に増加させ、cwndは最大メッセージセグメント(MSS)サイズに初期化される(この値は必ずしも1つのMSSとは限らない).メッセージセグメントが確認されるたびにcwndサイズ指数が増加する.開始->cwnd=1 RTT後->cwnd=2*1=2 RTT後->cwnd=2*2=4 3 RTT後->cwnd=4*2=8

2、混雑回避


cwndはこのように無限に成長することはできません.必ず制限が必要です.TCPは、cwnd>=ssthresh(ほとんどのTCPの実装では、通常65536の大きさ)になると、遅い起動プロセスが終了し、混雑回避フェーズが開始する.混雑回避:cwndの値は指数的に上昇せず、加算が増加し始める.このとき、ウィンドウ内のすべてのメッセージセグメントが確認されると、cwndのサイズが1になり、cwndの値はRTTが開始するにつれて線形に増加し、成長が速すぎるとネットワークが混雑し、徐々に増加してネットワークの最適値に調整されることを回避することができる.非ECN環境での混雑判定では,送信側RTOがタイムアウトし,メッセージセグメントが再送された.
  • 1、ssthreshをcwnd値の半分に下げる.
  • 2、cwndを1に再設定します.
  • 3、スロースタートプロセスに再突入します.

  • 3、クイック再送


    高速再送では、TCPは、重複した3回のACKを受信すると、再送キューの最初のメッセージセグメントがネットワークによって破棄されたとみなされるが、受信した重複した3回のACKのため、そのメッセージセグメントの後の3つのメッセージが受信側に受信されたとみなされ、再送タイマのタイムアウトを待たずに、再送キューの最初のメッセージセグメントを直接再送する.
  • 1、ssthreshをcwndの半分
  • に設定
  • 2、cwndをssthreshの値(具体的にはssthresh+3)
  • に再設定する
  • 3、再び混雑回避段階に入ります.

  • 4、迅速なリカバリ


    高速リカバリのパケット保存の原則は、同じ時点でネットワーク内のパケット数が一定であり、「古い」パケットが離れてから、ネットワークに「新しい」パケットを送信することができます.送信側が反復ACKを受信すると、TCPのACKメカニズムは、パケットが離れていることを示し、cwndは1を加算する.
  • 1は、3つの重複ACKを受信した場合、ssthreshをcwndの半分に設定し、cwndをssthreshの値に3を加えた後、失われたメッセージセグメントを再送し、3を加えたのは、3つの重複ACKを受信したためであり、3つの「古い」パケットがネットワークを離れたことを示している.
  • 2,ACKが繰り返されると,混雑ウィンドウは1増加する.
  • 3は、新しいパケットのACKを受信すると、cwndを第1ステップのssthreshの値に設定する.なぜなら、ACKは新しいデータを確認し、ACKを繰り返したときのデータがすべて受信されたことを示しており、この回復プロセスは終了し、回復前の状態に戻ることができ、すなわち再び混雑回避状態に入ることができるからである.

  • 5,ECN(Explicit Congestion Notification)、WWDC 2017は再び


    5.1、既存TCPの混雑時に発生する問題


    非ECN環境では,ネットワーク中間ルータがパケットを失った場合,TCPプロトコルはRTOタイムアウトにより失われたパケットを再送し,データ信頼性を保証する.ネットワークリンク内のルータでは、中間ルータキューの過負荷によりパケットが失われると、各ホスト間のTCP接続は、中間ルータの転送キューのビジー状態を感知しない.RTOタイマがタイムアウトした後、ACKが受信されなかったため、メッセージの再送が開始される.このタイマーの時間は比較的長く、通常は数秒から数十秒まで異なる.メッセージ破棄は多重TCPが送信速度を低下させ始め,1つのウィンドウの送信が完了した後もTCPの再送タイマがタイムアウトしない前に,送信プロセス全体がたまに停滞する.すべてのTCPが性能を下げた後、ルータの転送キューの混雑は緩和され、メッセージを捨てなくなり、すべてのTCPは同時に送信速度を高め、ある程度に達した後、ルータはまたメッセージを捨て始め、さっきのTCPの再送過程を繰り返します.この現象の問題は次のとおりです.
  • 1、パケット損失はTCP再送を招き、この再送タイマは時間が長く、遅延に敏感な応用にとって、ユーザーの感覚に影響を与える.
  • 2,パケット損失後,すべてのTCPは退避を開始し,送信性能を低下させ,混雑は緩和されたが,このときのネットワーク利用率は最適化できなかった.
  • 3、混雑緩和後、TCPは、送信の最適性能を得るために、パケット損失が発見されるまで、送信ウィンドウを拡大し続け、上記の問題プロセスを繰り返す.

  • 5.2,中間ルータ混雑制御キュー


    ルータの転送キューは、通常、RED機能を実現します.すなわち、ルータは、現在のキューの平均長さに基づいてパケット損失決定を行い、キューが満載になるまで待つのではなく、TCPメッセージセグメントをランダムに破棄し、すべてのTCPが同時にタイムアウトする問題を回避します.

    5.3,ECN設計


    TCPとIPヘッダの修正により、以下の問題を解決できる.
  • 1、すべてのTCP送信側はできるだけ早く中間経路の混雑を感知し、cwndを自発的に減少させる.
  • 2は、中間ルータにおいて平均キュー長を超えるTCPメッセージに対してECNタグを行い、転送を継続し、メッセージを破棄せず、メッセージ破棄と送信側再送信を回避する.
  • 3は、明示的な標識混雑の発生により、RTOタイムアウト(時間が比較的長い)を待たずにデータを再送信し、遅延感度の高いアプリケーションの直感的な感覚を向上させる.
  • 4は、非ECNネットワーク環境に比べてネットワーク利用率が高く、過負荷と軽負荷の間で振動することはありません.

  • 5.4、IPとTCPの首部に対する修正


    IPヘッダの修正
         0     1     2     3     4  5  6 7
    +-----+-----+-----+-----+-----+-----+-----+-----+
    | DS FIELD, DSCP | ECN FIELD |
    +-----+-----+-----+-----+-----+-----+-----+-----+

    DSCP: differentiated services codepoint
    ECN: Explicit Congestion Notification
    The Differentiated Services and ECN Fields in IP.

    +-----+-----+
    | ECN FIELD |
    +-----+-----+
    ECT CE [Obsolete] RFC 2481 names for the ECN bits.
    0 0 Not-ECT
    0 1 ECT(1)
    1 0 ECT(0)
    1 1 CE

    The ECN Field in IP.

    IPヘッダのTOSフィールドの7および8 bitのresフィールドは、4つの値をとるECNフィールドとして再定義され、RFC 3168において、00は、このメッセージがECNをサポートしていないことを示すので、ルータのこのメッセージは、元の非ECNメッセージ処理、すなわち、過負荷パケット損失である.01と10の2つの値はルータにとって同じであり、いずれもこのメッセージがECN機能をサポートしていることを示しており、混雑が発生すると、ECNフィールドの2つは11に変更され、メッセージが混雑を経てルータに転送され続けることを示す.01と10の具体的な違いについてはRFC 3168を参照してください.ルータ転送側がECNをサポートするには、以下の新機能が必要です.
  • 1、混雑が発生した場合、ECN=00のメッセージに対して、従来の非ECNフロー、すなわち、REDパケット損失を行う.
  • 2、混雑が発生した場合、ECN=01またはECN=10に対するメッセージは、いずれもECN=11に変更し、転送プロセスを継続する必要がある.
  • 3、混雑が発生した場合、ECN=11のメッセージに対して、転送を継続する必要がある.
  • 4、ECNメッセージをサポートしない公平性を保証するために、キューが一定の長さを超える場合、ECNメッセージをサポートする破棄を考慮する必要がある.

  • TCPヘッダの修正
        0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    | | | C | E | U | A | P | R | S | F |
    | Header Length | Reserved | W | C | R | C | S | S | Y | I |
    | | | R | E | G | K | H | T | N | N |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    CWR: Congestion Window Reduce
    ECE: ECN-Echo
    The new definition of bytes 13 and 14 of the TCP Header.

    ホスト側の変更に対して、ヘッダはbit 8とbit 9のresフィールドをCWRとECEに変更する.RFC 3168における設計は以下の通りである.
  • 1は、TCP受信側でIPヘッダのECN=11フラグを受信し、ACKの返信時にECE bitを1にセットする.ECE bitは、後続のACKの合計で1に設定される.
  • 2、TCP送信側でECE bitセット1のACKメッセージを受信した場合、自分の送信レートを半減し、次のメッセージを送信した場合、CWR bitを1にする必要がある.
  • 3、受信側でCWR bitセット1のメッセージを受信した場合、後続のECE bitは1をセットしません.IPヘッダECN=11が再び受信されるまで、上記の手順を繰り返す.
  • 4、TCP送信側は、ECE=1を受信すると、送信ウィンドウを縮小し、今回のRTT時間内に送信ウィンドウを再び縮小しない.
  • 5、TCP受信側が送信側にACKを応答する場合、このACKがデータを持たない「純」ACKである場合、IPヘッダECN=00が必要となる.TCPが純ACKに応答するメカニズムがないため、純ACKに対して混雑通知を送信できない.
  • 6、IP ECNをサポートするホストに対して、TCP層は、メッセージを送信する際にIPヘッダのECNを01または10にする必要がある.

  • まとめ


    他人のブログを記録し転載し、記憶を深める.

    リファレンス

  • 『TCP/IP詳細、巻1:プロトコル』
  • http://blog.csdn.net/itmacar/article/details/12278769
  • ECN:http://blog.csdn.net/xxx_500/article/details/8584323

  • 転載先:https://www.cnblogs.com/edisongz/p/6986527.html