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

| ボディクラス = hlist

| 見出し1 =アプリケーション層 | コンテンツ1 =

• GP-BGP とは
• DHCP ( v6 )
• ドメイン名
• FTP
• HTTP  ( HTTP/3 )について
• 翻訳
• IMMAP について
• IRCC の
• LDAP の
• MGCP
• 翻訳
• NNTP
• NTPA の
• オペレーティングシステム
• ポップ
• PTTP
• ONC/RPC
• RTTP とは
• RTSP
• RIP
• SIP
• メール
• SNMP の
• パスワード
• テルネット
• TLS/SSL
• ウェブマスター
• もっと...

| 見出し2 =トランスポート層 | コンテンツ2 =

• 通信プロトコル
• UDPI
• DCCP
• SCTP
• お返事お願いします
• クイック
• もっと...

| 見出し3 =インターネット層 | コンテンツ3 =

• IP
  • v4
  • v6
• ICMP ( v6 )
• 新民主党
• 電子商取引ネットワーク
• IGMP
• IPsec
• もっと...

| 見出し4 =リンク層 | コンテンツ4 =

• ARP
• トンネル
• PPPP（官民パートナーシップ）
• マック
• もっと...

}}

コンピュータ ネットワークにおいて、ユーザー データグラム プロトコル( UDP ) は、インターネット プロトコル スイートのコア通信プロトコルの 1 つであり、インターネットプロトコル(IP) ネットワーク上の他のホストにメッセージ (パケット内のデータグラムとして転送) を送信するために使用されます。IP ネットワーク内では、UDP では通信チャネルやデータ パスを設定するための事前の通信は必要ありません。

UDPはコネクションレスプロトコルであり、メッセージは接続をネゴシエートせずに送信され、UDPは送信した内容を追跡しません。^{[1] [2]} UDPは、データの整合性を確保するためのチェックサムと、データグラムの送信元と送信先のさまざまな機能のアドレス指定に使用するポート番号を提供します。ハンドシェイクダイアログがないため、ユーザーのプログラムは基盤となるネットワークの信頼性の低さにさらされます。配信、順序、重複保護の保証はありません。ネットワークインターフェースレベルでエラー訂正機能が必要な場合、アプリケーションは代わりにこの目的のために設計された伝送制御プロトコル（TCP）またはストリーム制御伝送プロトコル（SCTP）を使用できます。

UDPは、エラーチェックやエラー訂正が不要であるか、アプリケーション内で実行される目的に適しています。UDPは、プロトコルスタック内でのそのような処理のオーバーヘッドを回避します。時間に敏感なアプリケーションでは、再送による遅延パケットを待つよりもパケットをドロップする方が望ましいため、UDPがよく使用されます。これは、リアルタイムシステムでは選択肢にならない場合があります。^[3]

このプロトコルは1980 年にDavid P. Reedによって設計され、 RFC  768 で正式に定義されました。

UDPは、 RFC 768に記載されているシンプルなメッセージ指向のトランスポート層プロトコルです。UDPはヘッダーとペイロードの整合性検証（チェックサム経由）を提供しますが、 ^[4]上位層プロトコルへのメッセージ配信の保証はなく、UDP層は送信されたUDPメッセージの状態を保持しません。このため、UDPは信頼性の低いデータグラムプロトコルと呼ばれることもあります。^[5]伝送の信頼性が必要な場合は、ユーザーのアプリケーションで実装する必要があります。

UDP の多くの属性により、UDP は特定のアプリケーションに特に適しています。

• これはトランザクション指向であり、ドメイン ネーム システムやネットワーク タイム プロトコルなどの単純なクエリ応答プロトコルに適しています。
• IP トンネリングやリモート プロシージャ コール、ネットワーク ファイル システムなどの他のプロトコルをモデル化するのに適したデータグラムを提供します。
• これはシンプルで、DHCPやTrivial File Transfer Protocolなどの完全なプロトコル スタックなしでブートストラップやその他の目的に適しています。
• これはステートレスであり、 IPTVなどのストリーミング メディアアプリケーションなど、非常に多数のクライアントに適しています。
• 再送信遅延がないため、 Voice over IP、オンライン ゲーム、Real Time Streaming Protocol を使用する多くのプロトコルなどのリアルタイム アプリケーションに適しています。
• マルチキャストをサポートしているため、 Precision Time ProtocolやRouting Information Protocolなどの多くのサービス検出や共有情報などのブロードキャスト情報に適しています。

アプリケーションは、データグラム ソケットを使用してホスト間通信を確立できます。アプリケーションは、ソケットをデータ転送のエンドポイント ( IP アドレスとポートの組み合わせ) にバインドします。このようにして、UDP はアプリケーションの多重化を実現します。ポートは、16 ビットの整数値であるポート番号によって識別されるソフトウェア構造で、ポート番号は 0 から 65535 までです。ポート 0 は予約されていますが、送信プロセスが応答メッセージを期待しない場合は、ソース ポート値として使用できます。

IANA ( Internet Assigned Numbers Authority ) はポート番号を 3 つの範囲に分けました。^[6]ポート番号 0 から 1023 は一般的なよく知られたサービスに使用されます。Unix系オペレーティングシステムでは、これらのポートを使用するにはスーパーユーザーの操作権限が必要です。 ポート番号 1024 から 49151 は、 IANA 登録サービスに使用される登録ポートです。 ポート 49152 から 65535 は動的ポートで、特定のサービス用に正式に指定されておらず、どのような目的でも使用できます。 これらは、ホスト上で実行されているソフトウェアが必要に応じて通信エンドポイントを動的に作成するために使用できる一時ポートとしても使用できます。^[6]

UDPデータグラムは、データグラムヘッダーとそれに続くデータセクション（アプリケーションのペイロードデータ）で構成されています。UDPデータグラムヘッダーは4つのフィールドで構成され、各フィールドは2バイト（16ビット）です。^[3]

チェックサムフィールドと送信元ポートフィールドの使用は、IPv4ではオプションです（表の背景は薄紫色）。IPv6では送信元ポートフィールドのみがオプションです。使用しない場合は、これらのフィールドをゼロに設定する必要があります。^[7]

送信元ポート: 16 ビット

このフィールドは、送信者のポートを識別し、必要に応じて返信するポートであると想定する必要があります。送信元ホストがクライアントの場合、ポート番号は一時的なポートである可能性があります。送信元ホストがサーバーの場合、ポート番号は0〜1023の既知のポート番号である可能性があります。 ^[6]

宛先ポート: 16 ビット

このフィールドは受信者のポート番号を識別するもので、必須です。送信元ポート番号と同様に、クライアントが宛先ホストである場合、ポート番号は一時的なポート番号になる可能性があり、宛先ホストがサーバーである場合、ポート番号は既知のポート番号になる可能性が高いです。^[6]

長さ: 16 ビット

このフィールドは、UDPデータグラム（ヘッダーフィールドとデータフィールド）の長さをオクテット単位で指定します。最小長はヘッダーの長さである8バイトです。このフィールドサイズは、UDPデータグラムの理論上の制限を65,535バイト（8バイトのヘッダー + 65,527バイトのデータ）に設定します。ただし、基礎となるIPv4プロトコルによって課せられるデータ長の実際の制限は、65,507バイト（65,535バイト − 8バイトのUDPヘッダー − 20バイトのIPヘッダー）です。^[8]

IPv6ジャンボグラムを使用すると、65,535バイトを超えるサイズのUDPデータグラムを作成できます。UDPヘッダーとUDPデータの長さが65,535を超える場合、長さフィールドはゼロに設定されます。^[9]

チェックサム: 16ビット

チェックサムフィールドは、ヘッダーとデータのエラーチェックに使用されることがあります。このフィールドはIPv4ではオプションですが、IPv6ではほとんどの場合必須です。^[10]

データ: 変数

UDP パケットのペイロード。

チェックサムを計算する方法はRFC 768 で定義されており、効率的な計算についてはRFC 1071 で説明されています。

チェックサムは、IPヘッダー、UDPヘッダー、およびデータからの情報の疑似ヘッダーの1の補数の合計の16ビットの補数であり、2オクテットの倍数になるように末尾にゼロオクテットが埋め込まれます（必要な場合）。^[7]

言い換えれば、16 ビットのワードはすべて 1 の補数演算を使用して合計されます。16 ビットの値を加算します。各加算でキャリーアウト (17 番目のビット) が生成された場合は、その 17 番目のキャリー ビットを回転させて、実行中の合計の最下位ビットに追加します。^[11]最後に、合計を 1 の補数で計算して、UDP チェックサム フィールドの値を生成します。

チェックサム計算の結果がゼロ（16ビットすべてが0）になった場合、ゼロ値のチェックサムはチェックサムが計算されていないことを示すため、1の補数（すべて1）として送信する必要があります。^[7]この場合、1の補数演算ではすべての0とすべての1はゼロに等しいため、受信側で特別な処理は必要ありません。

IPv4とIPv6の違いは、チェックサムを計算するために使用される疑似ヘッダーにあり、チェックサムはIPv6ではオプションではないことです。^[12]特定の条件下では、IPv6を使用するUDPアプリケーションは、トンネルプロトコルでゼロUDPゼロチェックサムモードを使用できます。^[13]

UDPがIPv4上で実行される場合、チェックサムは実際のIPv4ヘッダーと同じ情報の一部を含む疑似ヘッダーを使用して計算されます。^{[7] : 2} 疑似ヘッダーはIPパケットの送信に使用される実際のIPv4ヘッダーではなく、チェックサムの計算にのみ使用されます。UDPチェックサムの計算はIPv4ではオプションです。チェックサムを使用しない場合は、値0に設定する必要があります。

チェックサムは次のフィールドに対して計算されます。

送信元アドレス: 32 ビット

IPv4 ヘッダーからの送信元アドレス。

宛先アドレス: 32 ビット

IPv4 ヘッダーからの宛先アドレス。

ゼロ: 8 ビット; ゼロ == 0

すべてゼロです。

プロトコル: 8 ビット

UDP のプロトコル値: 17 (または0x11 )。

UDP 長さ: 16 ビット

UDP ヘッダーとデータの長さ (オクテット単位で測定)。

IPv6ではアドレスが大きく、ヘッダーレイアウトが異なるため、チェックサムを計算する方法もそれに応じて変更されます。^{[10] : §8.1}

チェックサム計算に IP ヘッダーのアドレスを含めるトランスポートまたはその他の上位層プロトコルは、IPv6 で使用するために、32 ビットの IPv4 アドレスではなく 128 ビットの IPv6 アドレスを含めるように変更する必要があります。

チェックサムを計算するときにも、実際のIPv6 ヘッダーを模倣した疑似ヘッダーが使用されます。

チェックサムは次のフィールドに対して計算されます。

送信元アドレス: 128 ビット

IPv6 ヘッダー内のアドレス。

宛先アドレス: 128 ビット

最終宛先。IPv6 パケットにルーティング ヘッダーが含まれていない場合、TCP は IPv6 ヘッダー内の宛先アドレスを使用します。それ以外の場合、発信元ノードではルーティング ヘッダーの最後の要素のアドレスを使用し、受信側ノードでは IPv6 ヘッダー内の宛先アドレスを使用します。

UDP 長さ: 32 ビット

UDP ヘッダーとデータの長さ (オクテット単位で測定)。

ゼロ: 24 ビット; ゼロ == 0

すべてゼロです。

次のヘッダー: 8 ビット

UDP のプロトコル値: 17。

信頼性に欠けるため、UDPアプリケーションではパケット損失、順序変更、エラー、重複が発生する場合があります。UDPを使用する場合、エンドユーザーアプリケーションは、メッセージが受信されたことのリアルタイム確認など、必要なハンドシェイクを提供する必要があります。TFTPなどのアプリケーションでは、必要に応じて基本的な信頼性メカニズムをアプリケーション層に追加できます。^{[6]アプリケーションに高度な信頼性が必要な場合は、代わりに}伝送制御プロトコルなどのプロトコルを使用できます。

ほとんどの場合、UDP アプリケーションは信頼性メカニズムを採用しておらず、信頼性メカニズムによって妨げられることさえあります。ストリーミング メディア、リアルタイム マルチプレイヤー ゲーム、 VoIP ( Voice over IP ) は、UDP を頻繁に使用するアプリケーションの例です。これらの特定のアプリケーションでは、パケットの損失は通常、致命的な問題ではありません。たとえば、VoIP では、遅延とジッターが主な懸念事項です。TCP を使用すると、パケットが失われるとジッターが発生します。これは、TCP は、失われたデータの再送信を要求している間、アプリケーションに後続のデータを提供しないためです。

UDPは、ドメインネームシステム（DNS）、簡易ネットワーク管理プロトコル（SNMP）、ルーティング情報プロトコル（RIP）^[3]、動的ホスト構成プロトコル（DHCP）など、数多くの主要なインターネットアプリケーションで使用されています。

音声とビデオのトラフィックは通常、UDP を使用して送信されます。リアルタイムのビデオおよびオーディオ ストリーミング プロトコルは、時折発生するパケット損失を処理するように設計されているため、損失パケットが再送信された場合に大きな遅延が発生するのではなく、品質がわずかに低下するだけです。TCP と UDP はどちらも同じネットワーク上で実行されるため、2000 年代半ばに、これらのリアルタイム アプリケーションからの UDP トラフィックの増加により、POS、会計、データベースシステムなどの TCP を使用するアプリケーションのパフォーマンスがわずかに低下することがいくつかの企業で確認されました (TCP はパケット損失を検出すると、データ レートの使用を抑制します)。^[14]

OpenVPNなどの一部のVPNシステムでは、信頼性の高い接続を実装しながら、UDP を使用し、アプリケーション レベルでエラー チェックを実行する場合があります。

QUICはUDPの上に構築されたトランスポートプロトコルです。QUICは信頼性とセキュリティの高い接続を提供します。HTTP /3は、信頼性とセキュリティを確保するためにTCPとTLSの組み合わせを使用する以前のバージョンのHTTPSとは対照的に、QUICを使用します。つまり、 HTTP /3はTCPとTLSの2つの別々のハンドシェイクを使用するのではなく、単一のハンドシェイクを使用して接続を確立するため、接続を確立するための全体的な時間が短縮されます。^[15]

伝送制御プロトコルは接続指向のプロトコルであり、エンドツーエンドの通信を確立するためにハンドシェイクが必要です。接続が確立されると、ユーザー データは接続を介して双方向に送信できます。

• 信頼性– TCP はメッセージの確認、再送信、タイムアウトを管理します。メッセージの配信は複数回試行されます。途中でデータが失われた場合、データは再送信されます。TCP では、データが失われることはなく、タイムアウトが複数回発生した場合は接続が切断されます。
• 順序付け– 2 つのメッセージが接続を介して順番に送信された場合、最初のメッセージが最初に受信アプリケーションに届きます。データ セグメントが間違った順序で到着すると、TCP は、すべてのデータが正しく並べ替えられてアプリケーションに配信されるまで、順序が乱れたデータをバッファリングします。
• ヘビーウェイト– TCP では、ユーザー データを送信する前にソケット接続を確立するために 3 つのパケットが必要です。TCP は信頼性と輻輳制御を処理します。
• ストリーミング- データはバイトストリームとして読み取られ、メッセージ (セグメント) 境界を通知するための識別表示は送信されません。

ユーザー データグラム プロトコルは、より単純なメッセージ ベースのコネクションレス プロトコルです。コネクションレス プロトコルは、専用のエンドツーエンド接続を確立しません。通信は、受信側の準備状況や状態を確認せずに、送信元から送信先へ一方向に情報を送信することで実現されます。

• 信頼性が低い– UDP メッセージを送信すると、そのメッセージが宛先に届くかどうかはわかりません。途中で失われる可能性もあります。確認応答、再送信、タイムアウトの概念はありません。
• 順序なし– 2 つのメッセージが同じ受信者に送信された場合、到着順序は保証されません。
• 軽量- メッセージの順序付けや接続の追跡などはありません。IP 上に設計された非常にシンプルなトランスポート層です。
• データグラム– パケットは個別に送信され、到着時に整合性がチェックされます。パケットには受信時に尊重される明確な境界があり、受信側ソケットでの読み取り操作により、最初に送信されたとおりのメッセージ全体が返されます。
• 輻輳制御なし– UDP 自体は輻輳を回避しません。輻輳制御対策は、アプリケーション レベルまたはネットワークで実装する必要があります。
• ブロードキャスト- UDP はコネクションレスなのでブロードキャストが可能 - 送信されたパケットはサブネット上のすべてのデバイスが受信できるようにアドレス指定できます。
• マルチキャスト- マルチキャスト モードの動作がサポートされており、単一のデータグラム パケットを重複することなく加入者のグループに自動的にルーティングできます。

• RFC 768 – ユーザー データグラム プロトコル
• RFC 2460 – インターネット プロトコル バージョン 6 (IPv6) 仕様
• RFC 2675 – IPv6 ジャンボグラム
• RFC 4113 – UDP の管理情報ベース
• RFC 8085 – UDP 使用ガイドライン

Wikiversityにはユーザーデータグラムプロトコルに関する学習リソースがあります

• IANA ポート割り当て
• UDP スキャンの問題点 (PDF)
• UDPフレームの内訳
• MSDN マガジンの UDP ソケットと WCF