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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ではコンピュータネットワークユーザーデータグラムプロトコルUDPは)の中心メンバーの一人であるインターネットプロトコルスイート。 UDPを使用すると、コンピューターアプリケーションはインターネットプロトコル(IP)ネットワーク上の他のホストにメッセージ(この場合はデータグラムと呼ばれます)を送信できます。通信チャネルまたはデータパスを設定するために、事前の通信は必要ありません

UDPは、最小限のプロトコルメカニズムを備えたシンプルなコネクションレス型通信モデルを使用します。 UDPは、データ整合性のチェックサムと、データグラムの送信元と宛先でさまざまな機能をアドレス指定するためのポート番号提供しますハンドシェイクダイアログがないため、ユーザーのプログラムが基盤となるネットワークの信頼性さらされます。配達、注文、または重複保護の保証はありません。ネットワークインターフェイスレベルでエラー訂正機能が必要な場合、アプリケーションは、この目的のために設計された伝送制御プロトコル(TCP)またはストリーム制御伝送プロトコル(SCTP)を使用できます

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

プロトコルはによって設計されましたデイビット・P・リード1980年に正式に定義されたRFC  768

属性

UDPは、RFC768に文書化されて いる単純なメッセージ指向のトランスポート層プロトコルですUDPはヘッダーとペイロードの整合性検証(チェックサムを介して)を提供しますが[2]、メッセージ配信の上位層プロトコル保証せず、UDP層は送信されたUDPメッセージの状態を保持しません。このため、UDPは信頼性の低いデータグラムプロトコルと呼ばれることもあります。[3]伝送の信頼性が必要な場合は、ユーザーのアプリケーションに実装する必要があります。

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

ポート

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

割り当て番号機関インターネット(IANA)は、3つの範囲にポート番号を分けています。[4]ポート番号0〜1023は、一般的なよく知られたサービスに使用されます。上のUnixライクなオペレーティングシステムで、これらのポートのいずれかを使用することは必要でスーパーユーザーの操作権限を。ポート番号1024〜49151は、IANA登録サービスに使用される登録ポートです。ポート49152〜65535は、特定のサービス用に正式に指定されていない動的ポートであり、任意の目的に使用できます。これらはエフェメラルポートとしても使用でき、ホスト上で実行されているソフトウェアが必要に応じて通信エンドポイントを動的に作成するために使用できます。[4]

UDPデータグラム構造

UDPデータグラムヘッダー
オフセット オクテット 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 長さ チェックサム

UDPデータグラムは、データグラムヘッダーデータセクションで構成されます。UDPデータグラムヘッダーは4つのフィールドで構成され、各フィールドは2バイト(16ビット)です。[1]データセクションはヘッダーの後に続き、アプリケーション用に運ばれるペイロードデータです。

チェックサムフィールド送信元ポートフィールドの使用は、IPv4ではオプションです(表のピンク色の背景)。IPv6では、送信元ポートフィールドのみがオプションです。

送信元ポート番号
このフィールドは、使用時に送信者のポートを識別し、必要に応じて応答するポートであると見なす必要があります。使用しない場合は、ゼロにする必要があります。ソースホストがクライアントの場合、ポート番号は一時的なポート番号である可能性があります。ソースホストがサーバーの場合、ポート番号は既知のポート番号である可能性があります[4]
宛先ポート番号
このフィールドは受信者のポートを識別し、必須です。送信元ポート番号と同様に、クライアントが宛先ホストである場合、ポート番号は一時的なポート番号である可能性が高く、宛先ホストがサーバーである場合、ポート番号は既知のポート番号である可能性があります。[4]
長さ
このフィールドは、UDPヘッダーとUDPデータの長さをバイト単位で指定します。最小の長さは、ヘッダーの長さである8バイトです。フィールドサイズは、UDPデータグラムの理論上の制限を65,535バイト(8バイトのヘッダー+ 65,527バイトのデータ)に設定します。ただし、基盤となるIPv4プロトコルによって課されるデータ長の実際の制限は65,507バイトです(65,535バイト-8バイトUDPヘッダー-20バイトIPヘッダー)。[5]
IPv6ジャンボグラムを使用すると、65,535バイトを超えるサイズのUDPデータグラムを持つことができます。[6] RFC  2675は、UDPヘッダーとUDPデータの長さが65,535より大きい場合、長さフィールドがゼロに設定されることを指定しています。
チェックサム
チェックサムフィールドは、ヘッダ及びデータのエラーチェックのために使用することができます。このフィールドは、IPv4ではオプションであり、IPv6では必須です。[7]未使用の場合、フィールドにはすべてゼロが含まれます。[8]

チェックサム計算

チェックサムを計算するために使用される方法は、で定義されているRFC  768、および効率的な計算は、に記載されているRFC  1071

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

つまり、16ビットワードはすべて、1の補数演算を使用して合計されます。16ビット値を加算します。追加するたびに、キャリーアウト(17番目のビット)が生成された場合は、その17番目のキャリービットを振り回して、現在の合計の最下位ビットに追加します。[9]最後に、合計が補完されて、UDPチェックサムフィールドの値が生成されます。

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

IPv4IPv6の違いは、チェックサムの計算に使用される疑似ヘッダーにあり、IPv6ではチェックサムはオプションではありません。[10]

IPv4疑似ヘッダー

UDPがIPv4で実行される場合、チェックサムは、実際のIPv4ヘッダーからの同じ情報の一部を含む「疑似ヘッダー」を使用して計算されます[8] :2  疑似ヘッダーは、IPパケットの送信に使用される実際のIPv4ヘッダーではなく、チェックサムの計算にのみ使用されます。

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 送信元IPv4アドレス
4 32 宛先IPv4アドレス
8 64 ゼロ プロトコル UDPの長さ
12 96 ソースポート 宛先ポート
16 128 長さ チェックサム
20 160歳以上 データ

送信元アドレスと宛先アドレスは、IPv4ヘッダーのアドレスです。プロトコルはUDP用のものです(IPプロトコル番号のリストを参照):17(0x11)。UDP長さフィールドは、UDPヘッダーとデータの長さです。フィールドデータは、送信されたデータを表します。

UDPチェックサム計算はIPv4ではオプションです。チェックサムを使用しない場合は、値をゼロに設定する必要があります。

IPv6疑似ヘッダー

UDPがIPv6で実行される場合、チェックサムは必須です。記載されているように、それを計算するために使用される方法が変更されたRFC  2460

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

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

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 送信元IPv6アドレス
4 32
8 64
12 96
16 128 宛先IPv6アドレス
20 160
24 192
28 224
32 256 UDPの長さ
36 288 ゼロ 次のヘッダー=プロトコル[11]
40 320 ソースポート 宛先ポート
44 352 長さ チェックサム
48 384+ データ

送信元アドレスは、IPv6ヘッダーにあるアドレスです。宛先アドレスは最終的な宛先です。IPv6パケットにルーティングヘッダーが含まれていない場合、それがIPv6ヘッダーの宛先アドレスになります。それ以外の場合、発信元ノードでは、ルーティングヘッダーの最後の要素のアドレスになり、受信ノードでは、IPv6ヘッダーの宛先アドレスになります。Next Headerフィールドの値は、UDPのプロトコル値です。17。UDPlengthフィールドは、UDPヘッダーとデータの長さです。

信頼性と輻輳制御

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

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

アプリケーション

多数の主要なインターネットアプリケーションがUDPを使用しています。これには、ドメインネームシステム(DNS)が含まれます。この場合、クエリは高速で、単一の要求とそれに続く単一の応答パケット、簡易ネットワーク管理プロトコル(SNMP)、ルーティング情報プロトコル( RIP)[1]および動的ホスト構成プロトコル(DHCP)。

音声およびビデオトラフィックは通常、UDPを使用して送信されます。リアルタイムのビデオおよびオーディオストリーミングプロトコルは、時折失われるパケットを処理するように設計されているため、失われたパケットが再送信された場合の大きな遅延ではなく、品質のわずかな低下のみが発生します。 TCPとUDPの両方が同じネットワーク上で実行されるため、多くの企業は、これらのリアルタイムアプリケーションからのUDPトラフィックの最近の増加が、販売時点会計データベースシステムなどのTCPを使用するアプリケーションのパフォーマンスを妨げていることに気づいています。 TCPはパケット損失を検出すると、データレートの使用を抑制します。リアルタイムアプリケーションとビジネスアプリケーションの両方がビジネスにとって重要であるため、高品質のサービス一部の人は重要だと見ています。[12]

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

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

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. ^ a b c 黒瀬、JF; ロス、KW(2010)。コンピューターネットワーキング:トップダウンアプローチ(第5版)。ボストン、マサチューセッツ州:ピアソン教育。ISBN  978-0-13-136548-3
  2. ^ クラーク、MP(2003)。データネットワークIPとインターネット、第1版イギリス、ウエストサセックス:John Wiley&Sons Ltd.
  3. ^ [email protected]「UDPプロトコルの概要」Ipv6.com 取得した17年8月2011
  4. ^ a b c d e Forouzan、BA(2000)。TCP / IP:プロトコルスイート、第1版インド、ニューデリー:Tata McGraw-Hill Publishing CompanyLimited。
  5. ^ スティーブンス、W。リチャード(1994)。TCP / IPの図解:プロトコル1(2版)。アディソン-ウェスリー。ISBN 978-0-20-163346-7
  6. ^ RFC  2675
  7. ^ a b Deering S.&Hinden R.(1998年12月)。「インターネットプロトコル、バージョン6(IPv6)仕様」インターネットエンジニアリングタスクフォースRFC 2460 
  8. ^ a b c d Postel、J。(1980年8月)。ユーザーデータグラムプロトコルインターネットエンジニアリングタスクフォース。土井10.17487 / RFC0768RFC 768
  9. ^ 「16ビットの1の補数の合計を計算する」mathforum.orgジョン。2002年3月20日。2020年11月17日のオリジナル電子メールからアーカイブ検索された5年11月2014
  10. ^ インターネットプロトコル、バージョン6(IPv6)仕様NS。27-28。土井10.17487 / RFC8200RFC 8200
  11. ^ Next Headerフィールドの値は、UDPのプロトコル値です
  12. ^ 「データアプリケーションに対するUDPの影響」Networkperformancedaily.com。2007年7月31日にオリジナルからアーカイブされまし取得した17年8月2011
  13. ^ 「QUIC、UDPを介した多重化されたストリームトランスポート」chromium.org 2021年2月17日取得

外部リンク