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

ユーザーデータグラムプロトコル
通信プロトコル
略語UDPI
開発者デビッド・P・リード
導入1980
影響を受けたクイック
OSI層トランスポート層(4)
RFC(複数)RFC  768

| ボディクラス = hlist


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

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

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

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


}}

コンピュータ ネットワークにおいて、ユーザー データグラム プロトコル( 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 アドレスとポートの組み合わせ) にバインドします。このようにして、UDP はアプリケーションの多重化を実現します。ポートは、16 ビットの整数値であるポート番号によって識別されるソフトウェア構造で、ポート番号は 0 から 65535 までです。ポート 0 は予約されていますが、送信プロセスが応答メッセージを期待しない場合は、ソース ポート値として使用できます。

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

UDPデータグラム構造

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

UDPヘッダーフォーマット[7]
オフセット オクテット 0 1 2 3
オクテット 少し 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 送信元ポート 宛先ポート
4 32 長さ チェックサム
8 64 データ
12 96
⋮ ⋮

チェックサムフィールドと送信元ポートフィールドの使用は、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]

IPv4 疑似ヘッダー

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

チェックサム計算用の UDP 疑似ヘッダー (IPv4)
オフセット オクテット 0 1 2 3
オクテット 少し 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 送信元アドレス
4 32 宛先住所
8 64 ゼロ プロトコル UDP 長さ
12 96 送信元ポート 宛先ポート
16 128 長さ チェックサム
20 160 データ
24 192
⋮ ⋮

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

送信元アドレス: 32 ビット
IPv4 ヘッダーからの送信元アドレス。
宛先アドレス: 32 ビット
IPv4 ヘッダーからの宛先アドレス。
ゼロ: 8 ビット; ゼロ == 0
すべてゼロです。
プロトコル: 8 ビット
UDP のプロトコル値: 17 (または0x11 )。
UDP 長さ: 16 ビット
UDP ヘッダーとデータの長さ (オクテット単位で測定)。

IPv6 疑似ヘッダー

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

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

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

チェックサム計算用の UDP 疑似ヘッダー (IPv6)
オフセット オクテット 0 1 2 3
オクテット 少し 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 送信元アドレス
4 32
8 64
12 96
16 128 宛先住所
20 160
24 192
28 224
32 256 UDPの長さ
36 288 ゼロ 次のヘッダー（=プロトコル）
40 320 送信元ポート 宛先ポート
44 352 長さ チェックサム
48 384 データ
52 416
⋮ ⋮

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

送信元アドレス: 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]

UDPとTCPの比較

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

  • 信頼性– 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 使用ガイドライン

参照

参考文献

  1. ^ ネットワークセールスおよびサービスハンドブック。2003年。ISBN 9781587050909。
  2. ^ Windows コマンドライン: Windows 8.1、Windows Server 2012、Windows Server 2012 R2 のパーソナルトレーナー。2015 年。ISBN 9781627164139。
  3. ^ abc 黒瀬, JF; ロス, KW (2010).コンピュータネットワーキング: トップダウンアプローチ(第5版). ボストン, MA: ピアソンエデュケーション. ISBN  978-0-13-136548-3。
  4. ^ Clark, MP (2003).データネットワーク IP とインターネット、第 1 版。ウェストサセックス、イングランド: John Wiley & Sons Ltd.
  5. ^ [email protected] (2006 年 8 月 15 日). 「UDP プロトコルの概要」. Ipv6.com . 2011 年8 月 17 日閲覧。{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)
  6. ^ abcde Forouzan, BA (2000). TCP/IP: プロトコル スイート、第 1 版。インド、ニューデリー: Tata McGraw-Hill Publishing Company Limited。
  7. ^ abcde J. Postel編 (1980 年 8 月 28 日). ユーザー データグラム プロトコル. IETF . doi : 10.17487/RFC0768 . STD 6. RFC 768. インターネット標準6。
  8. ^ Stevens, W. Richard (1994). TCP/IP Illustrated: The protocols . 第 1 巻 (第 2 版). Addison-Wesley. ISBN 978-0-20-163346-7。
  9. ^ D. Borman、S. Deering、R. Hinden (1999 年 8 月)。IPv6 Jumbograms。ネットワーク ワーキング グループ。doi : 10.17487 / RFC2675。RFC 2675 。 提案された標準。 RFC 2147 は 廃止されます。
  10. ^ ab S. Deering ; R. Hinden (2017 年 7 月). インターネット プロトコル バージョン 6 (IPv6) 仕様。IETF。doi : 10.17487 / RFC8200。STD 86。RFC 8200。 インターネット標準 86。RFC 2460 は 廃止されます。
  11. ^ 「16ビットの1の補数の合計を計算する」。mathforum.org 。ジョン。2002年3月20日。 2020年11月17日時点のオリジナル（メール）からアーカイブ。 2014年11月5日閲覧。
  12. ^インターネットプロトコルバージョン6 ( IPv6) 仕様。p. 27-28。doi : 10.17487/ RFC8200。RFC 8200 。
  13. ^ インターネットプロトコルバージョン6 (IPv6) 仕様。p. 23。doi : 10.17487 / RFC8085。RFC 8085 。
  14. ^ 「UDP がデータ アプリケーションに与える影響」 Networkperformancedaily.com。2007 年 7 月 31 日時点のオリジナルよりアーカイブ。2011年8 月 17 日閲覧。
  15. ^ 「QUIC、UDP 上の多重化ストリームトランスポート」chromium.org . 2021 年2 月 17 日閲覧。
Wikiversityにはユーザーデータグラムプロトコルに関する学習リソースがあります
  • IANA ポート割り当て
  • UDP スキャンの問題点 (PDF)
  • UDPフレームの内訳
  • MSDN マガジンの UDP ソケットと WCF
「https://en.wikipedia.org/w/index.php?title=User_Datagram_Protocol&oldid=1246342016」から取得