0

UDP プロトコルは、パケットが連続して受信されることを保証しませんが、データグラムの一部をシーケンス番号として使用できます。

TCPの保証と比較して、UDPの上記のソリューションは同等ですか?

基本的に、UDP はシーケンシャル受信を提供しないことをどこでも読んできましたが、これは明らかな修正のように思えて、本当に適切な修正であるかどうか疑問に思っていました。

4

4 に答える 4

1

TCPとUDPの間で、部分的な信頼性の形式が必要なようです。

オプションは、SCTP-over-UDP ( SCTP、ポータブル ユーザー空間 & カーネルソース) を使用することです。SCTP を使用すると、信頼性の低い UDP のようなストリームや、部分的に信頼性の高いストリーム (限られた時間または再送信回数) に対して順序を設定できます。

于 2013-05-22T18:46:48.080 に答える
1

唯一の「欠点」は、数バイトのデータ領域が失われることです。

ただし、それ自体では解決策にはなりません。プロトコルに ACK メッセージを追加して、受信したものと受信していないものを送信者が認識できるようにする必要があります。送信されたデータグラムは、再送信する必要がある場合に備えて、ACK が返されるまで送信側でバッファリングする必要があります。また、シーケンス データグラムをバッファリングするか、それらを破棄して、シーケンスを正しく再構築できるようにする必要があります。ここまで来て、大量の再送信が必要であることに気付いた場合、送信者が何らかの形式のフロー制御またはペーシングを実装することも賢明です。

これは、TCP を実装するための良い方法です。ほとんどの人は、この時点であきらめて、TCP を使用します。

于 2013-05-23T00:08:28.920 に答える
1

この方法で UDP を使用すると、アプリケーションはパケットの再構築と順序付けを処理する必要があります。これにより、ネットワークのアプリケーション層にオーバーヘッドが生じます。トランスポート層でそれを処理するのは、おそらく TCP の方が効率的です。

また、UDP は失われたパケットを再送信するメカニズムを提供しません。シーケンス番号が 1 つスキップされたことにアプリケーションが気付いた場合、その意味にはあいまいさがあります。損失パケットまたは遅延パケットはありますか? アプリケーションはそれを検出でき、パケット番号参照を介してパケットを再送信するように要求できる必要があります。

つまり、順序保証された配信が必要な場合、TCP のオーバーヘッドには理由があります。

https://en.wikipedia.org/wiki/User_Datagram_Protocol

于 2013-05-22T18:33:13.247 に答える