トランスポート層とデータリンク層にスライディングウィンドウメカニズムが必要なのはなぜですか？TCPには、フローとエラーを管理するための独自のスライディングウィンドウメカニズムがあります。また、データリンク層にも同様のメカニズムがあります。これは冗長ではありませんか？
4197 次
1 に答える
1
TCP と UDP のエラー制御は、各パケットをカバーする単一のチェックサムです。失敗した場合は、パケット全体を破棄する必要があり、受信がタイムアウト後にデータの受信を確認できなかった場合は、データを再送信する必要があります。ネットワーク パスに沿った 2 つのルーター間の 1 つのデータ リンクでデータ破損が発生した場合でも、元の送信者からデータを再送信し、複数のネットワーク ホップを再び通過する必要があります。これは非常にコストがかかるため、この種のデータ整合性チェックは、エラー率が非常に低く、再送信のコストが多くの正常に送信されたパケットで償却される場合に適しています。また、単純なチェックサムはそれほど堅牢ではなく、いくつかのエラーを見逃す可能性があります。
特定の種類のネットワーク リンクでは、IP トランスポート プロトコルが効率的に処理するにはエラー率が高すぎることが予想される場合があるため、IP が機能するためには、独自のエラー検出 (または転送エラー訂正) レイヤーを提供する必要があります。それらをはるかに超えています。当初、(アナログ) モデムは、速度がますます高くなるにつれて、この種の完全性保護 (たとえばV.42 ) を導入したことがよく知られています。最近よく使われている種類の物理リンクの詳細についてはあまり知りませんが、1 つまたは複数のDOCSIS、ADSL、wifi、および/または 3G/4G/LTE には、この種の技術が組み込まれています。また、これらすべてがデータリンク層 (レイヤー 2) ではなく、物理層 (レイヤー 1) で発生していると考えていることにも注意してください。ネットワーキングの現実世界。
この種のエラー制御は、必ずしも物理層 (または必要に応じてデータリンク層) に何らかの種類のスライディング ウィンドウがあることを意味するわけではありません。最も信頼性の低い種類の物理リンク用に設計された、より複雑なスキームの一部には含まれている可能性がありますが、最も単純な種類のエラー チェックには含まれていません。たとえば、PPP やイーサネットFCSなどです。FCS では、UDP チェックサムと同様に、破損したパケットは単にドロップされ、プロトコルには失敗したフレームを再送信するためのメモリまたはウィンドウがなく、送信者に正常に受信されたフレームを確認しません (つまり、ウィンドウを進めるには、あらゆる種類のスライディング ウィンドウ プロトコルで必要です)。
そうは言っても、トランスポート層のエラー制御メカニズムはエンドツーエンドであるため、依然として不可欠です。この層でのみ、伝送媒体によって導入されたエラー以外のエラーが捕捉されます。IP トランスポート プロトコルのチェックサムは、ルーター内で発生した破損、エラーを検出できない、または検出できない物理メディアによって発生したエラー、またはホスト デバイスまたはデバイス ドライバーのエラーを検出します。
それはエラー制御のためです。フロー制御についても同じことが言えます。そうでなければ IP が機能するのに問題がある種類の物理リンクを処理する複雑なスキームがいくつか存在する可能性がありますが、ほとんどの単純なスキームには、いかなる種類のスライディング ウィンドウも含まれていません。たとえば、RS-232シリアル リンクを介して通信する場合、フロー制御は単純なバイナリ制御線です。アサートされると、もう一方の端はデータを送信し、デアサートされると、もう一方の端は一時停止します。ウィンドウで以前に送信されたデータは記憶されず、確認応答も受信されません。
最後のコメント: UDP は信頼性の低いトランスポート プロトコルです。UDP を使用する場合、アプリケーションはタイムアウトと再送信を管理します。個々のアプリケーションがそれをどの程度うまく処理するかには、多くのばらつきがあります。かなりひどいものもあります。(前方) エラー訂正は、少なくとも最も悪名高い信頼性の低い物理リンク層のいくつかによって提供されるため、少なくともその状況はその UDP で許容されますが、信頼性は低いものの、「通常は」機能します。一部の非 TCP、非 UDP トランスポート プロトコルについても同じことが言えます。
于 2013-03-11T00:29:17.660 に答える