こんにちは、かつコーチです。
前回はOSI参照モデルで通信全体の地図を確認し、トランスポート層（第4層）にTCPとUDPが登場することを紹介しました。
今回はそのトランスポート層の主役であるTCPとUDPを掘り下げ、何が違い、どう使い分けられているのかを解説します。
TCPとUDPとは？
対面の会話 vs 一方的な放送という比喩
TCP（Transmission Control Protocol）は、対面での会話に似ています。
「聞こえましたか」「はい、聞こえました」と、お互いに確認を取りながら話を進めるイメージです。
一方のUDP（User Datagram Protocol）は、ラジオやテレビの放送に似ています。
放送局は聞き手の反応を待たずに、内容を一方的に送り続けます。
第3層（ネットワーク層）のIPが「宛先までデータを届ける」役割だとすれば、第4層のTCP・UDPは「届いたかどうかをどう扱うか」を決める役割です。
なぜ2つのプロトコルが使い分けられているのか
会話のように確認を取り合えば、聞き逃しがあってもすぐに聞き返せて確実です。
その代わり、確認のやり取りが増える分、時間もかかります。
放送のように一方的に送り続ければ、確認の手間がない分スピードは出ますが、聞き逃した内容は基本的に取り戻せません。
「確実さ」と「スピード」はトレードオフの関係にあり、通信の目的に応じてTCPとUDPが使い分けられています。
TCPの仕組み：確実性を重視した通信
3ウェイハンドシェイクと再送制御
TCPが会話のように「確実」なのは、通信を始める前に3ウェイハンドシェイクと呼ばれる3回のやり取りで、お互いの準備ができているかを確認しているからです。
- クライアントが「通信を始めたい」と伝える（SYN）
- サーバーが「了解、準備できている」と応答する（SYN/ACK）
- クライアントが「では始めます」と最終確認する（ACK）
通信中も、データが届くたびに受信側が「ここまで受け取った」と確認応答を返し、届いていないデータがあれば送信側が自動的に再送します。
この仕組みのおかげで、データの欠落や順序の入れ替わりが起きにくくなっています。
TCPが向いているケース
確認を取り合いながら進める分、TCPは「1文字も欠けてはいけない」通信に向いています。
- Webページの表示（HTTP/HTTPS）
- メールの送受信
- ファイルのダウンロード
これまでの記事で扱ってきたHTTP通信も、内部ではTCPの上で動いています。
UDPの仕組み：スピードを重視した通信
コネクションレスとその代償
UDPには3ウェイハンドシェイクのような事前準備がなく、いきなりデータを送り始めます。
こうした接続の確立を行わない性質をコネクションレスと呼びます。
確認応答や再送の仕組みも持たないため、途中でデータが欠けても、UDP自身はそれを検知して直したりはしません。
その代わり、確認のやり取りがない分だけ、TCPよりも低い遅延で通信できます。
UDPが向いているケース
多少のデータ欠落があっても全体としては成立し、それよりも「今すぐ届くこと」が重要な通信にUDPは向いています。
- リアルタイムのオンラインゲーム
- ビデオ通話・ライブ配信
- DNSの問い合わせ（第7回・第8回で解説）
DNSの問い合わせにUDPが使われているのは、リクエストとレスポンスが小さく、確認応答のオーバーヘッドをかけるより速さを優先した方が都合がよいからです。
よくあるつまずきポイント・比較で迷うポイント
プロトコル選択で遅延に悩んだ経験
以前、業務用の在庫管理システムでリアルタイム通知機能を実装した際、最初はTCPベースのWebSocketで実装していました。
通知件数が増えたときに、確認応答の待ち時間が積み重なって通知の反映に遅れが出るという相談を受けたことがあります。
❌Before：すべての通知をTCP（確実性優先）で送る
→ 確認応答の待ちが積み重なり、大量通知時にラグが発生
✅After：通知が多少欠けても支障がない用途はUDPベースの仕組みに切り替え
→ 各通知を独立して即時送信し、体感の遅延を大幅に削減
このとき初めて、「確実に届けたいデータ」と「多少欠けても構わないデータ」を仕分けて設計する重要性を実感しました。
比較の軸をまとめると、以下のようになります。
| TCP | UDP | |
|---|---|---|
| 接続 | 事前に確立する（コネクション型） | 確立しない（コネクションレス） |
| 確認応答・再送 | あり | なし |
| 速度 | UDPより遅い | 速い |
| 向いている用途 | Web、メール、ファイル転送 | 動画配信、ゲーム、DNS |
応用・一歩先の使い方
QUICが実現する「速いのに確実」な通信
近年は、UDPをベースにしながら独自の仕組みで信頼性を確保するQUICというプロトコルが登場しています。
これは前回のHTTPS編で触れたHTTP/2の次世代にあたるHTTP/3の基盤になっている技術です。
QUICはUDPの速さを活かしつつ、TCPのような確認応答・再送の仕組みをアプリケーション側で独自に実装することで、「速いのに確実」という両立を目指しています。
TCPかUDPかという単純な二択だけでなく、こうした新しいアプローチが登場していることも覚えておくと理解が深まります。
まとめ
この記事のポイント
- TCPは「対面の会話」のように確認応答と再送で確実性を確保する通信方式
- UDPは「一方的な放送」のように確認応答を持たず、速度を優先する通信方式
- HTTP・メールはTCP、動画配信・ゲーム・DNSはUDPというように、目的に応じて使い分けられている
- QUICのように、UDPをベースに信頼性を補う新しいアプローチも登場している
次に読むべき記事
- pingとtracerouteでネットワークの疎通を調べる
- ネットワークトラブルシューティングの基本の流れ
タグ: ネットワーク, 中級者向け, 通信の仕組み