UDP プロトコルは、パケットが連続して受信されることを保証しませんが、データグラムの一部をシーケンス番号として使用できます。
TCPの保証と比較して、UDPの上記のソリューションは同等ですか?
基本的に、UDP はシーケンシャル受信を提供しないことをどこでも読んできましたが、これは明らかな修正のように思えて、本当に適切な修正であるかどうか疑問に思っていました。
UDP プロトコルは、パケットが連続して受信されることを保証しませんが、データグラムの一部をシーケンス番号として使用できます。
TCPの保証と比較して、UDPの上記のソリューションは同等ですか?
基本的に、UDP はシーケンシャル受信を提供しないことをどこでも読んできましたが、これは明らかな修正のように思えて、本当に適切な修正であるかどうか疑問に思っていました。
唯一の「欠点」は、数バイトのデータ領域が失われることです。
ただし、それ自体では解決策にはなりません。プロトコルに ACK メッセージを追加して、受信したものと受信していないものを送信者が認識できるようにする必要があります。送信されたデータグラムは、再送信する必要がある場合に備えて、ACK が返されるまで送信側でバッファリングする必要があります。また、シーケンス データグラムをバッファリングするか、それらを破棄して、シーケンスを正しく再構築できるようにする必要があります。ここまで来て、大量の再送信が必要であることに気付いた場合、送信者が何らかの形式のフロー制御またはペーシングを実装することも賢明です。
これは、TCP を実装するための良い方法です。ほとんどの人は、この時点であきらめて、TCP を使用します。
この方法で UDP を使用すると、アプリケーションはパケットの再構築と順序付けを処理する必要があります。これにより、ネットワークのアプリケーション層にオーバーヘッドが生じます。トランスポート層でそれを処理するのは、おそらく TCP の方が効率的です。
また、UDP は失われたパケットを再送信するメカニズムを提供しません。シーケンス番号が 1 つスキップされたことにアプリケーションが気付いた場合、その意味にはあいまいさがあります。損失パケットまたは遅延パケットはありますか? アプリケーションはそれを検出でき、パケット番号参照を介してパケットを再送信するように要求できる必要があります。
つまり、順序保証された配信が必要な場合、TCP のオーバーヘッドには理由があります。