TCPとUDPの違いは？信頼性・通信単位・QUICを比較

ひよこ

TCPは正確、UDPは速いって覚えればいい？

ペンギン先生

少し足りないね。TCPは再送や順序制御のあるバイトストリームを提供し、UDPはデータグラム単位で送る。UDP自体には再送や順序保証がないけれど、必ずTCPより速いという保証もないんだ。

ひよこ

TCPなら絶対に届くの？

ペンギン先生

失われたデータを再送し、順序を整えて渡そうとするけれど、回線断などで通信が失敗することはあるよ。またTCPで届いたことと、相手のアプリが処理や保存に成功したことも別。業務上の成功にはアプリの応答が必要なんだ。

ひよこ

送った1回分をそのまま受信する？

ペンギン先生

TCPはバイトの列なので、送信した呼び出しの区切りがそのまま受信側に渡るとは限らないよ。長さや区切り文字など、アプリでメッセージの境界を決める必要がある。UDPはデータグラムの境界を保つけれど、欠落や順序の入れ替わりなどは起こりうるんだ。

ひよこ

UDPでは届かなかったらどうする？

ペンギン先生

アプリや上位プロトコルで決めるよ。古い位置情報は捨てて新しいものを使う方法もあれば、再送や応答確認を付ける方法もある。データの重要度や期限で考えよう。UDPを使うから何も対策しなくてよいわけではないね。

ひよこ

ゲームや動画は全部UDP？

ペンギン先生

サービスや機能ごとに違うよ。リアルタイム音声とファイルの取得では必要な性質が異なるし、HTTP/3はUDP上のQUICで信頼性のある通信を行う。用途名だけでTCPかUDPかを断定しないほうがいいね。

ひよこ

DNSは512バイトを超えるとTCP？

ペンギン先生

従来の制限だけを見るとそう思いやすいけれど、EDNSでより大きなUDP応答を扱えるよ。DNSはTCPにも対応し、応答が切り詰められた場合などに使う。512バイトだけを一律の切り替え条件として覚えないでね。

ひよこ

QUICはUDPなのにどうやって信頼性を持つ？

ペンギン先生

QUICが暗号化や再送、ストリームの管理などを実装するんだ。複数ストリーム間で、TCPの一つのバイト列による待ち合わせを避けられる。ただし同じパケットに入っていたデータの欠落や、接続全体の混雑の影響まで消えるわけではないよ。

ひよこ

新しい通信を作るならどう選ぶ？

ペンギン先生

必要な順序、欠落時の処理、メッセージ境界、混雑への配慮、暗号化、ネットワークの対応を確認する。独自UDPで必要な機能を作り直すより、HTTPやQUICなど既存の上位プロトコルを使えるかも検討しよう。

通信の性質を比較

小さいヘッダーは一つの性質であり、通信全体の速度や遅延の保証ではありません。TCPの上にTLSを使うHTTPSと、QUICを使うHTTP/3など、上位の仕組みも含めて比較します。

「1回の送信＝1回の受信」ではない例

TCPでABCとDEFを別々に書き込んでも、受信側がABCDEFをまとめて読むことや、一部分ずつ読むことがあります。アプリは読み取った長さを確認し、必要なデータがそろうまで処理します。

UDPでも巨大なデータグラムを送ればよいわけではありません。経路MTUや断片化、損失、輻輳への配慮が必要です。アプリが「処理済み」を保証したい場合は、TCP・UDPどちらでも処理IDや結果の確認を設計してください。

参考資料

確認日：2026年9月27日。製品の仕様・料金・対応環境は導入時にも確認してください。

• RFC 9293: TCP：信頼性・順序付きバイトストリーム・ヘッダー。
• RFC 768: UDP：データグラム、ヘッダー、再送保証の欠如。
• RFC 7766: DNS over TCP：DNSのTCP対応と切り詰めへの対応。
• RFC 6891: EDNS：512バイトを超えるUDP応答。
• RFC 9000: QUIC：ストリームと損失・輻輳の関係。