UDPデータグラム(ユーディーピーデータグラム)とは | 意味や読み方など丁寧でわかりやすい用語解説

UDPデータグラムとは、インターネットプロトコルスイートにおけるトランスポート層のプロトコルであるUser Datagram Protocol (UDP) によって送受信されるデータの最小単位を指す。データグラムという用語は、ネットワーク上で独立してルーティングされる自己完結型のデータ単位を意味し、各データグラムは、それ自身で必要な情報（送信元、宛先など）をすべて持ち、他のデータグラムとの関連性を事前に確立することなく単独で送信される。これは、通信を開始する前に送信側と受信側の間で論理的な接続（コネクション）を確立するTransmission Control Protocol (TCP) とは対照的なアプローチである。

UDPデータグラムの最も顕著な特徴は、そのシンプルさと、それに伴う高速性にある。TCPが通信の信頼性を確保するために、データの再送、順序の保証、フロー制御、輻輳制御など、多くの複雑なメカニズムを持つ一方、UDPはこれらの信頼性に関する機能は一切提供しない。このため、UDPデータグラムはTCPデータに比べて非常に小さなヘッダ情報を持ち、ネットワーク上での処理オーバーヘッドが少なく、迅速にデータを送受信できる。システムエンジニアを目指す上で、このTCPとUDPの根本的な違いを理解することは、ネットワークアプリケーション設計の基礎となる。

UDPデータグラムの構造は極めて単純であり、8バイトの固定長ヘッダと、それに続くユーザーデータ（ペイロード）から構成される。このヘッダは以下の4つのフィールドを持つ。

1. 送信元ポート番号（Source Port Number）: 2バイトのフィールドで、データを送信したアプリケーションのプロセスを識別するポート番号を示す。これにより、受信側のオペレーティングシステムは、どのアプリケーションに受信データを渡すべきかを特定できる。
2. 宛先ポート番号（Destination Port Number）: 2バイトのフィールドで、データを受信するアプリケーションのプロセスを識別するポート番号を示す。特定のサービス（例: DNSのポート53、NTPのポート123など）は、一般的に特定のポート番号を使用する。
3. UDP長（UDP Length）: 2バイトのフィールドで、UDPヘッダ（8バイト）を含むデータグラム全体の長さをバイト単位で示す。この値は常に8バイト以上である。
4. チェックサム（Checksum）: 2バイトのフィールドで、データグラムの内容が転送中に破損していないかを検出するための値である。送信側で計算されたチェックサムを受信側でも計算し、両者が一致しない場合はデータにエラーが発生したと判断できる。ただし、このチェックサムの計算はオプションであり、アプリケーションによっては省略されることもある。また、エラーが検出されたとしても、UDPプロトコル自身はデータの再送などのエラー回復処理は行わず、単にエラーをアプリケーションに通知するだけである。

これらのヘッダ情報が示す通り、UDPデータグラムは「誰が」「誰に」「どれくらいの長さのデータを」「データに破損がないか（オプション）」という最低限の情報のみを持つ。

UDPデータグラムが採用する「コネクションレス型」の通信モデルは、データ送信に先立つ接続確立のプロセス（TCPの3ウェイハンドシェイクのような手順）が不要であることを意味する。送信側は、単に宛先IPアドレスとポート番号を指定し、データグラムをネットワークに送り出す。この特性により、接続確立にかかる時間やリソースが不要となり、リアルタイム性が極めて重要な通信において有利に働く。

しかし、このシンプルさの裏返しとして、UDPデータグラムには「信頼性の欠如」という特徴がある。具体的には、UDPは以下の信頼性に関する保証を一切提供しない。

• 到達保証（Delivery Guarantee）: 送信されたUDPデータグラムが必ず受信側に届くという保証はない。ネットワークの混雑、ルーターの負荷、通信路の障害などにより、データグラムが途中で失われる「パケットロス」が発生する可能性がある。
• 順序保証（Ordering Guarantee）: 複数のUDPデータグラムを送信した場合でも、それらが送信されたのと同じ順序で受信される保証はない。ネットワーク上の異なる経路を通ることで、データグラムの到着順序が入れ替わる可能性がある。
• 重複排除（Duplication Elimination）: 同じUDPデータグラムがネットワーク障害や再送試行（アプリケーション層での）によって複数回受信側に届く可能性がある。UDPプロトコル自身は重複したデータグラムを検出し、破棄する機能を持たない。
• 輻輳制御（Congestion Control）: ネットワークが混雑している状況下でも、UDPは送信レートを自動的に調整する機能を持たない。このため、大量のUDPデータグラムを送信し続けると、ネットワークの混雑をさらに悪化させ、パケットロスを増加させる可能性がある。

これらの特性から、UDPデータグラムは、データの信頼性よりもリアルタイム性や通信の低遅延、または最小限のプロトコルオーバーヘッドが重視されるアプリケーションで特に有効である。例えば、リアルタイム音声通話（VoIP）やビデオストリーミング、オンラインマルチプレイヤーゲームなどでは、多少のデータロスが発生しても、通信の遅延を最小限に抑え、途切れない体験を提供することが優先される。失われたフレームを再送して遅延を発生させるよりも、新しいデータを迅速に届ける方がユーザー体験が向上する場合が多い。

また、Domain Name System (DNS) のクエリのように、短いリクエストとレスポンスで完結する通信、Simple Network Management Protocol (SNMP) のようなネットワーク機器の監視、Network Time Protocol (NTP) のような時刻同期プロトコルでもUDPデータグラムが広く利用される。これらのプロトコルは、リクエストが単一のデータグラムで完結し、もし失われても簡単に再送できる性質を持つため、TCPのコネクション確立・切断にかかるオーバーヘッドを避ける利点が大きい。さらに、ブロードキャスト通信やマルチキャスト通信のように、不特定多数のデバイスに対して同時にデータを一斉送信するような場合にも、コネクションを確立する必要のないUDPが適している。

UDPデータグラムを使用するアプリケーションを設計する際には、UDPが提供しない信頼性に関する機能を、アプリケーション層で独自に実装する必要がある。例えば、重要なデータグラムが失われた場合に再送を要求するメカニズム、データグラムにシーケンス番号を付与して順序を保証するメカニズム、重複したデータグラムを破棄するメカニズムなどが挙げられる。システムエンジニアとしては、UDPデータグラムのこれらの特性を深く理解し、アプリケーションの要件に応じて適切なトランスポートプロトコルを選択する、あるいはUDP上に独自の信頼性層を構築する判断が求められる。