WEB PROTOCOL
UDP（User Datagram Protocol）
コネクションレスのトランスポートプロトコル。ハンドシェイクなし、確認応答なしの高速通信
解説
📌UDPとは
UDP（User Datagram Protocol）は、コネクションレスで軽量なトランスポート層プロトコルです。TCPのようなハンドシェイクや確認応答を省略し、データをそのまま送信します。はがきに例えてみましょう。宛先を書いて投函するだけ。届いたかどうかの確認はしない。速達でもなく、届く保証もないが、切手を貼って投函するだけなので圧倒的にシンプルで速い。一方TCPは書留郵便のようなもので、受取確認が返ってくるまで追跡し続けます。
なぜ重要か：リアルタイム通信（Zoom、オンラインゲーム、動画ストリーミング）では、TCPの信頼性保証（再送、順序保証）がかえって邪魔になります。1秒前のフレームを再送するより、今のフレームを送る方が重要。だからUDPが選ばれます。DNS、NTP、DHCPなど、小さなデータを高速にやり取りするプロトコルもUDPを使います。クエリとレスポンスがそれぞれ1パケットで完結するため、TCPのハンドシェイクは無駄になります。上のツールで「基本フロー」シナリオを再生すると、ハンドシェイクなしで即座にデータが送信される様子が確認できます。TCPの3ウェイハンドシェイクと比較してみてください。
📌特徴
- ⚡コネクションレス：TCPのような事前のハンドシェイク（SYN→SYN-ACK→ACK）が不要。送りたいデータがあればすぐにデータグラムとして送信できる。接続の確立・維持・終了のオーバーヘッドがゼロ。上のツールで「TCP vs UDP比較」シナリオを再生すると、TCPが3往復必要なところUDPは即送信できることが確認できます。
- 🚫確認応答なし：データグラムを送信しても、相手が受け取ったかどうかの確認（ACK）を待たない。TCPでは毎回ACKを待つため遅延が発生するが、UDPではその遅延がない。ただし、パケットが失われても気づかない。上のツールで「パケットロス」シナリオでこの動作を確認できます。
- 📦軽量ヘッダー：UDPヘッダーはわずか8バイト（送信元ポート/宛先ポート/長さ/チェックサム）。TCPヘッダーの20バイト（+オプション最大40バイト）と比べて極めて軽い。通信のオーバーヘッドが小さいため、小さなデータの送受信に最適。
- 🎮リアルタイム向き：動画のフレームやゲームの座標データなど、「古いデータより新しいデータが重要」な通信に最適。パケットが失われても再送せず、次のデータを優先する。Zoom、Discord、Fortniteなどがこの特性を活用している。上のツールで「リアルタイム通信」シナリオで確認できます。
📌ユースケース
💬 Zoom（ビデオ会議）
音声・映像のリアルタイム転送にUDP（RTP over UDP）を使用。パケットが1つ失われても「少しノイズが入る」だけで、TCPのように再送を待って映像が固まることがない。WebRTCの基盤もUDP。
🎮 Fortnite/Apex（オンラインゲーム）
プレイヤーの位置・操作をUDPで毎フレーム送信。遅延が1msでも増えるとゲーム体験が劣化するため、TCPの再送は許容できない。ロスしたパケットは次のフレームで上書きされる。
🔍 DNS（名前解決）
ドメイン名→IPアドレスの変換はUDPポート53で行われる。クエリとレスポンスがそれぞれ1パケットで完結するため、TCPのハンドシェイクは無駄。512バイト以下のDNS応答はすべてUDP。
📺 Netflix（動画ストリーミング）
近年はQUIC（UDP上で動作）を採用。従来のTCPベースストリーミングでは、パケットロス時にバッファリング（再生が止まる）が発生していたが、UDPベースのQUICでストリームごとの独立性を実現。
📌用語解説
データグラム
= UDPのデータ単位
= UDPのデータ単位
TCPの「セグメント」に対してUDPは「データグラム」と呼びます。UDPヘッダー（8バイト）+ ペイロード（データ）で構成されます。各データグラムは独立して処理され、前後のデータグラムとの関連は保持されません。
ポート番号
= アプリケーション識別子
= アプリケーション識別子
送信元と宛先のアプリケーションを識別する16ビットの数値（0-65535）。DNS=53、DHCP=67/68、NTP=123、RTP=動的。TCPとUDPは別々のポート空間を持つため、TCPの80番とUDPの80番は別のサービスです。
チェックサム
= エラー検出値
= エラー検出値
データの誤りを検出するための値。UDPヘッダーの末尾に含まれます。IPv4ではオプション（省略可）、IPv6では必須。チェックサムでエラーが検出されたデータグラムは破棄されます（修正はしない）。
コネクションレス
= 事前接続不要
= 事前接続不要
通信前の接続確立手順が不要。送信側はいきなりデータグラムを送信し、受信側は届いたデータグラムを処理します。TCPの「接続状態」のような管理が不要なため、サーバーのリソース消費が少ない。
ベストエフォート配送
= 保証なし配送
= 保証なし配送
「最善を尽くすが保証はしない」という配送モデル。パケットの到着、順序、重複排除は保証されません。信頼性が必要な場合はアプリケーション層で独自に実装します（例: QUICはUDP上にTCPの信頼性を構築）。
UDPヘッダー
= 8バイト固定長
= 8バイト固定長
わずか8バイトの固定長ヘッダー。送信元ポート(2B)+宛先ポート(2B)+長さ(2B)+チェックサム(2B)。TCPの20-60バイトヘッダーと比べて極めてコンパクト。
📌UDP通信の手順
UDP通信に必要な3つのステップを追いかけます。TCPの複雑な手順と比べて圧倒的にシンプルです。
1
データグラム生成
アプリケーションデータにUDPヘッダー（送信元ポート、宛先ポート、長さ、チェックサム）を付加。TCPと異なり、接続確立の前処理は一切不要。socket()→sendto()の2ステップでデータを送信できます。
2
ネットワーク転送
データグラムはIPパケットに包まれてネットワークに送出されます。各ルーターがIPアドレスを見てルーティング。パケットの到着確認や再送は行われません。
3
受信処理
受信側はデータグラムのチェックサムを検証し、宛先ポート番号に対応するアプリケーションにデータを渡します。ロストしたデータグラムは検知されず、受信側に通知もされません。
上のツールで「基本フロー」シナリオを再生すると、ハンドシェイクなしの即座の送信→受信の流れが確認できます。
📌TCP vs UDP 比較
TCP
- -コネクション型。3ウェイハンドシェイクで接続確立
- -順序保証 + 再送制御でデータの信頼性を担保
- -ヘッダー20-60バイト
- -HTTP/HTTPS、メール、ファイル転送に最適
- -「確実に届く」が最優先の用途
UDP
- -コネクションレス。ハンドシェイク不要で即送信
- -順序保証なし、再送なし
- -ヘッダー8バイト
- -DNS、動画配信、ゲーム、VoIPに最適
- -「速さ」が最優先の用途
使い分けの指針
→データが確実に届く必要があるか？ TCP （Webページ、API、データベース）
→リアルタイム性が重要か？ UDP （動画、音声、ゲーム）
→小さなデータの高速応答か？ UDP （DNS、NTP、DHCP）
上のツールで「TCP vs UDP比較」シナリオを再生すると、同じデータを送る場合のパケット数と遅延の違いが視覚的に確認できます。
