UDP

概要

UDP（User Datagram Protocol）は、TCP/IPのTCPと対をなすもう一つの転送プロトコルです。TCPが「順序どおり・欠落なく届ける」ための仕組みをフルに備えるのに対し、UDPは事前の接続確認も、届いたかどうかの確認も、再送も一切しません。データを小包（データグラム）に詰めて、宛先のIPアドレスとポート番号へ投げる——やることはほぼそれだけです。

一見頼りない仕様ですが、だからこそ速くて軽い。音声通話や動画配信、オンラインゲーム、そしてDNSの問い合わせなど、「多少欠けても遅れるよりまし」「一往復で終わるから儀式は不要」という通信の主役です。

なぜ生まれたか

TCPの信頼性はタダではありません。通信の前に3ウェイハンドシェイクの往復が必要で、パケットが1つ失われれば再送が完了するまで後続のデータも足止めされます。ところが音声通話では、0.2秒前の音声パケットを再送してもらっても、もう再生時刻を過ぎていて役に立ちません。古いデータを律儀に届け直すTCPの生真面目さが、リアルタイム用途ではむしろ品質を下げてしまうのです。

また、DNSのように「1つ質問して1つ答えをもらう」だけの通信では、そのためにコネクションを確立して切断する手間のほうが本体より重くなります。そこで、IPの「ベストエフォートで運ぶ」機能にポート番号による振り分けとチェックサム（データ破損の検出）だけを足した最小限のプロトコルとして、1980年にUDPが定義されました。信頼性が必要ならアプリケーションが自分で作ればよい、という割り切りです。

詳細

仕組み: ほとんど「何もしない」設計

UDPのヘッダは送信元ポート・宛先ポート・長さ・チェックサムのわずか8バイトで、TCPのヘッダ（最低20バイト）と比べても身軽です。コネクションという概念がないため、送信側は相手の状態を気にせずいつでもデータグラムを送れます。

TCPと往復を並べて比べると、その身軽さがよく分かります。

この「何もしなさ」は欠点であると同時に自由度です。TCPでは1つの通信が1本のコネクションに縛られますが、UDPなら1つのソケットで不特定多数とやり取りできますし、全員に一斉送信するブロードキャストやマルチキャストもUDPの領分です。

代表的な使いどころ

DNSの問い合わせは典型例で、1往復で完結する小さなやり取りに最適です（応答が大きい場合などはTCPも併用されます）。音声・ビデオ通話（WebRTCなど）やライブ配信、オンラインゲームでは、「最新の状態」だけが価値を持つため、失われた古いパケットは諦めて先へ進むUDPの性質がそのまま利点になります。ほかにも時刻同期のNTP、ログ転送のsyslog、VPNのWireGuardなど、インフラの足回りにも広く使われています。

「信頼性はアプリ層で作る」— QUICへ

UDPの設計思想が最も大きく花開いたのが、HTTP/3の土台であるQUICです。TCPの改良はOSカーネルや経路上の機器の対応に縛られて何十年も進めにくかったのに対し、QUICはUDPの上にアプリケーションとして再送制御・輻輳制御・TLS相当の暗号化を実装し直しました。「土管はUDPに任せ、賢さは自前で載せ替え可能にする」というアプローチで、TCPが抱えていた「1パケットの欠落が全ストリームを止める」問題（ヘッドオブラインブロッキング）も解消しています。

実務での落とし穴

UDPを選ぶときの落とし穴は、まさに「何もしてくれない」ことに起因します。第一に、欠落・重複・順序の入れ替わりへの対処はすべて自分の設計課題になります。「ローカルでは動くが本番で時々おかしい」というUDPアプリの不具合は、パケットロスを想定していないことが原因の定番です。第二に、輻輳制御がないため、無配慮に送り続けるとネットワークを圧迫します。第三に、送信元IPを詐称しやすい性質から、DNSなどを踏み台にしたリフレクション型DDoS攻撃に悪用されてきた歴史があり、UDPサービスの公開には応答サイズの制限などの配慮が要ります。最後に、企業ネットワークのファイアウォールやNATはUDPに厳しめなことが多く、「UDPが通らない環境ではTCPにフォールバックする」二段構えが実務の定石です。