第19回トランスポート層 ─ UDP(標準) | 通信ネットワーク学習

学習目標

本講を終えると、以下の問いに学術的な言葉で答えられるようになります。

UDP の4つの特徴(コネクションレス・無信頼・順序非保証・フロー/輻輳制御なし)を挙げ、それぞれが「ない」ことの設計上の意味を説明できる
UDP ヘッダ(送信元ポート / 宛先ポート / 長さ / チェックサム、各 16 ビット = 計 8 バイト)を図示し、各フィールドの役割を説明できる
UDP データグラムの送受信フローを、ソケット API(sendto / recvfrom)とカプセル化の観点から述べられる
UDP が選ばれる代表的アプリケーション(DNS・DHCP・SNMP・VoIP・リアルタイム動画・オンラインゲーム・QUIC)について、なぜ UDP なのかを設計上の理由とともに述べられる

本講は第17回トランスポート層の役割(標準) で導入したポート・ソケット・多重化と、第18回 TCP の信頼性(標準) で扱った TCP の機能を前提とします。「TCP に対する対比」として読むと、UDP の薄さが何を可能にしているかが鮮明に見えます。発展編では QUIC / HTTP/3(発展編シリーズ第28回)で、UDP の上にアプリ層から TCP 相当の信頼性を再構築する事例を扱います。

このレッスンの目次

01 UDP の特徴 UDP(User Datagram Protocol, RFC 768, 1980年… 02 UDP ヘッダ構造 UDP セグメントはヘッダ(8 バイト) とアプリケーションデータ(可変長) の… 03 送信の流れ送信側のアプリが sendto を呼んでから、受信側のプロセスが recvfro… 04 UDP の用途 UDP の薄さと低遅延性は、特定の用途で大きな利点になります。代表例を見ていきましょ… 05 まとめと用語本講の重要語句を整理 06 確認問題理解度を問題でチェック

UDP の特徴 ─ 最小機能のトランスポート

UDP(User Datagram Protocol, RFC 768, 1980年) は、トランスポート層に求められる機能のうち「多重化と簡易な誤り検出」しか提供しない、極めて薄いプロトコルです。その薄さがオーバーヘッドの小ささと低遅延につながり、用途によっては TCP より好まれます。

POINT UDP の4つの特徴:
1. コネクションレス ─ 事前のハンドシェイクなし。データグラム単位で投げっぱなし。
2. 無信頼 ─ 再送なし。途中で消えても気付かない・通知しない。
3. 順序非保証 ─ 並べ直しなし。受信順がそのままアプリに渡る。
4. フロー制御・輻輳制御なし ─ アプリが送りたいレートでそのまま送る。

「ない」ことのトレードオフ

UDP のメリット

ヘッダがわずか8バイト(TCP は最小 20 バイト)。短いペイロードで効率が高い
3ウェイハンドシェイクの待ち時間がなく、1往復で要求と応答が完結できる
状態を持たないため、サーバが大量クライアントを並列処理しやすい(セッションテーブル不要)
マルチキャスト・ブロードキャストの送信に使える(TCP は1対1のみ)
アプリ層で再送・順序を独自制御したい場合(QUIC・ゲーム等)に最適

UDP のデメリット(=注意点)

パケットロスや順序逆転はアプリ自身が検出・対処する責任を負う
ネットワーク輻輳時に送信を絞らないため、輻輳を悪化させる恐れ(TCP に対する公平性の問題)
NAT/ファイアウォール越しのセッション維持(キープアライブ)を別途考える必要がある
反射増幅型 DDoS の踏み台にされやすい(送信元 IP 偽装が可能)[要確認]

UDP と TCP の比較

UDP の動作モデル

送信側は sendto(socket, data, …, 宛先IP, 宛先ポート) を呼ぶたびに、独立した1個のデータグラムが送出されます。事前のセットアップは不要、送信後の確認も行いません。受信側は recvfrom でブロッキング待機し、届いたデータグラム単位でアプリに渡します。

「送ったか」「届いたか」「順序通りか」はすべてアプリ側の関心事
サーバはステートレス設計が容易。クライアント追跡用テーブルが要らない
パケット長 = アプリのメッセージ境界が保たれる(レコード型)

TCP の動作モデル(復習)

TCP はコネクション指向で、データ送信前に3ウェイハンドシェイク(SYN → SYN+ACK → ACK)で双方向の論理回線を確立します。確立後はバイトストリームとしてデータを流し、シーケンス番号と確認応答(ACK)で確実な配送・順序保証・フロー制御・輻輳制御を提供します(詳細は第18回 TCP)。

コネクション状態を双方が保持(セッションテーブルが必要)
パケットロス検出 → 自動再送(タイムアウト・3重ACK)
受信窓・輻輳窓により送信レートを動的に調整
アプリはバイト列を渡すだけでよい(信頼性は OS が担保)

基本的な違いの早見表

観点	UDP	TCP
コネクション	なし(コネクションレス)	あり(3ウェイハンドシェイク)
信頼性	なし(再送・確認応答なし)	あり(ACK・再送)
順序保証	なし	あり(シーケンス番号で並べ直し)
フロー制御	なし	あり(受信窓 RcvWindow)
輻輳制御	なし	あり(CongWin・AIMD 等)
ヘッダ長	固定 8 バイト	最小 20 バイト(オプション含むと最大 60)
メッセージ境界	保たれる(データグラム単位)	失われる(バイトストリーム)
1対多通信	マルチキャスト・ブロードキャスト可	1対1のみ
典型用途	DNS・DHCP・SNMP・VoIP・動画・ゲーム・QUIC	HTTP/1.1, 2 / SMTP / SSH / FTP / IMAP

つながる知識: 「TCP は信頼性、UDP は速さ」という二分は正しい一方、QUIC(HTTP/3 が乗る)はUDP の上にアプリ層で TCP 相当の信頼性を実装するという、新しい中間設計です。発展編で扱います。

Q. なぜ動画のライブ配信や VoIP は UDP を選ぶのでしょうか?「TCP の方が確実なのでは?」と思った人は、ぜひ自分なりの仮説を立ててからクリック。

UDP ヘッダの構造 ─ わずか 8 バイト

UDP セグメントはヘッダ(8 バイト)とアプリケーションデータ(可変長)の2部分だけからなります。ヘッダは 16 ビットのフィールドが4つ(計 64 ビット = 8 バイト) というシンプルな構造です。

POINT UDP ヘッダの4フィールド(各 16 ビット):
1. 送信元ポート(Source Port)
2. 宛先ポート(Destination Port)
3. 長さ(Length, ヘッダ + データの合計バイト数)
4. チェックサム(Checksum, 16ビット和の1の補数による誤り検出)

ヘッダ構造図(32 ビット幅 × 2 行 + データ部)

図の見方:UDP のヘッダは「送信元ポート / 宛先ポート / 長さ / チェックサム」の4つだけで、各 16 ビット = 計 64 ビット = 8 バイトです。TCP の最小 20 バイトと比べてとてもコンパクト。これがオーバーヘッドの小ささを生みます。

各フィールドの役割

フィールド	サイズ	役割
送信元ポート	16 bit	送り手側のソケットを示す。応答が必要な場合の戻り口。クライアントがリクエスト時に動的ポートをここに入れる
宛先ポート	16 bit	受け手側のソケットを示す。逆多重化の鍵となる必須情報
長さ	16 bit	ヘッダ + データの合計バイト数(最小 8、上限は理論上 65535)
チェックサム	16 bit	誤り検出。16 ビットごとの和の1の補数で計算(後述)

もっと詳しく:UDP チェックサムの計算と省略

UDP チェックサムは、トランスポート層の誤り検出フィールドです。計算は次の手順で行います。

UDP ヘッダ・データ・擬似ヘッダ(IPの送信元/宛先 IP・プロトコル番号・UDP長を含む)を 16 ビット単位に分割
すべてを1の補数和(桁あふれは最下位桁へ回す = end-around carry)で合算
最後にその1の補数を取った値をチェックサムフィールドに入れる
受信側は同じ計算を行い、結果が 1111111111111111(オール1)になればエラーなしと判定。違えばそのデータグラムを破棄

擬似ヘッダを混ぜるのは、IP 層のアドレスまで含めて誤りを検出するため(間違った宛先で届いたものを撥ねる)です。

IPv4 ではチェックサムを省略可能(計算しない場合は値 0 を入れる)であり、ローカルでオーバーヘッドを下げる用途に使われた歴史があります。一方 IPv6 ではUDP チェックサムは必須で、0 にすることはできません(RFC 2460 系)[要確認:RFC 番号と例外規定の最新動向]。

誤り検出能力としては、CRC のような強い符号と比べて1の補数和は弱い(すべてのビット誤りを検出できるわけではない)ことが知られています。リンク層(Ethernet)の CRC で多くは弾かれる前提で、トランスポート層は最終確認として軽量チェックを行う、という分担になっています。

UDP データグラム送信の流れ ─ ステップで追う

送信側のアプリが sendto を呼んでから、受信側のプロセスが recvfrom でデータを受け取るまでの典型的な流れを、4 ステップで追ってみましょう。

ステップ 1:アプリがソケットにデータを書き込む
送信側プロセスが socket(AF_INET, SOCK_DGRAM, 0) で UDP ソケットを作り、sendto(sock, buf, len, …, dstAddr) を呼ぶ。OS にデータと宛先(IP, ポート)が渡る。コネクション確立は不要。

ステップ 2:UDP がヘッダを付与し IP に渡す
トランスポート層は送信元ポート(動的ポートから OS が選ぶ)・宛先ポート・長さ・チェックサムの8バイトヘッダをデータの前に付け、UDP セグメント(=データグラム)として下層 IP に渡す。

ステップ 3:IP・リンク層を経由してネットワークへ
IP が宛先 IP アドレスを見て経路を決め、リンク層がフレームを作って物理媒体へ送出する。途中ルータは IP ヘッダだけを見て転送し、UDP ヘッダの中身は触らない。パケットロスや順序逆転が起きても、UDP は何もしない。

ステップ 4:受信側 UDP が逆多重化、アプリへ届ける
受信側のリンク層 → IP → UDP と昇り、UDP 層が宛先ポートを見て対応するソケットを引き当て、データ部分を受信バッファに格納する。アプリは recvfrom でそれを読み出し、必要なら送信元(IP, ポート)を取得して返信もできる。

1 / 4

図の見方:UDP は TCP のような事前のハンドシェイク・確認応答・タイムアウトを持たないため、送信側・受信側ともに状態管理が簡素です。送信1回・受信1回がそれぞれ独立した「データグラム」として扱われます。

つながる知識: このステップ図はカプセル化(第11回第4節)の具体例です。アプリ層の生データに、UDP ヘッダ → IP ヘッダ → リンク層ヘッダ/トレイラ、と層を下りるたびに包まれていく流れを思い出してください。

UDP が選ばれる場面 ─ DNS から QUIC まで

UDP の薄さと低遅延性は、特定の用途で大きな利点になります。代表例を見ていきましょう。「なぜ UDP なのか」を、各用途の設計上の要請と結びつけて理解することが大切です。

POINT UDP が選ばれる典型的理由:
・1往復で済む短い問い合わせ(DNS, NTP, SNMP)─ コネクション確立コストを払う価値がない
・初期化通信のため TCP が前提とする情報がまだない(DHCP は IP 取得前に動く必要がある)
・リアルタイム性 > 信頼性(VoIP, ライブ動画, ゲーム)─ 古いデータを再送しても無意味
・1対多のばらまき(ブロードキャスト・マルチキャスト)─ TCP では構造的に不可能
・アプリ層で独自の信頼性・輻輳制御を組みたい(QUIC)

代表的な UDP 利用アプリケーション

アプリ・プロトコル	ポート	UDP を選ぶ理由
DNS(ドメイン名解決)	53	多くの問い合わせは1往復で完結。応答も小さい。コネクション確立の3パケット分が無駄になる。応答が大きい場合のみ TCP にフォールバック
DHCP(IP アドレス自動設定)	67/68	クライアントは IP を持っていない段階でブロードキャストしてサーバを探す必要がある。TCP は IP が前提なので不可能
SNMP(機器管理)	161/162	多数の機器に短い Get/Trap を頻繁に送る用途。コネクション維持コストが負担になる
NTP(時刻同期)	123	1往復のタイムスタンプ交換で完結。再送より新鮮な時刻が大事
TFTP(簡易ファイル転送)	69	ブートローダなど、TCP スタックがまだ動かない環境でも実装できる軽さが必要
VoIP / RTP(音声・動画)	動的	古い音声フレームの再送は無意味。遅延と揺らぎを抑える方が品質に直結
オンラインゲーム	動的	位置・状態の最新スナップショットが届けば古いものは捨ててよい。低遅延が勝敗を決める
QUIC / HTTP/3(Web 新世代)	443	UDP の上で TCP 相当の信頼性 + TLS + 0-RTT 接続を独自実装。中間装置が UDP を「ただ通す」性質を活かしている

用途を支える UDP の性質(対応関係)

「短い問い合わせ」を支える性質

コネクションレス + 8バイトヘッダ。リクエスト 1 パケット・レスポンス 1 パケットの合計2パケットで完結でき、TCP の 3 パケット(ハンドシェイク)+ 2 パケット(本文)+ 4 パケット(切断)と比べて圧倒的に少ない。DNS や NTP がこれに該当。

「リアルタイム配信」を支える性質

無信頼・順序非保証・フロー制御なし。ネットワーク輻輳時に送信を絞らないため遅延が安定しやすく、消えたフレームは捨てて次へ進める。VoIP・動画・ゲームに適合。

「アプリ層で独自制御」を支える性質

UDP はトランスポート層の「素地」として機能する。QUIC は UDP の上にコネクション概念・暗号・輻輳制御を再構築。アプリレベルで全機能を握れるため、ブラウザの更新だけで TCP を置き換えるかのような進化が可能になった。

QUIC の位置付け(参考)

QUIC(RFC 9000, 2021年)は Google が 2012 年頃から実装を始め、IETF で標準化されたトランスポートプロトコルです。UDP の上にアプリ層として実装され、TLS 1.3 を統合し、0-RTT 再接続・コネクション識別子による経路変更耐性などを備えます。HTTP/3 はこの QUIC 上で動作します。「なぜ UDP の上に作ったのか?」の最大の理由は、OS カーネルの TCP を置き換える政治的・技術的コストを払わずに、トランスポート層を進化させるためと説明されます [要確認:RFC・年代の正確性]。詳しくは発展編で扱います。

考えてみよう: 「UDP は不便で危ない」という印象を持つ人もいますが、本当の問題は用途と性質のミスマッチです。動画配信に TCP を使うとカクつき、ファイル転送に UDP を使うと壊れたファイルが届く。設計者は「アプリが本当に求めているのは信頼性か、低遅延か」を見極めて選んでいます。

まとめと用語チェック

SUMMARY 1. UDP はコネクションレス・無信頼・順序非保証・フロー/輻輳制御なしの最小機能トランスポート
2. UDP ヘッダは8 バイト(送信元ポート / 宛先ポート / 長さ / チェックサム、各 16 ビット)
3. 送信は sendto、受信は recvfrom。コネクション状態を持たないためサーバはステートレスに保てる
4. UDP の用途:DNS / DHCP / SNMP / NTP / TFTP / VoIP / リアルタイム動画 / ゲーム / QUIC(HTTP/3)
5. 選択基準は「短い問い合わせ」「初期化通信」「リアルタイム性」「アプリ層独自制御」

用語チェック

用語	1行説明
UDP(User Datagram Protocol)	RFC 768。コネクションレス・無信頼・8バイトヘッダのトランスポート
UDP セグメント / データグラム	UDP の通信単位。ヘッダ 8 バイト + データ
コネクションレス	事前のハンドシェイクなしで送信できる通信モデル
チェックサム	UDP/TCP のヘッダで使う 16 ビットの誤り検出符号(1 の補数和)
擬似ヘッダ	UDP/TCP チェックサム計算のために IP の送信元/宛先 IP・プロトコル番号・長さを混ぜる仮想領域
sendto / recvfrom	UDP ソケットでデータを送受信するシステムコール
FEC(前方誤り訂正)	受信側だけで誤りを訂正できるよう冗長情報を加える方式。UDP の上で再送せずに信頼性を補う
QUIC	UDP の上に実装された新しいトランスポート。HTTP/3 が乗る

NEXT: 次回(第20回)はトランスポート層の下、ネットワーク層に戻り、IPv4 ヘッダ・サブネット計算・NAT・ICMP を扱います。「ホスト→ホスト」を運ぶ IP の足元を改めて押さえると、UDP / TCP との役割分担がさらに鮮明になります。

確認問題

問1. UDP の特徴として誤っているものを1つ選べ。

次の選択肢から誤った記述を選択してください。

A. 事前のコネクション確立を行わない(コネクションレス)

B. パケットの順序を保証しない

C. ヘッダは固定長 8 バイトで、TCP より小さい

D. 失われたデータグラムを自動的に再送する

正解:D(誤った記述)
UDP は無信頼であり、再送・確認応答(ACK)・タイムアウトといった機能を持ちません。失われた場合の検出・再送はアプリ側の責任です。A・B・C はすべて UDP の正しい特徴です。再送が欲しいときは TCP を選ぶか、UDP の上にアプリ層で再送機構を実装(QUIC のように)します。

問2. UDP ヘッダの構造について、正しいものを1つ選べ。

次の選択肢から最も適切なものを選択してください。

A. 送信元ポート・宛先ポート・長さ・チェックサムの4フィールドからなり、各 16 ビット = 計 8 バイト

B. 送信元 IP・宛先 IP・ポート・チェックサムの4フィールドからなり、計 20 バイト

C. シーケンス番号と確認応答番号を含み、最小 20 バイトの可変長ヘッダを持つ

D. ヘッダは存在せず、アプリのメッセージがそのままIPに渡される

正解:A
UDP ヘッダは「送信元ポート / 宛先ポート / 長さ / チェックサム」の4つの 16 ビットフィールド(計 64 ビット = 8 バイト)で構成されます。B は IP ヘッダの記述に近い誤り、C は TCP ヘッダの説明、D は誤り(UDP にも 8 バイトのヘッダがあります)。

問3. 次のうち、設計上の理由からUDP を選ぶのが自然と考えられるアプリケーションはどれか。

次の選択肢から最も適切なものを選択してください。

A. Web ページの HTML や画像を取得する HTTP/1.1 通信(欠落するとページが壊れる)

B. ライブ配信の音声・動画ストリーム(古いフレームの再送より、新しいフレームの到着が大事)

C. 銀行の振込トランザクション(金額や宛先が一字でも欠落してはならない)

D. 遠隔ログイン SSH(コマンドや出力が順序通り完全に届く必要がある)

正解:B
ライブ配信は「再送より時間優先」の典型例で、UDP(あるいは UDP の上に乗る RTP/QUIC)が選ばれます。古いフレームを再送してもすでに再生位置を過ぎており役に立たないため、欠けたフレームは捨てて次へ進める設計が必要です。一方 A・C・D は完全性と順序が必須で、TCP が適切です。

問4. DHCP がトランスポートとして UDP を採用している主な理由として、最も適切なものを1つ選べ。

次の選択肢から最も適切なものを選択してください。

A. DHCP では大量データを送るので帯域効率が最重要だから

B. UDP の方が暗号化が簡単だから

C. クライアントは IP アドレスを持っていない段階でサーバを探す必要があり、ブロードキャストできない TCP では実現できないから

D. UDP はパケットロスがないので確実だから

正解:C
DHCP の DISCOVER は IP アドレス割り当てを受ける前に動くため、まだ自分の IP を持たない状態でサブネットへブロードキャストする必要があります。TCP は事前にコネクションを確立する必要があり、ブロードキャスト通信もできないため、初期化通信には UDP が適しています。A は誤り(DHCP は短いメッセージ)、B は無関係、D は逆(UDP には信頼性がない)。

問5. UDP のチェックサムについて、正しい記述を1つ選べ。

次の選択肢から最も適切なものを選択してください。

A. 32 ビットの CRC を用いて計算され、すべてのビット誤りを検出できる

B. 16 ビット和の1の補数で計算され、IPv4 では省略可能だが IPv6 では原則必須である

C. 暗号学的ハッシュであり、改ざん検知にも使える

D. 送信元ポート番号と一致するように計算される識別子である

正解:B
UDP のチェックサムは 16 ビットフィールドで、ヘッダ・データ・擬似ヘッダ(送信元/宛先 IP などを含む)を 16 ビット単位で1の補数和を取った値の1の補数を入れます。誤り検出能力は CRC より弱く(A は誤り)、暗号学的でもないため改ざん検知には使えません(C は誤り)。IPv4 では値 0 とすることで省略可、IPv6 では原則必須です。D は無関係。