【比較】TCPとUDPの違い¶
概要¶
TCP（Transmission Control Protocol）と UDP（User Datagram Protocol）は、どちらも IP の上位で動くトランスポート層プロトコルです。「ポート番号でアプリケーションを区別する」点は共通なので入門時に混同されがちですが、通信の信頼性をプロトコル自身が保証するかどうかという設計思想が正反対です。
TCP はコネクション型で、3 ウェイハンドシェイクで接続を確立し、データを順序通り・欠落なく届けるための再送・順序整列・フロー制御・輻輳制御を備えた「信頼できるバイトストリーム」を提供します（RFC 9293）。一方 UDP はコネクションレスで、データグラムを「投げっぱなし」にするだけ。到達保証も順序保証も重複排除もなく、ヘッダも 8 バイトと最小限です（RFC 768）。この違いを理解すると、なぜ DNS や VoIP、そして QUIC/HTTP3 が UDP の上に作られるのかが見えてきます。
例えるなら：書留郵便と投函ポストカード¶
- TCP … 書留郵便。送る前に「受け取れますか」と相手と段取りし（ハンドシェイク）、届かなければ再送し、届いた順に並べ直して渡す。確実だが手続きの分だけ遅い。
- UDP … 宛先を書いてポストに投函する絵はがき。届くかも順番も保証しないが、出すのは一瞬で軽い。確実さが要るなら差出人（アプリ）側で工夫する。
詳細比較¶
| 比較軸 | TCP | UDP |
|---|---|---|
| 接続モデル | コネクション型（3 ウェイハンドシェイクで確立、FIN で終了） | コネクションレス（事前の確立なし） |
| 信頼性（到達保証） | あり（確認応答 ACK と再送で欠落を補償） | なし（到達はベストエフォート、欠落・重複は検出されない） |
| 順序保証 | あり（シーケンス番号で順序整列、バイトストリームとして提供） | なし（データグラムは送信順に届くとは限らない） |
| フロー制御 | あり（受信ウィンドウで送り手を抑制） | なし |
| 輻輳制御 | あり（ネットワーク混雑時に送信レートを下げる） | なし（必要ならアプリ側で実装） |
| データ境界 | なし（連続バイトストリーム。受信側でメッセージ区切りを管理） | あり（1 送信＝1 データグラムの境界を保持） |
| ヘッダサイズ | 20 バイト以上（オプションで可変） | 8 バイト固定 |
| Head-of-line ブロッキング | 起こりうる（1 個の欠落で後続データの引き渡しが待たされる） | プロトコル層では起こらない |
| 代表的な用途 | HTTP/1.1・HTTP/2、SSH、SMTP、ファイル転送など | DNS、VoIP/リアルタイム映像、ゲーム、QUIC（HTTP/3 の土台） |
よくある誤解¶
- 誤解1：「UDP は TCP の劣化版で、使うべきではない」 — 用途が違うだけで優劣ではありません。リアルタイム音声・映像では、古いデータを再送して順番待ちさせるより、欠落フレームを捨てて最新を優先したほうが体感品質が高い。再送・順序整列が「邪魔」になる領域で UDP は積極的に選ばれます。
- 誤解2：「UDP は信頼性が一切ないので重要な通信には使えない」 — UDP 自体に信頼性機構がないのは事実ですが、信頼性をアプリ／上位プロトコル側で再実装できます。実例が QUIC（RFC 9000）です。QUIC は UDP 上で動きつつ、独自の再送・順序整列・独自の損失回復・輻輳制御（RFC 9002）を実装し、信頼性のあるストリームを提供します。HTTP/3 はこの QUIC の上で動いています。
- 誤解3：「TCP なら順序が保証されるので遅延は起きない」 — 順序保証はむしろ遅延要因になりえます。TCP は 1 つのセグメントが欠落すると、後続が届いていてもそれを再送が完了するまでアプリに渡しません（Head-of-line ブロッキング）。HTTP/2 がこの TCP レベルの HOL に悩み、HTTP/3 が UDP ベースの QUIC に移った主因がこれです。
- 誤解4：「UDP はチェックサムすらないので壊れたデータも素通り」 — UDP にもチェックサムフィールドはあります（IPv4 では任意、IPv6 では必須）。ただし検出するだけで、壊れていればそのデータグラムが破棄されるのみ。再送はされません。
実務での選び分け¶
- 欠落・順序が許されない（ファイル、API、認証、メール） → TCP。信頼性をプロトコルに任せられる。
- 遅延・即時性が最優先で多少の欠落は許容（音声・映像・ゲーム） → UDP。古いデータの再送待ちを避けられる。
- 大量の短いリクエスト／レスポンス（DNS など） → UDP。コネクション確立のラウンドトリップを省ける（応答が大きい等の場合は TCP にフォールバック）。
- 信頼性は欲しいが TCP の HOL ブロッキングを避けたい（モダンな Web） → UDP 上の QUIC（HTTP/3）。ストリーム単位で独立し、1 つの欠落が他ストリームを止めない。
- 判断の軸：「再送・順序整列のコスト（遅延）」と「欠落の許容度」のトレードオフで決める。信頼性が要るなら TCP か QUIC、即時性が要るなら素の UDP。
ひとことまとめ¶
TCP は「順序通り・欠落なしを保証する代わりに手続きと遅延を伴うコネクション型」、UDP は「保証しない代わりに軽量・低遅延なコネクションレス型」。信頼性が必要なら TCP（または UDP 上に信頼性を再構築した QUIC/HTTP3）、即時性が最優先なら素の UDP、と用途で選びます。
出典・参考¶
- RFC 9293「Transmission Control Protocol (TCP)」（TCP は reliable, in-order, byte-stream service を提供。3 ウェイハンドシェイク。RFC 793 ほかを obsolete）: https://www.rfc-editor.org/rfc/rfc9293.html
- RFC 768「User Datagram Protocol」（UDP は最小オーバーヘッドのデータグラム。delivery and duplicate protection are not guaranteed。チェックサムは省略可）: https://www.rfc-editor.org/rfc/rfc768.html
- RFC 9000「QUIC: A UDP-Based Multiplexed and Secure Transport」（QUIC は UDP 上で reliable・in-order なストリームと独自の輻輳制御を提供、HTTP/3 の土台）: https://www.rfc-editor.org/rfc/rfc9000.html
- RFC 9002 - QUIC Loss Detection and Congestion Control — QUIC の損失回復・輻輳制御の規定