UDPプロトコル |ユーザーデータグラムプロトコル

コンピュータネットワーキングにおいて、UDP は User Datagram Protocol の略です。 David P. Reed は 1980 年に UDP プロトコルを開発しました。UDP プロトコルは RFC 768 で定義されており、TCP/IP プロトコルの一部であるため、インターネット上の標準プロトコルです。 UDP プロトコルを使用すると、コンピュータアプリケーションは、インターネットプロトコル (IP) ネットワークを介して、あるマシンから別のマシンにデータグラムの形式でメッセージを送信できます。 UDP は、TCP プロトコル (伝送制御プロトコル) の代替通信プロトコルです。 TCP と同様に、UDP は、インターネット上でデータを交換する方法を管理する一連のルールを提供します。 UDP は、データをパケットにカプセル化し、独自のヘッダー情報をパケットに提供することによって機能します。次に、この UDP パケットは IP パケットにカプセル化され、宛先に送信されます。どちらも TCPとUDP プロトコルはインターネットプロトコルネットワーク経由でデータを送信するため、次のように呼ばれます。 TCP/IP および UDP/IP。これら 2 つのプロトコルには多くの違いがあります。 UDP はプロセスによる通信の処理を可能にし、TCP はホスト間の通信を提供します。 UDP はメッセージをデータグラムの形式で送信するため、通信のベストエフォートモードとみなされます。 TCP は個別のパケットを送信するため、信頼性の高いトランスポートメディアです。もう 1 つの違いは、TCP がコネクション型プロトコルであるのに対し、UDP はデータ転送に仮想回線を必要としないコネクションレス型プロトコルであることです。

また、UDP は、異なるユーザー要求を区別するために異なるポート番号を提供し、完全なデータが到着したかどうかを確認するチェックサム機能も提供します。 IP 層はこれら 2 つのサービスを提供しません。

UDPプロトコルの特徴

UDP プロトコルの特徴は次のとおりです。

トランスポート層プロトコル

UDP は最も単純なトランスポート層通信プロトコルです。最小限の通信メカニズムが含まれています。これは信頼性の低いプロトコルとみなされており、ベストエフォート型の配信サービスに基づいています。 UDP は確認応答メカニズムを提供しません。つまり、受信者は受信したパケットに対する確認応答を送信せず、送信者も送信したパケットに対する確認応答を待ちません。

コネクションレス型

UDP は、データを転送するための仮想パスを作成しないため、コネクションレス型プロトコルです。仮想パスを使用しないため、パケットは送信者と受信者の間で異なるパスで送信され、パケットの損失や受信順序の乱れが発生します。

データの順序どおりの配信は保証されません。

Javaで配列に追加する

UDP の場合、データグラムには番号が付けられていないため、データグラムはある順序で送信され、同じ順序で受信されるかどうかは保証されません。

ポート

UDP プロトコルは、データを正しい宛先に送信できるように、異なるポート番号を使用します。ポート番号は 0 ～ 1023 の間で定義されます。

より高速な伝送

UDP はコネクションレス型プロトコルであるため、より高速な送信を可能にします。つまり、データ転送に仮想パスは必要ありません。ただし、個々のパケットが失われる可能性があり、伝送品質に影響します。一方、TCP 接続でパケットが失われた場合、そのパケットは再送信されるため、データパケットの配信が保証されます。

確認メカニズム

UDP には確認応答メカニズムがありません。つまり、UDP 送信者と UDP 受信者の間にハンドシェイクはありません。メッセージが TCP で送信される場合、受信者は準備ができていることを確認し、送信者はデータを送信します。 TCP の場合、送信者と受信者の間でハンドシェイクが発生しますが、UDP では送信者と受信者の間でハンドシェイクが発生しません。

セグメントは独立して処理されます。

各 UDP セグメントは宛先に到達するまでに異なるパスを取るため、各 UDP セグメントは他のセグメントとは個別に処理されます。送信者と受信者の間に接続が設定されていないため、UDP セグメントが失われたり、宛先に到達する順序が狂って配信される可能性があります。

ステートレス

これはステートレスプロトコルであり、送信者が送信されたパケットに対する確認応答を取得しないことを意味します。

なぜ UDP プロトコルが必要なのでしょうか?

UDP は信頼性の低いプロトコルであることはわかっていますが、それでも場合によっては UDP プロトコルが必要です。 UDP は、パケットが実際のデータとともに大量の帯域幅を必要とする場合に導入されます。たとえば、ビデオストリーミングでは、数千のパケットを確認するのは面倒であり、多くの帯域幅を無駄にします。ビデオストリーミングの場合、一部のパケットの損失は問題を引き起こすことはなく、無視することもできます。

UDPヘッダー形式

UDP では、ヘッダーサイズは 8 バイト、パケットサイズは最大 65,535 バイトです。ただし、データを IP データグラムにカプセル化する必要があり、IP パケットのヘッダーサイズは 20 バイトになる可能性があるため、このパケットサイズは不可能です。したがって、UDP の最大値は 65,535 マイナス 20 になります。UDP パケットが伝送できるデータのサイズは、UDP パケットのヘッダーが 8 バイト、IP ヘッダーが 20 バイトとして、65,535 マイナス 28 になります。

UDP ヘッダーには 4 つのフィールドが含まれます。

送信元ポート番号:これは、どのポートがパケットを送信するかを識別する 16 ビットの情報です。宛先ポート番号:どのポートが情報を受け入れるかを識別します。これは、宛先マシン上のアプリケーションレベルのサービスを識別するために使用される 16 ビットの情報です。長さ：ヘッダーも含む UDP パケット全体の長さを指定する 16 ビットのフィールドです。ヘッダーのサイズは 8 バイトであるため、最小値は 8 バイトになります。チェックサム:これは 16 ビットのフィールドであり、オプションのフィールドです。送信中に情報が破損する可能性があるため、このチェックサムフィールドは情報が正確であるかどうかをチェックします。これはオプションのフィールドであり、チェックサムを書き込むかどうかはアプリケーションに依存することを意味します。チェックサムを書き込みたくない場合は、16 ビットすべてが 0 になります。それ以外の場合は、チェックサムを書き込みます。 UDP では、チェックサムフィールドはパケット全体、つまりヘッダーとデータ部分に適用されますが、IP では、チェックサムフィールドはヘッダーフィールドのみに適用されます。

UDPプロトコルにおけるキューイングの概念

UDP プロトコルでは、サーバーとクライアント上のさまざまなプロセスを区別するために番号が使用されます。 UDP が通信を処理するプロセスを提供することはわかっています。クライアントはサービスを必要とするプロセスを生成し、サーバーはサービスを提供するプロセスを生成します。キューは両方のプロセスで使用できます。つまり、プロセスごとに 2 つのキューがあります。最初のキューはメッセージを受信する受信キューで、2 番目のキューはメッセージを送信する送信キューです。キューはプロセスの実行中に機能します。プロセスが終了すると、キューも破棄されます。

UDP は、次のコンポーネントを利用して UDP パケットの送受信を処理します。

Androidのimessageゲーム

入力キュー:UDP パケットは、プロセスごとに一連のキューを使用します。入力モジュール:このモジュールは IP からユーザーデータグラムを取得し、同じポートの制御ブロックテーブルから情報を見つけます。ユーザーデータグラムと同じポートを持つエントリが制御ブロックテーブル内で見つかると、データがキューに入れられます。コントロールブロックモジュール:制御ブロックテーブルを管理します。制御ブロックテーブル:制御ブロックテーブルには、開いているポートのエントリが含まれています。出力モジュール:出力モジュールはユーザーデータグラムを作成して送信します。

いくつかのプロセスが UDP のサービスを使用したいと考えています。 UDP はプロセスを多重化および逆多重化し、複数のプロセスを単一のホスト上で実行できるようにします。

制限事項

信頼性の低い接続配信サービスを提供します。プロセス間通信を提供することを除き、IP サービスは提供しません。
UDP メッセージは、失われたり、遅延したり、重複したり、順序が狂ったりする可能性があります。
信頼性の高い輸送配送サービスは提供されません。確認応答やフロー制御メカニズムは提供されません。ただし、ある程度のエラー制御は可能です。

利点

最小限のオーバーヘッドが発生します。