コンピューターサイエンス：アルゴリズム / OS / ネットワーク / DB

UDP の用途 (DNS / 動画 / ゲーム)

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

UDP の用途 (DNS / 動画 / ゲーム)

このレッスンで分かること

  • UDP は DNS、ビデオ会議、ゲーム、IoT、QUIC/HTTP3 など「リアルタイム性 > 信頼性」の場面で活躍します
  • コーデックの誤り耐性や、コネクション維持コストを払わない設計とよく噛み合います
  • QUIC の登場で UDP は「現代 Web の最前線」に返り咲き、HTTP/3 の土台として再評価されました

UDP の用途 とは

TCP より UDP が選ばれる代表的な用途とその理由を学びます。本レッスンでは、UDP の用途 の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

この章のポイント

UDP が選ばれる場面 (要約)

  • 単発リクエスト型 = DNS、SNMP (短いやりとり、再送はアプリ層で OK)
  • リアルタイム性 > 信頼性 = ビデオ会議、ライブ配信、オンラインゲーム (遅延より「今届く」)
  • 低リソース端末 = IoT センサー (CoAP)
  • モダンプロトコルの基盤 = QUIC / HTTP/3 が UDP を土台に独自再送・暗号化を実装

TCP / UDP どちらを使うか判断早見表

要件推奨理由
ファイル転送、API 通信TCP信頼性が必須
DNS 問い合わせUDP短い往復 + 再試行可能
ビデオ会議・ライブ配信UDP遅延 > 再送、コーデックが補完
FPS / MOBA ゲームUDPレイテンシ最優先
IoT (温度、位置センサー)UDP (CoAP)端末リソース節約
最新 Web (HTTP/3)UDP (QUIC)多重化 + HoL Blocking 解消
メール送信 (SMTP)TCP確実な配送が必須

このレッスンで学ぶこと

UDP が選ばれる代表的な用途を見ながら、「なぜそこで TCP ではなく UDP なのか」の判断軸を身につけます。

DNS と UDP

DNS の問い合わせはほぼ UDP の 53 番ポートで行われます。理由はシンプルです。

  • 1 リクエスト = 1 レスポンスで完結する短いやりとり
  • 失敗したらアプリ側で再試行すれば良い
  • 3-way ハンドシェイクのオーバーヘッドが無視できない

TCP で接続を確立してからクエリを送ると 1 往復以上余計にかかります。UDP なら 1 往復で名前解決が終わり、ブラウザの体感がはっきり速くなります。

ただし、応答サイズが大きい場合 (DNSSEC, 多レコード) は TCP にフォールバックする仕様も併存しています。

動画・音声ストリーミング

リアルタイム性の高い動画・音声では UDP が定番です。

  • VoIP (Skype の昔のバージョン、SIP) — RTP/UDP
  • ビデオ会議 (Zoom, Google Meet) — WebRTC over UDP
  • ライブ配信 (一部の OBS / SRT) — UDP ベース

「再送を待っている間に映像が固まる」のを避けるため、落ちたパケットは諦めて次に進むほうが体感が良いのです。

この章のポイント

コーデック側のエラー耐性

動画コーデック (H.264, AV1 など) はパケットロスにある程度耐えられるように設計されています。失われたフレームを前後のフレームから補完したり、キーフレームを定期的に挿入したりして、UDP の不確実性を吸収しています。

オンラインゲーム

FPS や MMORPG などのアクションゲームは UDP がほぼ必須です。

  • プレイヤーの位置情報を 30-60 Hz で送信
  • 1 つのパケットが落ちても、次のパケットで補完
  • TCP の Head-of-Line Blocking でカクつかせたくない

特に競技性の高いゲーム (Apex Legends, Valorant) では、数十ミリ秒のレイテンシ差が勝敗に影響しうるため、UDP + 独自プロトコルでチューニングしています。

IoT センサー

温度センサーや位置トラッカーなど、IoT デバイスも UDP ベースのプロトコル (CoAP など) を好みます。

  • 端末側のリソース (CPU・メモリ) が限られている
  • 送信頻度が高く、1 つ落ちても困らない
  • バッテリーを長持ちさせたい

TCP の接続維持コストや再送ロジックを省ける UDP は、低リソース端末と相性が抜群です。

QUIC と HTTP/3

最近の大きな潮流が QUIC (Quick UDP Internet Connections) です。Google が開発し、IETF で標準化された UDP ベースのプロトコルで、HTTP/3 の下位プロトコルとして使われています。

QUIC は UDP の柔軟性を活かしつつ、TCP 同等の信頼性 + TLS 1.3 の暗号化を持っています。

  • 接続確立が 1 RTT (TLS 込み)、再接続なら 0 RTT
  • 1 つのコネクション内で複数ストリームを多重化、Head-of-Line Blocking を回避
  • パケットロスがあってもストリーム単位で並行進行

Cloudflare や Google のサービスは HTTP/3 (QUIC) に積極的に対応しており、特にモバイル環境で TCP より速いとされます。

この章のポイント

UDP が「鎌倉時代から復活」した理由

UDP は古いプロトコルですが、QUIC のおかげで現代 Web の最前線に返り咲きました。「TCP の遅さや硬さを、UDP の上に新しい高速プロトコルを作ることで突破する」という発想は、今後も他の用途で広がっていきそうです。

マルチキャストと UDP

UDP には、1 対多の効率配信を可能にするマルチキャストがあります。1 つのパケットを複数の受信者に配るので、IPTV や金融機関の株価配信などで使われます。TCP では原理的にできない芸当です。

ただし、インターネット全体でのマルチキャストはルーター側のサポートが限定的なため、現状は社内 LAN や ISP 内に閉じた用途が多いです。

まとめ

このレッスンの要点は、UDP の代表用途 / コーデック側の補完 / QUIC が UDP を選んだ理由 の 3 点です。実務でこれらを切り分けて説明できるようになると、設計レビューや障害対応の精度が一段上がります。

理解度チェック

Q. ビデオ会議で UDP が選ばれる主な理由は？

  1. UDP のほうがエラー検出が強いから
  2. 落ちたパケットの再送を待つより、捨てて次に進むほうが体感が良いから
  3. UDP は暗号化が自動で行われるから
  4. TCP がビデオストリームに対応していないから
答えを見る

正解は 2。リアルタイム会議では「過去のパケットを再送するより、今の映像/音声を優先して進む」ほうがユーザー体験が良いため、UDP + コーデックの誤り訂正の組み合わせが定番です。

出典 (References)

最終更新: 2026-05-28

関連レッスン

よくある質問

Q. UDP を使うとパケットロスが必ず発生しますか？

A. ネットワーク状況次第です。LAN など安定した環境ではロスはほとんど起きません。インターネット経由でも、動画コーデックやゲームの補間ロジックなどアプリ層でカバーできる範囲なら問題になりません。

Q. DNS は UDP だけで動くのですか？

A. 通常の問い合わせは UDP の 53 番ポートで完結しますが、DNSSEC や多レコード応答など応答サイズが大きい場合は TCP にフォールバックします。両方を実装しているのが標準的なリゾルバです。

Q. QUIC は UDP なのに信頼性があるのはなぜですか？

A. QUIC はアプリケーション層で独自の再送・輻輳制御・暗号化を実装しているためです。UDP が提供しないパケット順序保証や再送処理を QUIC 自身が担うことで、TCP 同等の信頼性と TLS 1.3 の安全性を両立しています。

次のレッスン

次は ポート番号と well-known port で、TCP より UDP が選ばれる代表的な用途とその理由を学びます を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. UDP の用途 の要点を自分の言葉で説明できる
  2. DNS・動画配信・ゲーム・QUIC でそれぞれ UDP が選ばれる理由を説明できる
  3. 理解度チェックで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. UDP の用途 とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン

復習ミニクイズ

HTTP/3 が UDP 上に構築されている主な理由はどれですか