多くのネットワークシステムでは、通信方式としてTCPとUDPのどちらも選択できます。かつては信頼性の高さからTCPが主流でしたが、近年はUDPを採用するケースが明らかに増えています。私自身の経験でも、「TCPを選べるのに、最終的にUDPが選ばれる」という場面が増えてきました。 その背景には、現代の通信要件やアプリケーションの性質が大きく変化したことがあります。この記事では、TCPとUDPの概念的な違いを整理しつつ、なぜ“選択肢があるのにUDPが優勢になったのか”を解説します。
TCPとUDPの基本的な違い
TCPとUDPはどちらもトランスポート層のプロトコルですが、設計思想が大きく異なります。
TCP(Transmission Control Protocol)
- コネクション型で、通信前に接続を確立します。
- 再送制御、順序保証、輻輳制御などを備え、信頼性が高いです。
- その分オーバーヘッドが大きく、遅延が増えやすい特徴があります。
- 「確実に届けること」を最優先するプロトコルです。
UDP(User Datagram Protocol)
- コネクションレスで、接続確立を行いません。
- 再送や順序保証を持たず、非常に軽量です。
- 遅延が少なく、リアルタイム性に優れています。
- 「速さと軽さ」を最優先するプロトコルです。
どちらも用途によって使い分けられますが、現代ではUDPが選ばれる場面が増えています。
なぜ“選択肢があるのに”UDPが優勢になったのか
TCPとUDPのどちらも使える状況で、なぜUDPが選ばれるのでしょうか。 その理由は、現代の通信要件とアプリケーションの性質がTCPよりUDPに適しているためです。
1. TCPは“丁寧すぎて”スタックしやすい
TCPは信頼性を確保するために多くの機能を持っています。
- 3ウェイハンドシェイク
- 再送制御
- 輻輳制御
- ACKのやり取り
- 順序保証
これらは便利ですが、ネットワークが混雑すると一気に詰まりやすい(スタックしやすい)という弱点があります。 リアルタイム性が求められる場面では、この“丁寧さ”が逆に問題になります。
2. UDPはアプリ側で自由に制御できる
UDPは最低限の機能しか持たないため、アプリケーション側で必要な制御を実装できます。
- 再送するかどうか
- 順序保証をどこまで行うか
- ロスをどこまで許容するか
- 独自の輻輳制御を入れるか
つまり、アプリケーションが賢くなった現代では、TCPの自動制御がむしろ邪魔になることがあります。
3. 動画・音声・ゲームなどリアルタイム通信が主流になった
現代の主要トラフィックはリアルタイム系です。
- 動画配信
- 音声通話
- オンラインゲーム
- IoT
- ストリーミング
これらは「多少のロスより遅延の少なさ」が重要です。 TCPの再送は遅延を生むため、UDPのほうが圧倒的に向いています。
4. QUIC(HTTP/3)によりWebすらUDPベースへ
Googleが開発したQUICは、UDP上でTCP的な信頼性を実現する新プロトコルです。
- 0-RTT
- 独自の再送制御
- ヘッドオブラインブロッキングなし
- マルチプレックス
これにより、Web通信そのものがUDPベースに移行し始めています。 「Web=TCP」という前提が崩れつつあります。
5. 現場では「スタックしないUDP」が扱いやすい
私の経験でも、最終的にUDPが選ばれる理由は次の一点に集約されます。
TCPはスタックしますが、UDPはスタックしません。
TCPは混雑時に速度を落とす輻輳制御を持つため、詰まりやすいです。 UDPは輻輳制御を持たないため、アプリ側で最適化できます。 結果として、大規模・リアルタイム・高負荷のシステムほどUDPが選ばれるようになりました。
まとめ

- 多くのシステムではTCPとUDPのどちらも選択できます。
- しかし現代の通信要件は、軽量で遅延が少ないUDPに適しています。
- TCPは信頼性が高い一方で、混雑時にスタックしやすいという弱点があります。
- UDPはアプリ側で制御でき、リアルタイム通信に強く、扱いやすいです。
- QUICの登場により、Web通信すらUDPベースへ移行しています。
- その結果、「選択肢があるのにUDPが優勢になる」という状況が生まれています。

HR