UDP｜コンピュータネットワーク

🎓 レベル：基礎　|　重要度：A（必須） 📎 前提：TCP（3ウェイ・再送・フロー制御）

要点（BLUF）

UDPはコネクションを張らず、確認応答も再送もしない最小限のトランスポートです。ヘッダはわずか8バイト。
信頼性をアプリ側に委ねる代わりに、**低遅延・低オーバーヘッド・1対多（マルチキャスト/ブロードキャスト）**が得意です。
「届かなくてもいいから速く・軽く」が要るDNS・DHCP・音声/映像・ゲームで使われます。

UDPは何をしないか

TCPが提供する機能のうち、UDPが省くものを並べると性格が分かります。

機能	TCP	UDP
コネクション確立	あり（3ウェイ）	なし
順序保証	あり	なし
再送・確認応答	あり	なし
フロー/輻輳制御	あり	なし
ヘッダ長	20バイト〜	8バイト
1対多	不可	可（マルチキャスト等）

UDPヘッダは送信元ポート・宛先ポート・長さ・チェックサムだけ。チェックサムで壊れを検出はしますが、壊れていたら黙って捨てるだけで再送はしません。

graph LR
  A["送信アプリ"]
  B["UDP：ポートを付けて即送信"]
  C["IP：ベストエフォートで配送"]
  A --> B --> C

なぜ「信頼性なし」を選ぶのか（設計の直観）

リアルタイム音声を考えます。0.5秒前の音声パケットが今ごろ再送で届いても、もう再生時刻は過ぎていて無価値です。遅れて正しいより、欠けても今すぐの方が価値が高い。TCPの再送・順序保証はこういう用途ではむしろ害になります。だからUDPは「最低限だけやって、必要な信頼性はアプリが自分の都合で実装する」という割り切りをします。実際、HTTP/3はUDP上にQUICで独自の信頼性と多重化を載せ、TCPの制約（先頭ブロッキング等）を回避しています。

代表的な用途

DNS：1往復で済む小さな問い合わせ。コネクション確立の往復が無駄なのでUDP（大きな応答はTCPにフォールバック）。
DHCP：まだIPが無い段階でブロードキャストする必要があり、コネクションを張れない。
音声/映像（VoIP・ストリーミングの一部）：低遅延優先。欠落は補間でごまかす。
オンラインゲーム：最新状態が重要で、古い情報の再送は不要。

TCPとUDPの選び方

graph TD
  Q["この通信に必要なのは?"]
  Q -->|"完全性・順序が必須（ファイル・Web・メール）"| T["TCP"]
  Q -->|"低遅延・1対多・小さな問い合わせ"| U["UDP"]

「壊れたら困るか、遅れたら困るか」で分けるのが実務の判断軸です。

⚠️ よくある誤解

「UDPは信頼性がゼロで使い物にならない」ではない。チェックサムで破損検出はします。必要な信頼性はアプリ層（QUICやアプリ独自の再送）で足せます。
「UDPは常にTCPより速い」ではない。輻輳制御がないため、混雑時に無秩序に送ると逆に損失が増え遅くなることも。速さは状況次第です。
「DNSは必ずUDP」ではない。応答が大きいときやゾーン転送はTCPを使います。

対応 lab

なし（概念回。ポート多重化の観察は次トピックのlabで）