「TCP」と「UDP」の違いは？速度・信頼性・用途・QUICとの関係をわかりやすく解説

インターネット通信について調べていると、

「TCPで通信する」

「UDPを使ったリアルタイム通信」

「HTTP/3はUDPベースのQUICを利用する」

といった説明を目にします。

しかし、

「TCPとUDPは何が違う？」

「UDPのほうがTCPより速い？」

「TCPはなぜ信頼性が高い？」

「UDPではデータが届かなくてもそのまま？」

「動画やゲームではなぜUDPを使うことがある？」

「HTTP/3がUDPを使っているなら、通信の信頼性は低い？」

と迷うことがあります。

結論からいうと、「TCP」はデータを正しい順序で確実に届けるための仕組みを備えたコネクション型の通信プロトコルで、「UDP」は再送・順序保証などを基本機能として持たず、少ない仕組みでデータグラムを送るコネクションレス型の通信プロトコルです。

一言で覚えるなら、

TCP＝「正しく順番どおり届けることを重視」

UDP＝「シンプルに素早く送ることを重視」

です。

IETFのRFC 9293ではTCPについて、アプリケーションへ、

「reliable, in-order, byte-stream service」

を提供すると規定しています。

つまり、データの損失を検出し、必要に応じて再送し、正しい順序でアプリケーションへ渡す仕組みがあります。

一方、RFC 768ではUDPについて、最小限のプロトコル機構でメッセージを送る仕組みであり、

• データの到達
• 重複防止
• 順序どおりの配送

を保証しないとされています。

ただし、

「TCPは遅い、UDPは速い」

と単純に考えるのは正確ではありません。

実際の通信性能は、アプリケーション、回線品質、遅延、パケットロス、輻輳制御、再送方式など多くの要素で変わります。

この記事では、「TCP」と「UDP」の違いから、接続、再送、順序保証、ポート番号、ハンドシェイク、ゲーム・動画・DNSでの利用、さらにHTTP/3・QUICとの関係まで詳しく解説します。

「TCP」と「UDP」の違い【結論】

比較項目	TCP	UDP
正式名称	Transmission Control Protocol	User Datagram Protocol
通信方式	コネクション型	コネクションレス型
信頼性	損失検出・再送などを行う	到達そのものを保証しない
順序保証	正しい順序で渡す	保証しない
重複処理	重複データを適切に扱う仕組みがある	重複防止を保証しない
接続確立	通信前に接続を確立	基本的に接続確立なしで送信
データの単位	バイトストリーム	データグラム
基本ヘッダー	最低20バイト	8バイト
代表用途	Web、メール、ファイル転送など	DNS、リアルタイム通信、QUICの基盤など

3秒で判断するなら、

「データを順番どおり確実に届けたい？」 → TCP

「多少の欠落より遅延を抑えたい・独自に制御したい？」 → UDP

と考えると分かりやすいでしょう。

そもそもTCPとUDPは何のためのもの？

TCPとUDPはどちらも、インターネットで広く使われる、

トランスポート層のプロトコル

です。

IPがコンピューターから別のコンピューターまでデータを運ぶための基盤を提供するのに対し、TCPやUDPは、

「そのコンピューターのどのアプリケーションへデータを届けるか」

といった役割も担います。

そのためTCP・UDPでは、

ポート番号

が利用されます。

たとえば1台のサーバーで、Webサーバー、DNSサーバー、メールサーバーなど複数のサービスを動かしていても、ポート番号によって通信先のサービスを区別できます。

「TCP」とは？

信頼性のあるバイトストリームを提供するプロトコル

TCPは、

Transmission Control Protocol

の略です。

現在のTCPの基本仕様は、IETFの、

RFC 9293

にまとめられています。

RFC 9293ではTCPについて、

信頼性があり、順序どおりのバイトストリームサービス

をアプリケーションへ提供すると説明しています。

TCPでは、通信途中でデータの一部が失われた場合などに、それを検出して再送する仕組みがあります。

TCPの「信頼性」とは？

TCPでいう信頼性には、主に、

• データの損失を検出する
• 必要なデータを再送する
• データの順序を整える
• 重複したデータを適切に処理する
• エラーを検出する

といった仕組みが関係します。

RFC 9293では、TCPがシーケンス番号によってパケット損失を検出し、チェックサムでエラーを検出し、再送によって損失を修復すると説明しています。

そのため、文章・画像・プログラムファイルなど、

「途中の一部分が欠けては困るデータ」

の送受信に向いています。

TCPは必ず100％データを届ける？

「どんな状況でも必ず届ける」という意味ではありません。

ネットワークが完全に切断されたり、相手のサーバーが停止したりすれば、通信を完了できないことがあります。

TCPの重要な点は、

データが失われたまま正常に届いたことにして処理を続けるのではなく、再送などによって信頼性を確保し、それでも通信できない場合には接続エラーとして扱う

ことです。

そのため、「TCPは確実」と説明するときは、

可能な限り信頼性のある配送を提供する

という意味で理解するのが適切です。

TCPは「順番」も保証する

ネットワーク上では、送信したデータが必ず送信順に到着するとは限りません。

たとえば、

A → B → C

という順序で送信しても、ネットワーク上では、

A → C → B

という順序で届く可能性があります。

TCPではシーケンス番号を利用してデータの順序を管理し、アプリケーションには正しい順序に並べて渡します。

そのため受信側のアプリケーションは、基本的に、

「データがネットワーク上でどの順番に到着したか」

を意識する必要がありません。

TCPは「バイトストリーム」

TCPは、

バイトストリーム

を提供します。

これは、アプリケーションが送信したデータを「1通のメッセージ単位」としてそのまま保持する仕組みではありません。

たとえば送信側で、

• 100バイト送信
• 200バイト送信

と2回に分けたとしても、受信側が必ず、

• 100バイト
• 200バイト

という同じ区切りで受信するとは限りません。

アプリケーション側で、どこまでが1件のデータなのかを判断する仕組みを用意します。

TCPは通信前に「接続」を作る

TCPは、

コネクション型

のプロトコルです。

データ通信を始める前に、クライアントとサーバーの間でTCP接続を確立します。

代表的なのが、

3ウェイハンドシェイク

です。

「3ウェイハンドシェイク」とは？

TCP接続を開始するときには、簡略化すると、

1. クライアント → サーバー：SYN
2. サーバー → クライアント：SYN＋ACK
3. クライアント → サーバー：ACK

というやり取りを行います。

これによって両者が通信できる状態を確認し、シーケンス番号などを同期して接続を開始します。

通信前にこうした処理が必要になるため、TCPでは最初のデータ通信までに一定の時間が必要です。

「UDP」とは？

最小限の仕組みでデータグラムを送るプロトコル

UDPは、

User Datagram Protocol

の略です。

UDPの基本仕様は、1980年に公開された、

RFC 768

で規定されています。

RFC 768ではUDPについて、IPネットワーク上で、

最小限のプロトコル機構でメッセージを送るための仕組み

と説明されています。

TCPのような、

• 接続確立
• 配送保証
• 再送
• 順序制御
• 重複防止

をUDP自身では基本的に提供しません。

UDPは「コネクションレス」

UDPは、

コネクションレス型

の通信プロトコルです。

TCPの3ウェイハンドシェイクのように、送信前に相手とのTCP接続を確立する必要がありません。

送信側は、

「このIPアドレス、このポートへこのデータを送る」

という形でデータグラムを送信できます。

そのためUDPはシンプルですが、相手へデータが届いたかどうかをUDP自身が確認して再送してくれるわけではありません。

UDPではデータが届かないことがある？

あります。

RFC 768ではUDPについて、

配送と重複防止を保証しない

と明記されています。

MDNもUDPには、

• 到達保証
• 順序保証
• 重複防止

がないと説明しています。

たとえば10個のUDPデータグラムを送信しても、ネットワーク状態によっては、

• 9個しか届かない
• 順番が入れ替わる
• 重複して届く

可能性があります。

UDPは「データグラム」単位

TCPがバイトストリームなのに対し、UDPは、

データグラム

というメッセージ単位を保持します。

送信側が1つのUDPデータグラムとして送ったデータは、受信側でも1つのデータグラムとして扱われます。

つまり、

TCP＝連続したデータの流れ

UDP＝1通ずつのメッセージ

という違いもあります。

UDPにもチェックサムはある？

あります。

「UDPは信頼性がないからエラーチェックも一切ない」と考えるのは間違いです。

UDPヘッダーには、

Checksum

フィールドがあります。

ただしチェックサムでデータの破損を検出できても、

「失われたパケットを自動的に再送する」

機能とは別です。

TCPでは損失検出と再送をプロトコル側で行いますが、UDPで同等の信頼性が必要なら、アプリケーションやUDP上に構築した別のプロトコルで実装する必要があります。

TCPとUDPではヘッダーサイズも違う

UDPの基本ヘッダーは、

8バイト

です。

含まれる基本フィールドは、

• 送信元ポート
• 宛先ポート
• Length
• Checksum

の4つです。

一方、TCPヘッダーはオプションなしでも、

最低20バイト

あります。

TCPは、

• シーケンス番号
• 確認応答番号
• 各種フラグ
• ウィンドウサイズ

など、信頼性のある通信を実現するための追加情報を管理する必要があるためです。

ただし、

「UDPはヘッダーが小さいから常にTCPより高速」

という意味ではありません。

「TCPは遅い・UDPは速い」は正しい？

単純化しすぎです。

UDPは、

• 接続確立が不要
• プロトコル自身による再送がない
• 順序制御がない
• ヘッダーが小さい

ため、TCPより少ない仕組みでデータを送れます。

その意味では、低遅延が重要な用途に適した場合があります。

しかし、アプリケーション側で、

• 再送
• 順序制御
• 輻輳制御
• 接続管理

を独自実装すれば、その分の処理は必要になります。

またTCPも長年にわたり高速化・損失回復・輻輳制御が改良されています。

したがって、

TCPとUDPの違いは「速い・遅い」ではなく、「どこまでの通信制御をプロトコル自身が提供するか」

と考えるのが適切です。

「再送」とは？

TCPでは送信データが失われたと判断すると、必要なデータをもう一度送信します。

これが、

再送（Retransmission）

です。

たとえば、

A → B → C

と送信し、Bだけが失われた場合、TCPは損失を検出してBを再送します。

そのため最終的にアプリケーションには、

A → B → C

という正しいデータ列を渡せます。

一方UDPでは、Bが失われてもUDP自身が自動的に再送するわけではありません。

リアルタイム通信では「再送しないほうがよい」場合もある

再送は信頼性を高める一方で、

時間

がかかります。

たとえばリアルタイム音声で、0.5秒前の音声パケットが失われたとします。

その古い音声を再送して待つより、多少音が欠けても、

「今の音声をすぐ再生する」

ほうが望ましい場合があります。

MDNも、時間に敏感なアプリケーションでは、再送で遅れたデータを待つよりパケットを破棄するほうが適切な場合があるため、UDPが利用されると説明しています。

オンラインゲームでUDPが使われることがある理由

オンラインゲームでは、

• プレイヤーの位置
• 向いている方向
• 現在の速度
• 一時的なゲーム状態

など、短い間隔で大量の更新情報を送る場合があります。

たとえば、100ミリ秒前の位置情報が失われたとしても、すでに新しい位置情報が届いていれば、古いデータを再送する価値が低い場合があります。

このような用途ではUDPが適しています。

ただしゲーム内の、

• ログイン
• アイテム購入
• 重要なゲーム結果

など、確実性が必要なデータについては、別の通信方式やアプリケーション側の信頼性制御を利用することがあります。

音声通話・リアルタイム通信とUDP

音声・映像のリアルタイム通信でも、UDPを基盤とするプロトコルが利用される場合があります。

理由は、

「完全に欠落ゼロで届くこと」より、「遅れずに届くこと」が重要な場面がある

ためです。

音声通話で数秒前の音声が遅れて再生されても、会話として使いにくくなります。

多少の欠落を許容してでも、現在の音声を優先するほうが適している場合があります。

動画配信は必ずUDP？

いいえ。

ここはよくある誤解です。

YouTubeなど一般的なWeb動画配信では、HTTPSによって動画データを配信することが多く、利用するHTTPバージョンによって、TCPやQUICが使われます。

たとえば、

HTTP/2 → TCP

HTTP/3 → QUIC（UDPを基盤）

です。

そのため、

「動画＝UDP」

と単純に覚えるのは適切ではありません。

ライブ映像、Web動画、ビデオ会議など、用途や使用プロトコルによって異なります。

DNSではTCPとUDPのどちらを使う？

DNSは歴史的にUDPを広く利用してきました。

名前解決の問い合わせと応答が比較的小さく、毎回TCP接続を確立せずに処理できるUDPと相性がよいためです。

ただしDNSでは状況によってTCPも使用します。

さらに現在では、

• DNS over TLS（DoT）
• DNS over HTTPS（DoH）
• DNS over QUIC（DoQ）

など複数の方式があります。

したがって、

「DNS＝必ずUDP」

ではありません。

TCPの「輻輳制御」とは？

インターネット上で多くのコンピューターが好きなだけデータを送ると、ネットワークが混雑して正常に通信できなくなる可能性があります。

そこでTCPには、ネットワークの状況に応じて送信量を調整する、

輻輳制御（Congestion Control）

の仕組みがあります。

RFC 9293でも、輻輳制御がTCPに必要な機能であることが示されています。

TCPでは長年にわたって、多数の輻輳制御・損失回復アルゴリズムが開発されてきました。

UDPには輻輳制御がない？

UDPそのものには、TCPのような組み込みの輻輳制御機構はありません。

しかし、

「UDPを使うアプリは好きなだけデータを送ってよい」

という意味ではありません。

IETFのRFC 8085「UDP Usage Guidelines」では、インターネットの安定した運用には輻輳制御が重要であり、UDPを利用するアプリケーションやプロトコルも、ネットワークの輻輳を悪化させない仕組みを備える必要があるとしています。

HTTP/3で利用するQUICも、UDP上に独自の輻輳制御を実装しています。

HTTP/1.1・HTTP/2とTCPの関係

従来のWeb通信では、TCPが非常に重要な役割を担ってきました。

HTTP/1.1やHTTP/2は通常、

TCP

上で通信します。

HTTP/2では1本のTCP接続上に複数のストリームを作り、複数のHTTPリクエスト・レスポンスを多重化できます。

しかし、すべてのストリームが同じTCP接続を共有するため、TCPパケットの損失によって複数ストリームが一時的に待たされる、

Head-of-Line Blocking

という問題が残りました。

HTTP/3はなぜUDPを使う？

HTTP/3では、TCPではなく、

QUIC

を利用します。

QUICはIETFのRFC 9000で標準化されたトランスポートプロトコルで、

UDPデータグラム上で通信します。

しかし重要なのは、

HTTP/3がUDPの機能だけで通信しているわけではない

という点です。

QUIC自身が、

• 接続管理
• 損失検出
• 再送
• フロー制御
• 輻輳制御
• 複数ストリーム
• 暗号化

などの仕組みを提供します。

「UDPは信頼性がないのにHTTP/3は大丈夫？」

問題ありません。

HTTP/3が必要とする信頼性は、UDPそのものではなく、

UDP上のQUIC

が提供します。

RFC 9114では、HTTP/3がQUICを利用することで、

• 信頼性のあるストリーム単位の配送
• 複数ストリーム
• フロー制御
• 暗号化

などを利用すると規定されています。

つまり、

UDPを土台として、その上にHTTPに必要な高度な通信機能をQUICが構築している

のです。

QUICはUDPなの？

より正確には、

QUICはUDP上で動作する独立したトランスポートプロトコル

です。

RFC 9000では、QUICを、

UDP-Based Multiplexed and Secure Transport

として規定しています。

QUIC自身はコネクション型で、クライアントとサーバーの間に状態を持つ接続を作ります。

そのため、

「UDPがコネクションレスだからQUICもコネクションレス」

ではありません。

TCPとUDPはどちらが安全？

TCPとUDPだけを比較して、

「こちらのほうがセキュリティが高い」

と単純には決められません。

TCPの信頼性は、

データを正しく配送する

ための仕組みであり、通信内容を第三者から秘密にする暗号化とは別です。

たとえばTCP上で通信していても、TLSを使用しなければ通信内容が暗号化されない場合があります。

反対にQUICはUDPを基盤としていますが、TLS 1.3を統合して安全な通信を実現します。

したがって、

通信の信頼性と、通信のセキュリティは別々に考える必要があります。

TCPとUDPは両方ともポート番号を使う？

はい。

TCPもUDPもポート番号を利用します。

ただし、

TCPのポート番号空間

と、

UDPのポート番号空間

は別に扱われます。

そのため、同じ「443番」であっても、

TCP 443

と、

UDP 443

では異なる通信です。

たとえば、

HTTPSのHTTP/2 → TCP 443

HTTP/3・QUIC → UDP 443

が一般的です。

TCPとUDPは同時に使える？

使えます。

1つのサービスやアプリケーションが、用途に応じてTCPとUDPの両方を利用することがあります。

たとえば、

• 重要なデータはTCP相当の信頼性がある経路
• リアルタイム更新はUDP

のように役割を分ける設計も可能です。

またHTTP/3へ対応するWebサイトでは、

• HTTP/3用のUDP
• HTTP/2等へフォールバックするTCP

の両方を利用できる構成が一般的です。

「TCP・UDP」で迷ったときの3秒判定

こんな場合	答え
接続を確立してから通信する	TCP
コネクションレスで送信する	UDP
データの到達・順序をプロトコル側で管理	TCP
失われたデータを自動再送しない	UDP
バイトストリーム	TCP
データグラム	UDP
HTTP/2の主な基盤	TCP
QUICの基盤	UDP
HTTP/3	UDP上のQUIC

最も簡単に覚えるなら、

TCP＝「確認しながら確実に運ぶ」

UDP＝「まず送る。必要な制御は上位で考える」

です。

「TCP」を使った例文

• WebサーバーとTCP接続を確立する。
• TCPで失われたデータを再送する。
• TCPはデータを正しい順序でアプリケーションへ渡す。
• HTTP/2は通常TCP上で利用される。
• TCPの3ウェイハンドシェイクで接続を開始する。

「UDP」を使った例文

• リアルタイム通信にUDPを利用する。
• UDPデータグラムを送信する。
• UDP自体には配送保証がない。
• QUICはUDP上で動作する。
• HTTP/3ではUDPを基盤とするQUICを利用する。

具体例で比較：ファイルを送る

100MBの重要なファイルを相手へ送るとします。

ファイルの途中が1バイトでも欠ければ、元のファイルと一致しなくなる可能性があります。

この場合、

• 損失を検出する
• 欠けた部分を再送する
• 正しい順番でデータを並べる

という処理が重要です。

TCPはこうした信頼性をプロトコルとして提供するため、ファイル転送のような用途と相性があります。

具体例で比較：オンラインゲームの位置情報

オンラインゲームで、プレイヤーの現在位置を1秒間に何十回も送信するとします。

古い位置情報が1回失われても、すぐ後に最新の位置情報が届くなら、古い情報を再送するより、

最新情報をすぐ処理する

ほうが重要な場合があります。

このようなリアルタイム性重視のデータではUDPが選ばれることがあります。

具体例で比較：Webページを開く

HTTP/2でWebサイトへアクセスする場合、ブラウザとサーバーは通常TCP接続を利用します。

TCPがHTTPデータを、

• 信頼性を保って
• 順序どおりに

運びます。

一方HTTP/3ではTCPを利用せず、UDP上で動作するQUICを使います。

QUICがHTTPに必要な信頼性、暗号化、複数ストリームなどを提供します。

よくある間違い1：「TCPなら絶対にデータが届く」と思う

TCPは信頼性の高い通信を提供しますが、ネットワークが完全に切断されればデータを届けられないことがあります。

届けられない場合にエラーとして検出できることもTCPの重要な性質です。

よくある間違い2：「UDPなら必ずTCPより速い」と思う

UDPはTCPよりシンプルですが、実際の速度は回線・用途・実装等によって変わります。

必要な信頼性をアプリ側で実装すれば、その分の処理も必要です。

よくある間違い3：「UDPにはエラーチェックが一切ない」と思う

UDPにはチェックサムがあります。

ただし、パケット損失時の再送や順序保証をUDP自身が提供するわけではありません。

よくある間違い4：「リアルタイム通信は全部UDP」と思う

用途によります。

リアルタイム通信でも利用するプロトコルや要件によってTCP系の通信を使う場合があります。

逆にWeb通信でも、HTTP/3のようにUDPを基盤としたQUICを使う例があります。

よくある間違い5：「UDPは信頼性がないのでHTTP/3も信頼性がない」と思う

HTTP/3ではUDPの上にQUICがあります。

QUICが損失回復・ストリーム・輻輳制御などを提供するため、HTTPに必要な信頼性を確保できます。

よくある間違い6：「TCPは安全、UDPは危険」と思う

TCPの信頼性と暗号化によるセキュリティは別です。

TCPでも暗号化なしなら通信内容を保護できません。

UDP上のQUICのように暗号化を統合したプロトコルもあります。

よくある間違い7：「UDPなら輻輳制御を考えなくてよい」と思う

UDP自身にはTCPのような輻輳制御がありませんが、インターネット上でUDPを利用するアプリケーションには適切な輻輳制御が必要です。

IETFのRFC 8085でも重要な要件として示されています。

「TCP」と「UDP」に関するよくある質問

Q1. 「TCP」と「UDP」の一番簡単な違いは？

TCPはデータの信頼性・順序をプロトコル側で管理し、UDPは最低限の仕組みでデータグラムを送るという違いがあります。

Q2. TCPとUDPではどちらが速いですか？

一律には決められません。

UDPは接続確立・再送・順序制御等を標準では行わないためオーバーヘッドが小さい一方、アプリケーションが必要な機能を追加すれば処理は増えます。

実際の性能は用途・回線・実装によって異なります。

Q3. TCPではデータが順番どおり届きますか？

アプリケーションには正しい順序のバイトストリームとして渡されます。

ネットワーク上で到着順が入れ替わってもTCPが並び替えます。

Q4. UDPでは順番が入れ替わることがありますか？

あります。

UDP自体はデータグラムの配送順序を保証しません。

Q5. UDPではパケットが失われたらどうなりますか？

UDP自身は自動再送しません。

再送が必要なら、アプリケーションやUDP上の別プロトコルで対応します。

Q6. TCPとUDPはどちらもポート番号を使いますか？

はい。

ただしTCPとUDPでは別々のポート番号空間として扱われます。

Q7. HTTPはTCPとUDPのどちらを使いますか？

バージョンによります。

HTTP/1.1やHTTP/2では主にTCPを利用します。

HTTP/3ではUDPを基盤としたQUICを利用します。

Q8. QUICとUDPは同じですか？

同じではありません。

UDPは基本となるトランスポートプロトコルで、QUICはUDPデータグラム上に、信頼性・複数ストリーム・輻輳制御・暗号化などを実装した別のトランスポートプロトコルです。

Q9. オンラインゲームはUDPを使いますか？

UDPを利用するゲームは多くありますが、すべての通信をUDPだけで行うとは限りません。

ゲームの設計やデータの重要性に応じて、複数の通信方式を使い分ける場合があります。

Q10. TCPとUDPのどちらを選べばよいですか？

用途によります。

データの欠落が許されず、順序どおりに確実に扱いたい場合はTCPが適しています。

リアルタイム性を優先したい場合や、アプリケーション側で独自の配送制御を行いたい場合にはUDPが適することがあります。

「どちらが優秀か」ではなく、必要な通信特性で選ぶことが重要です。

まとめ

「TCP」と「UDP」は、どちらもインターネットで重要なトランスポートプロトコルですが、設計思想が大きく異なります。

TCP	UDP
Transmission Control Protocol	User Datagram Protocol
コネクション型	コネクションレス型
信頼性のある通信	配送を保証しない
正しい順序で渡す	順序を保証しない
損失時に再送	UDP自身は再送しない
バイトストリーム	データグラム
基本ヘッダー最低20バイト	基本ヘッダー8バイト

最も簡単な覚え方は、

TCP＝「確認しながら、正しく順番どおり届ける」

UDP＝「最低限の仕組みでデータを送る」

です。

TCPでは、

• 接続確立
• シーケンス番号
• 確認応答
• 再送
• 順序制御
• フロー制御
• 輻輳制御

などを利用し、信頼性の高い通信を提供します。

一方UDPは、これらの多くをUDP自身では提供しません。

そのため、低遅延を重視するリアルタイム通信などで利用しやすい一方、必要な信頼性や輻輳制御は上位のプロトコル・アプリケーションで考える必要があります。

また、

TCP＝遅い

UDP＝速い

とだけ覚えるのは正確ではありません。

より重要なのは、

TCP＝信頼性に必要な多くの機能をTCP自身が提供する

UDP＝最低限の機能だけを提供し、必要な制御を上位へ任せる

という違いです。

HTTPとの関係では、

HTTP/2 → 主にTCP

HTTP/3 → QUIC

QUIC → UDPを基盤として動作

と整理すると理解しやすいでしょう。

HTTP/3がUDPを利用できるのも、UDPそのものにHTTPの信頼性を任せているからではありません。

QUICがUDPの上に、

• 信頼性
• 損失回復
• 複数ストリーム
• 輻輳制御
• TLSによるセキュリティ

などを実装しているからです。

TCPとUDPは「どちらが優れているか」を競う技術ではなく、

求める通信特性に合わせて使い分けるプロトコル

と理解するのが最も重要です。

参考リンク・出典

• IETF / RFC Editor「RFC 9293: Transmission Control Protocol (TCP)」
  ― 現在のTCP基本仕様。TCPを信頼性があり順序どおりのバイトストリームサービスとして定義し、シーケンス番号、チェックサム、再送、接続などTCPの基本機能を規定
• IETF / RFC Editor「RFC 768: User Datagram Protocol」
  ― UDPの基本仕様。UDPを最小限のプロトコル機構によるデータグラム通信として規定し、配送・重複防止を保証しないことやUDPヘッダーの構造を説明
• IETF / RFC Editor「RFC 8085: UDP Usage Guidelines」
  ― UDPを利用するアプリケーション・プロトコル向けのBest Current Practice。輻輳制御、信頼性、メッセージサイズ、チェックサムなどUDP利用上の注意点を解説
• MDN Web Docs「UDP（User Datagram Protocol）」
  ― UDPのコネクションレス通信、到達・順序・重複防止の非保証、リアルタイム用途でUDPが利用される理由などを解説
• IETF / RFC Editor「RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport」
  ― QUICをUDPベースの多重化された安全なトランスポートプロトコルとして規定。ストリーム、フロー制御、接続、暗号化、ネットワークパス変更への対応などを解説
• IETF / RFC Editor「RFC 9114: HTTP/3」
  ― HTTP/3をQUIC上で動作するHTTPとして規定し、QUICによる信頼性のあるストリーム単位の配送、HTTP/2との違い、UDP通信が利用できない場合のTCP系HTTPへのフォールバックなどを説明

※本記事では一般ユーザー向けに、「TCP＝信頼性・順序制御をプロトコル側で提供」「UDP＝最小限のデータグラム配送を提供」と整理しています。

※「TCPは必ず届く」という表現は、ネットワーク障害があっても無条件に配送できるという意味ではありません。TCPは損失検出・再送等によって信頼性を提供し、通信不能の場合には接続エラーとして扱います。

※「UDPは速い」「TCPは遅い」という単純な比較はできません。実際の性能はネットワーク品質、アプリケーション、輻輳制御、再送方式、実装等によって異なります。

※UDPそのものにはTCPのような組み込みの輻輳制御はありませんが、UDPをインターネット上で利用するアプリケーション・上位プロトコルにも適切な輻輳制御が求められます。

※HTTP/3はUDPだけで信頼性のあるHTTP通信を実現しているわけではありません。UDP上で動作するQUICが損失回復、ストリーム、フロー制御、輻輳制御、TLSによるセキュリティなどを提供します。