主な違い: フロー制御は送信側と受信側の間のレートの不一致の問題を解決し、輻輳制御はネットワーク リソースの枯渇を回避するという問題を解決します。フロー制御はスライディング ウィンドウを通じて実装され、輻輳制御は輻輳ウィンドウを通じて実装されます。
このチュートリアルの動作環境: Windows 7 システム、Dell G3 コンピューター。
関連する推奨事項: 「プログラミング教育」
フロー制御と輻輳制御の違い
TCP フロー制御と輻輳制御は比較的似た概念であるため、混同されやすいようです。しかし実際には、彼らが望む目標や方法はまったく異なります。
フロー制御は、送信者と受信者の間のレートの不一致の問題を解決します。送信者の送信が速すぎると、受信者はそれを受信して処理する時間がなくなります。使用されるメカニズムはスライディング ウィンドウ メカニズムで、送信されても確認されないパケットの数を制御します。
輻輳制御は、ネットワーク リソースの枯渇を防ぐという問題を解決します。自律的に回避策を講じることで、誰もが限られたネットワーク リソースの枯渇を回避できます。パケットロスが発生した場合、送信レートを制御してネットワーク負荷を軽減します。
フロー制御
#輻輳制御
輻輳制御は、輻輳ウィンドウを通じて実現されます。輻輳ウィンドウとは、送信者が 1 つの RTT 内に送信できるデータ パケットの最大数を指します。 - 輻輳制御には通常、スロー スタートと輻輳回避の 2 つの段階が含まれます。
- スロー スタート フェーズは、1 から制限されたサイズまで指数関数的に増加するプロセスです。
-
- 輻輳回避フェーズでは、制限サイズを超えた後に直線的に増加するプロセスと、パケット損失を発見した後に輻輳ウィンドウを 1 に変更して制限サイズを半分にするプロセスが行われます。
拡張情報
フロー制御はエンドツーエンドの制御です。たとえば、A は、データをネットワーク経由で B に送信する データ A の送信速度が速すぎて B が受信できない (B のバッファウィンドウが小さすぎる、または処理が遅すぎる) このときの制御がフロー制御であり、原理はサイズを変更することで実現されます。引き違い窓のこと。
輻輳制御とは、A と B の間のネットワークがブロックされ、その結果、送信が遅すぎるかパケット損失が発生し、送信する時間がなくなった場合のことです。ネットワークに過剰なデータが注入されないようにすることで、ネットワーク内のルーターやリンクが過負荷になるのを防ぎます。輻輳制御は、すべてのホスト、ルーター、およびネットワーク パフォーマンスの低下に関連するすべての要素が関与するグローバル プロセスです。
フロー制御メカニズム: 
ホスト A がホスト B にデータを送信するとします。双方によって決定されるウィンドウ値は 400 です。各メッセージ セグメントの長さは 100 バイト、シーケンス番号の初期値は seq=1 であると仮定します。大文字の ACK はヘッダーが ACK と見なされることを示し、小文字の ACK は値を示します。確認フィールドの。
受信側ホスト B は 3 回フロー制御を実行しました。最初にウィンドウが rwind=300 に設定され、2 回目は rwind=100 に減らされ、最後に rwind=0 に減らされます。つまり、送信者はそれ以上データを送信できません。送信者が送信を一時停止するこの状態は、ホスト B が新しいウィンドウ値を再送信するまで続きます。
B がゼロウィンドウ メッセージ セグメントを A に送信した直後、B の受信バッファーにある程度の記憶領域があるとします。したがって、B は rwind=400 のメッセージ セグメントを A に送信しましたが、このメッセージ セグメントは送信中に失われました。 A は B によって送信された非ゼロ ウィンドウ通知の受信を待機しており、B は A によって送信されたデータを待機しています。これによりデッドロックが発生します。このデッドロック状況を解決するために、TCP には接続ごとに継続的なタイマーが用意されています。 TCP 接続の一方が他方からゼロ ウィンドウ通知を受信している限り、連続タイマーを開始し、連続タイマーで設定された時間が経過すると、ゼロ ウィンドウ検出メッセージ セグメント (1 バイトのみのデータを伝送) を送信します。 ) と相手 この検出セグメントを確認すると、現在のウィンドウ値が表示されます。
輻輳制御メカニズム:
スロースタートと輻輳回避
メッセージセグメントの送信速度は、受信側の受信能力とネットワークの輻輳を引き起こさないことを総合的に考慮して決定する必要があり、受信ウィンドウと輻輳ウィンドウの2つの状態量によって決定されます。受信者ウィンドウ (受信者ウィンドウ) は、アドバタイズド ウィンドウとも呼ばれ、現在の受信バッファ サイズに基づいて受信者によって約束された最新のウィンドウ値であり、受信者からのフロー制御です。輻輳ウィンドウ cwnd (Congestion Window) は、ネットワークの輻輳レベルを推定して送信側が設定するウィンドウ値であり、送信側からのフロー制御です。
スロースタート原則:
#1) ホストがデータの送信を開始すると、より大きな送信ウィンドウのすべてのデータ バイトが直ちにネットワークに注入される場合場合、ネットワークの状況が明確ではないため、ネットワークの輻輳が発生する可能性があります。
2) より良い方法はテストすることです。つまり、送信者の輻輳制御ウィンドウの値を小さい到着から徐々に増加させます
3) 通常、メッセージ セグメントの送信を開始するときは、まず輻輳ウィンドウ cwnd を最大のメッセージ セグメントの MSS の値に設定します。新しいメッセージ セグメントの確認が受信されるたびに、輻輳ウィンドウは最大 1 MSS 値ずつ増加します。rwind が十分に大きい場合、輻輳ウィンドウ cwind の増大がネットワークの輻輳を引き起こすのを防ぐために、別の変数が必要です。 ssthresh
輻輳制御の具体的なプロセスは次のとおりです:
1) TCP 接続の初期化、輻輳ウィンドウを 1 に設定します
2) 実行が遅い アルゴリズムを開始すると、cwind == ssthress が輻輳回避アルゴリズムの実行を開始するまで、cwind は指数関数的に増加し、cwnd は線形に増加します
3) ネットワーク内で輻輳が発生すると、ssthresh 値を次のように更新します。輻輳前の ssthresh 値の半分 cwnd を 1 にリセットし、手順 (2) に従います。
高速再送信と高速リカバリ
TCP 接続は、再送信タイマーの期限が切れるのを待っているため、長時間アイドル状態になることがあります。低速開始と輻輳回避では、この問題を十分に解決できません。問題、したがって、高速再送信と高速回復を備えた輻輳制御方法が提案されています。
高速再送信アルゴリズムは再送信メカニズムをキャンセルしませんが、場合によっては失われたメッセージ セグメントをより早く再送信します (送信者が 3 回繰り返される確認 ACK を受信した場合、パケットが失われた場合、失われたセグメントは失われると判断されます)。再送信タイマーの期限が切れるのを待たずに、すぐに再送信されます）。スロー スタート アルゴリズムは、TCP が確立されている場合にのみ使用されます。
高速回復アルゴリズムには、次の 2 つの重要なポイントがあります:
1) 送信者が 3 回連続して重複確認を受信すると、「乗算削減」アルゴリズムを実行し、スロー スタートしきい値を半分にします。これはネットワークの輻輳を防ぐためです。
2) 送信側は、ネットワークがおそらく混雑していないと考えているため、スロー スタート アルゴリズムを実行せず、代わりに、cwnd 値をスロー スタートしきい値が半分になった後の値に設定します。次に、輻輳回避アルゴリズムの実行を開始し、輻輳ウィンドウが直線的に増加します。
概要:
最初の 2 つのアルゴリズムは輻輳が発生する前に使用され、後の 2 つのアルゴリズムは輻輳が発生した後 (つまり、確認が 3 回繰り返された後) に使用されます。
さらに関連記事を読みたい場合は、PHP 中国語 Web サイト にアクセスしてください。 ！
以上がフロー制御と輻輳制御の主な違いは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
