TCP/UDP違いを比較表で徹底解説｜ポート番号・コマンド確認・使い分けまとめ

TCPとUDPは、OSI参照モデルのトランスポート層（第4層）で動作するプロトコルです。

Webサーバー構築・ファイアウォール設定・VPN設計・ネットワークトラブルシューティングなど、インフラエンジニアが日常的に扱う場面で必ず登場します。

「なんとなくわかっているけど、設計書や面接で正確に説明できるか不安」という方も多いはずです。

この記事では、基本概念から実務で使うコマンド・ポート番号まで体系的に整理します。

TCPとUDPの基本と仕組み

TCP（Transmission Control Protocol）の仕組み

TCPはコネクション型プロトコルです。データ送信前に必ず「3ウェイハンドシェイク」で接続を確立し、送達確認（ACK）と再送制御によってデータの確実な到達を保証します。

3ウェイハンドシェイクの流れ：① SYN（接続要求）→ ② SYN-ACK（受諾）→ ③ ACK（確認）。この3ステップで接続が確立されてからデータ転送が始まります。

UDP（User Datagram Protocol）の仕組み

UDPはコネクションレス型プロトコルです。ハンドシェイクなしでデータグラムを送りつけるだけなので、オーバーヘッドが極めて小さく、低遅延を実現します。ただし送達保証・順序保証・再送制御は一切ありません。

UDPでは送達確認が不要な分、ヘッダサイズはわずか8バイト（TCPは最小20バイト）。この差がリアルタイム通信での応答速度に直結します。

TCP/UDP 詳細比較表

主要プロトコルとポート番号一覧

ファイアウォール設定やACL作成時に必須となる、代表的なポート番号を整理します。

TCP：主要ウェルノウンポート

UDP：主要ウェルノウンポート

DNS（ポート53）はUDPを基本としますが、応答サイズが512バイトを超える場合（DNSSECなど）や、ゾーン転送（AXFR）にはTCP 53を使用します。ファイアウォールでDNSを許可する際は両方を考慮してください。

コマンドでTCP/UDP接続状態を確認する

実際のトラブルシューティングでは、現在の接続状態やリスニングポートをコマンドで確認することが基本です。

Windows：netstatコマンド

# すべての接続とリスニングポートを表示（PID付き）
netstat -ano

# 特定ポートで絞り込む（例：443番ポート）
netstat -ano | findstr ":443"

# TCPのみ表示
netstat -ano -p TCP

# UDPのみ表示
netstat -ano -p UDP

出力例：

Proto  Local Address          Foreign Address        State        PID
TCP    0.0.0.0:443            0.0.0.0:0              LISTENING    4
TCP    192.168.1.10:54321     93.184.216.34:443      ESTABLISHED  1234
UDP    0.0.0.0:123            *:*                                 1056

Windows：PowerShellコマンド

# ESTABLISHED状態のTCP接続一覧
Get-NetTCPConnection | Where-Object State -eq "Established" | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State

# リスニング中のTCPポート一覧
Get-NetTCPConnection | Where-Object State -eq "Listen" | Select-Object LocalPort,State | Sort-Object LocalPort

# UDPエンドポイント一覧
Get-NetUDPEndpoint | Select-Object LocalAddress,LocalPort | Sort-Object LocalPort

Linux：ssコマンド（推奨）

ssはnetstatの後継コマンドです。カーネルから直接情報を取得するためより高速で、詳細なフィルタリングが可能です。

# TCP・UDP・プロセス名・数値表示（よく使う組み合わせ）
ss -tunap

# ESTABLISHED状態のTCP接続のみ
ss -tnp state established

# 特定ポートで絞り込む（例：80番）
ss -tnp | grep ':80'

# リスニング中のポート一覧
ss -tlnp

CentOS 7以降・Rocky Linux・Ubuntu 20.04以降ではnetstatがデフォルトで入っていない場合があります。ssコマンドを優先して使いましょう。どうしても必要な場合は yum install net-tools または apt install net-tools でインストールできます。

用途別の使い分け基準

TCPを選ぶべき場面

データの完全性が最優先の場合はTCPを選択します。ファイル転送・Web通信・メール・データベース接続・リモート管理（SSH/RDP）が代表例です。

• ファイルダウンロード（一部欠損でファイルが壊れる）
• HTTPSによるWeb通信
• SSHリモート操作
• メール送受信（SMTP / POP3 / IMAP）
• データベースへの接続（MySQL / PostgreSQL / SQL Server）
• DNSゾーン転送（AXFR）

UDPを選ぶべき場面

リアルタイム性・低遅延が最優先の場合はUDPを選択します。多少のパケットロスより応答速度が重要な通信が対象です。

• DNS名前解決（高頻度・小データ・再送は上位層で対応）
• NTP時刻同期
• SNMP監視・トラップ通知
• 動画ストリーミング・VoIP・Web会議（Zoom / Teams / Google Meet）
• オンラインゲーム（位置情報など最新データ優先）
• IPsec VPN鍵交換（IKE / NAT-T）
• Syslogによるログ転送

トラブルシューティング事例

【事例1】SSH接続がタイムアウトする

SSHはTCP 22番を使用します。以下の順序で確認します。

ss -tlnp | grep ':22'

# firewalld（Rocky Linux / CentOS）
firewall-cmd --list-all

# UFW（Ubuntu）
ufw status verbose

# Windows（PowerShell）
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*SSH*" }

# Linux
nc -zv 192.168.1.10 22

# Windows（PowerShell）
Test-NetConnection -ComputerName 192.168.1.10 -Port 22

【事例2】SNMPでネットワーク機器を監視できない

SNMPはUDP 161番（ポーリング）とUDP 162番（トラップ）を使用します。

SNMPトラブルの主な原因：
①ファイアウォールでUDP 161/162がブロック
②コミュニティ文字列の不一致（SNMPv2c）
③SNMPv3の認証パラメータ不一致。
まずはUDPポートの疎通確認から始めましょう。

# UDPポート161への疎通確認
nc -zuv 192.168.1.1 161

# SNMPwalkで応答確認（net-snmpが必要）
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.1

【事例3】VoIP・Web会議の音声が途切れる

VoIPはRTP（UDP）を使うため、ネットワーク品質（パケットロス・ジッタ・遅延）が直接影響します。

VoIPで許容される品質目安：パケットロス1%未満、遅延150ms以下、ジッタ30ms以下。
これを超えると通話品質が著しく低下します。

• ルーターのQoS設定でVoIPトラフィック（RTP：UDP 10000〜20000など）を優先
• ping でパケットロス率を確認（1%以上なら回線品質を疑う）
• 有線接続に切り替えてWi-Fiの影響を排除
• Zoom / TeamsがアウトバウンドのUDP（3478、3479、8801〜8802）を通過できるかファイアウォールを確認

最新技術動向｜QUICとHTTP/3

QUICとは

QUIC（Quick UDP Internet Connections）はGoogleが開発し、IETFで標準化されたトランスポートプロトコルです。UDPの上位で動作しながら、TCPの信頼性・TLSのセキュリティを実現します。HTTP/3の土台として採用されています。

HTTP/3（QUIC）はUDP 443を使用します。企業のファイアウォールでUDPアウトバウンドを制限している環境では、HTTP/3が使えずHTTP/2へ自動フォールバックします。パフォーマンス最適化でHTTP/3を活用したい場合は、アウトバウンドUDP 443の通信許可を確認してください。

WebRTC

WebRTCはブラウザ上でP2Pリアルタイム通信を実現する技術です。

メディアトラフィックはSRTP（Secure Real-time Transport Protocol）over UDPで転送されます。

Google Meet・Zoom・Teamsのブラウザ版などで採用されています。

企業ネットワークでZoom・Teams・Google Meetが繋がらない場合、アウトバウンドUDP（ポート3478・3479・8801〜8802など）がファイアウォールでブロックされていることが多いです。TCPフォールバックはありますが遅延が増大します。

まとめ

TCPとUDPの違いを、仕組み・ポート番号・コマンド・実務事例の観点から整理しました。

ファイアウォール設計では「このサービスはTCPかUDPか、ポートは何番か」を正確に把握することが前提です。本記事のポート番号一覧をブックマークしておくと、設定作業時にすぐ参照できます。

TCPとUDPを同じポート番号で使えますか？

はい、可能です。ポート番号はTCPとUDPで独立した空間を持つため、同じ番号を両方で使用できます。代表例がDNSで、UDP 53（通常の名前解決）とTCP 53（ゾーン転送）を同じポート番号で使い分けています。

UDPは信頼性がないのに、なぜDNSで使われるのですか？

DNSのクエリ・レスポンスは通常512バイト以下の小さなデータで処理が完結します。万一タイムアウトしても上位のリゾルバが再試行するため、UDP側での再送制御が不要です。速度を優先してUDPが採用されています。

netstatとssはどちらを使えばよいですか？

新しいLinux環境ではssを推奨します。ssはカーネルから直接情報を取得するため高速で、netstatより詳細なフィルタリングが可能です。netstatが必要な場合はnet-toolsパッケージをインストールしてください（yum install net-tools / apt install net-tools）。

HTTP/3はHTTP/2より必ず速いですか？

必ずしもそうではありません。QUICは高パケットロス環境や、モバイル回線でのネットワーク切替が多い環境で特に効果を発揮します。安定した有線LAN環境では、HTTP/2との差はほとんどない場合もあります。