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

ユーザーデータグラムプロトコル
通信プロトコル
略語UDP
開発者デビッド・P・リード
導入1980
影響を受けたQUIC、UDP-Lite
OSI層トランスポート層（4）
IP番号17
RFC(s)768
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

コンピュータネットワークにおいて、ユーザーデータグラムプロトコル（UDP ）は、インターネットプロトコルスイートの中核となる通信プロトコルの一つであり、インターネットプロトコル（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]
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00送信元ポート宛先ポート
432長さチェックサム
864データ
1296
⋮⋮

IPv4では、チェックサムフィールドと送信元ポートフィールドの使用は任意です（表の背景は薄紫色）。IPv6では、送信元ポートフィールドのみが任意です。使用しない場合は、これらのフィールドは0に設定する必要があります。[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バイトを超える場合、長さフィールドは0に設定されます。[9]
チェックサム：16ビット
チェックサムフィールドは、ヘッダーとデータのエラーチェックに使用される場合があります。このフィールドはIPv4ではオプションですが、IPv6ではほとんどの場合必須です。[10]
データ: 変数
UDP パケットのペイロード。

チェックサム計算

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

チェックサムは、IPヘッダー、UDPヘッダー、およびデータからの情報の疑似ヘッダーの16ビットの1の補数の合計の1の補数であり、必要に応じて末尾にゼロオクテットが埋め込まれ、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）
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00送信元アドレス
432宛先アドレス
864ゼロプロトコルUDPの長さ
1296送信元ポート宛先ポート
16128長さチェックサム
20160データ
24192
⋮⋮

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

送信元アドレス: 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）
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00送信元アドレス
432
864
1296
16128宛先アドレス
20160
24192
28224
32256UDPの長さ
36288ゼロ (0)次のヘッダー (17)
40320送信元ポート宛先ポート
44352長さチェックサム
48384データ
52416
⋮⋮

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

送信元アドレス: 128ビット
IPv6 ヘッダー内のアドレス。
宛先アドレス: 128ビット
最終宛先。IPv6 パケットにルーティング ヘッダーが含まれていない場合、TCP は IPv6 ヘッダー内の宛先アドレスを使用します。それ以外の場合、発信元ノードではルーティング ヘッダーの最後の要素内のアドレスを使用し、受信ノードでは IPv6 ヘッダー内の宛先アドレスを使用します。
UDPの長さ: 32ビット
UDP ヘッダーとデータの長さ (オクテット単位で測定)。
ゼロ: 24 ビット; ゼロ == 0
すべてゼロです。
次のヘッダー: 8ビット
UDP のトランスポート層プロトコル値: 17。

信頼性と輻輳制御

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

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

アプリケーション

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

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

OpenVPNなどの一部のVPNシステムでは、UDPを使用し、アプリケーションレベルでエラーチェックを行いながら信頼性の高い接続を実現します。WireGuardはUDPを使用し、エラーチェックを行いますが、信頼性の保証は提供せず、カプセル化されたプロトコルで処理することになります。

QUICはUDPをベースに構築されたトランスポートプロトコルです。QUICは信頼性とセキュリティに優れた接続を提供します。HTTP /3では、信頼性とセキュリティを確保するためにTCPとTLSを組み合わせて使用​​していた以前のHTTPSとは異なり、QUICを使用します。つまり、HTTP/3ではTCPとTLSの2つの別々のハンドシェイクではなく、1つのハンドシェイクで接続を確立するため、接続確立にかかる時間が全体的に短縮されます。[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. ^ Castelli, Matthew J. (2003).ネットワークセールスおよびサービスハンドブック. Cisco Press. ISBN 9781587050909。
  2. ^ Stanek, William (2015). Windows コマンドライン: Windows 8.1、Windows Server 2012、Windows Server 2012 R2 のパーソナルトレーナー. Stanek & Associates. ISBN 9781627164139。
  3. ^ abc 黒瀬, JF; ロス, KW (2010).コンピュータネットワーキング：トップダウンアプローチ（第5版）. ボストン, マサチューセッツ州: ピアソン・エデュケーション. 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. 2012年7月10日時点のオリジナルよりアーカイブ。2011年8月17日閲覧。{{cite web}}: CS1 maint: numeric names: authors list (link)
  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. Network Working Group. doi : 10.17487/RFC2675 . RFC 2675. 提案された標準。RFC 2147 を廃止します。
  10. ^ ab S. Deering ; R. Hinden (2017年7月). インターネットプロトコルバージョン6（IPv6）仕様.インターネット技術タスクフォース. doi : 10.17487/RFC8200 . STD 86. RFC 8200. インターネット標準 86。RFC 2460 は廃止されます。
  11. ^ 「16ビットの1の補数の合計を計算する」mathforum.org . John. 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日閲覧。
ウィキバーシティにはユーザーデータグラムプロトコルに関する学習リソースがあります
  • IANA ポート割り当て
  • UDP スキャンの問題点 (PDF)
  • UDPフレームの内訳 2009年1月22日アーカイブWayback Machine
  • MSDN マガジンの UDP、ソケット、WCF
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_Datagram_Protocol&oldid=1327434722#IPv6PH"