インフラエンジニアが知っておくべきTCPとUDPの違い｜通信プロトコル選定の判断基準
TCPとUDPはインフラエンジニアの基礎知識
ネットワークの基礎を学び始めた方が最初に詰まるのが「TCPとUDPの違い」です。私が講師を始めた当初、この2つの違いを「信頼性の有無」とだけ説明していましたが、それだけでは現場で応用できません。実際にどう使い分けるか、を含めてお伝えします。
TCPとは：信頼性を保証するプロトコル
TCP（Transmission Control Protocol）はデータの信頼性を保証するトランスポート層のプロトコルです。以下の仕組みで確実なデータ転送を実現します。
- 3ウェイハンドシェイク：通信前にSYN・SYN-ACK・ACKで接続を確立する
- 順序制御：分割されたパケットを正しい順序で並べ直す
- 再送制御：パケットが届かなかった場合に自動で再送する
- フロー制御・輻輳制御：受信側の処理能力やネットワーク状況に合わせて送信量を調整する
これらの仕組みにより、TCPは「必ずデータが届く」ことを保証しますが、その分オーバーヘッドが生じます。
UDPとは：速さを優先するプロトコル
UDP（User Datagram Protocol）はTCPとは対照的に、確認応答・再送・順序制御を行わないシンプルなプロトコルです。
- 接続確立のオーバーヘッドがない
- ヘッダが小さく処理が軽い
- データが届かなくても再送しない
「信頼性がないなら使えないのでは？」と思うかもしれませんが、実はUDPのほうが適しているケースが多くあります。
現場での使い分け：どちらを選ぶべきか
実際の現場でよく使われるプロトコルをTCP・UDP別に整理します。
TCPを使うプロトコル
- HTTP/HTTPS（Webサイトの閲覧）
- SSH（サーバーへのリモートアクセス）
- FTP（ファイル転送）
- SMTP/POP3/IMAP（メール送受信）
UDPを使うプロトコル
- DNS（名前解決 ※大きなレスポンスはTCPも使用）
- DHCP（IPアドレスの自動割り当て）
- NTP（時刻同期）
- 動画ストリーミング・VoIP（多少のデータ欠損より遅延のなさを優先）
- SNMP（ネットワーク機器の監視）
講師として見ていると、「DNSはUDPだと思っていたらTCPも使う」という部分でよく混乱が生じます。DNSはデフォルトでUDPポート53を使いますが、レスポンスが512バイトを超える場合はTCPに切り替わります。
ウェルノウンポート番号も合わせて覚えよう
TCPとUDPを理解したら、主要なポート番号もセットで覚えましょう。インフラの設計や障害対応で毎日使う知識です。
- HTTP：TCP 80 / HTTPS：TCP 443
- SSH：TCP 22 / FTP：TCP 20,21
- DNS：UDP/TCP 53
- DHCP：UDP 67（サーバー）/ 68（クライアント）
- NTP：UDP 123
- SNMP：UDP 161
まとめ：用途に応じた使い分けがエンジニアの判断力
TCPは「確実に届けたいデータ」、UDPは「速さを優先したいデータ」に使います。この判断基準を持っておくと、ファイアウォールの設定やトラブルシューティングの際にも役立ちます。CCNAやLinuCの試験にも頻出の知識ですので、しっかり押さえておきましょう。
UDPが使われる理由：速さが信頼性より重要な場面
UDPは接続確立・再送制御・順序保証を行いません。そのため処理速度が速く、リアルタイム性が求められる場面で使われます。
- 動画ストリーミング：1フレームが遅延するよりも、多少欠けても速く届く方が視聴体験が良い
- VoIP（音声通話）：わずかな遅延も体感に影響するため、再送より速度を優先
- DNS：クエリが小さく、応答が来なければ再送するのはアプリ側で処理できる
- NTP（時刻同期）：定期的な送信で精度を保てるため信頼性制御は不要
- SNMP（ネットワーク監視）：大量のポーリングを効率よく行うためUDPを使用
TCPとUDPのポート番号：現場でよく使う代表例
ポート番号とプロトコルの対応はインフラエンジニアとして必須の知識です。ファイアウォール設定・Nmap・パケットキャプチャの解析でも使います。
| ポート番号 | プロトコル | TCP/UDP |
|---|---|---|
| 22 | SSH | TCP |
| 25 | SMTP | TCP |
| 53 | DNS | UDP（主）/ TCP |
| 80 | HTTP | TCP |
| 123 | NTP | UDP |
| 161 | SNMP | UDP |
| 443 | HTTPS | TCP |
| 3389 | RDP | TCP |
3ウェイハンドシェイクの詳細とトラブルシューティング
TCPの接続確立（3ウェイハンドシェイク）を理解しておくと、接続トラブルの原因切り分けに役立ちます。
- SYN：クライアントがサーバーに接続要求を送信
- SYN-ACK：サーバーが受け入れを通知し、自身の接続要求も送信
- ACK：クライアントがサーバーの接続要求を確認
接続できない場合、tcpdumpやWiresharkでキャプチャしてSYNが送れているか・SYN-ACKが返ってくるかを確認することで、ファイアウォールのブロック・サービス未起動・ルーティングの問題を切り分けられます。
まとめ：TCP/UDPの使い分けの判断基準
- TCPを使う：データの完全性が重要（Webアクセス・ファイル転送・SSH・メール）
- UDPを使う：速度・リアルタイム性が重要（動画・音声・DNS・NTP・SNMP）
TCPとUDPは「どちらが優れているか」ではなく「用途に応じた選択」の問題です。インフラエンジニアとして、ポート番号とプロトコルの対応、3ウェイハンドシェイクの流れを体系的に押さえることで、ネットワークトラブルの原因切り分け精度が大きく向上します。
tcpdumpでTCP・UDPパケットを確認する
実際のパケットをキャプチャして確認することで、TCP/UDPの動作を体感的に理解できます。Linuxのtcpdumpコマンドを使った基本的な確認方法を紹介します。
# TCPのパケットをキャプチャ（SSH接続など）
tcpdump -i eth0 tcp port 22
# UDPのDNSクエリをキャプチャ
tcpdump -i eth0 udp port 53
# 3ウェイハンドシェイクを確認（SYN・SYN-ACK・ACK）
tcpdump -i eth0 tcp port 80 -S
# 特定ホストのパケットのみ表示
tcpdump -i eth0 host 192.168.1.100
# キャプチャをファイルに保存してWiresharkで解析
tcpdump -i eth0 -w capture.pcap
現場でtcpdumpを使いこなせると、「どこまでパケットが届いているか」「SYNを送っているのにSYN-ACKが返ってこない」という切り分けが即座にできます。インフラエンジニアとして一段上のスキルセットになります。
HTTP/2・QUICとTCP/UDP：最新プロトコルの動向
近年のWebプロトコルの進化もTCP/UDPに関係しています。
- HTTP/2：TCPベース。多重化・ヘッダ圧縮でHTTP/1.1の問題を解消
- HTTP/3（QUIC）：UDPベース。TCPのハンドシェイクの遅延を解消するためにGoogleが開発したQUICプロトコルを採用。現在主要なWebサービスで採用が進んでいる
「UDPは信頼性がない」という固定観念を超えて、アプリケーション層で信頼性制御を実装する方向に進化しています。HTTP/3はその代表例であり、インフラエンジニアとして知っておくべきトレンドです。
AWS・クラウドにおけるTCP/UDPの設定ポイント
AWSのセキュリティグループ・ネットワークACLでは、TCP/UDPとポート番号を組み合わせてトラフィックを制御します。
- セキュリティグループのインバウンドルール例：SSH（TCP 22）・HTTP（TCP 80）・HTTPS（TCP 443）・DNS（UDP 53）
- ステートフルとステートレスの違い：セキュリティグループはステートフル（戻りのトラフィックを自動許可）、ネットワークACLはステートレス（インバウンド・アウトバウンド両方の設定が必要）
この違いを理解していないと、「ポートを開けたのに繋がらない」というトラブルが発生します。AWS環境での設計では必須の知識です。
