「TCPとUDPは何が違うの？」
ネットワークを学び始めると、よく出てくるのがTCPとUDPです。
「TCPは確実、UDPは速い」と覚えている方も多いでしょう。
しかし、UDPが必ず速いわけでも、TCPならデータが必ず届くわけでもありません。
TCPとUDPの大きな違いは、データを受け渡すための制御を、プロトコル自身がどこまで行うかにあります。
– TCP：通信相手と接続を確立し、確認しながらデータを受け渡す
– UDP：TCPのような接続確立や再送を行わず、データグラム単位で送る
どちらも、アプリケーション間のデータ受け渡しを担当するトランスポート層のプロトコルです。
この記事では、仕組みと使い分け、Windowsでの確認方法を解説します。
TCP/IP全体の中でTCPとUDPがどこに位置するのか先に知りたい方は、[インターネットの仕組み]も参考にしてください。
TCPとUDPの違いをまず比較しよう
コネクション型は、通信相手との間に論理的な接続を確立してからデータをやり取りする方式です。UDPはこの接続確立や再送、順序制御をUDP自身では行いません。
単純な速さではなく、アプリケーションが必要とする制御に応じて使い分けられます。
TCPとは？信頼性のあるデータ受け渡しを行う仕組み
TCP（Transmission Control Protocol）は、接続を確立し、データの欠損や順番の入れ替わりに対処する仕組みを持つプロトコルです。
TCPは通信前に接続を確立する
TCPではデータを送り始める前に、3ウェイハンドシェイクによって接続を確立します。
基本的な流れは次のとおりです。
1. クライアントからサーバーへ `SYN` を送る
2. サーバーからクライアントへ `SYN/ACK` を返す
3. クライアントからサーバーへ `ACK` を返す
`SYN` はTCP接続を確立するときの同期に使われ、`ACK` は受信したことを確認するために使われます。
この手順で双方がTCP接続に必要な状態を作り、データの順番を管理するための初期情報を合わせます。
電話で相手の返事を確認してから会話を始めるイメージです。
ただし、TCPが確認するのは人の在席ではなく、コンピューター間の接続状態です。
TCPはデータの欠損や順番を管理する
ネットワークでは、データが失われたり、到着順が入れ替わったりすることがあります。
TCPは次の仕組みで対処します。
– シーケンス番号：データの位置や順番を識別する
– ACK：どこまで受信できたかを相手へ知らせる
– 再送：必要なデータが届かなかったと判断したときに送り直す
– 順序制御：受信したデータを正しい順番でアプリケーションへ渡す
送信側は応答の状況などから欠損を検出して再送し、到着順が前後したデータはシーケンス番号をもとに整えます。
ただし、回線断やサーバー停止などがあれば通信を完了できるとは限りません。
TCPはデータを「バイトの流れ」として扱う
TCPは、アプリケーションから受け取ったデータを連続したバイトの流れ（バイトストリーム）として扱います。
データを1通ずつ独立した封筒として扱うのではなく、長くつながった流れとして渡すイメージです。
送信時の区切りが、そのまま受信側へ渡されるとは限らないため、アプリケーション側でメッセージの区切りを判断します。
UDPとは？シンプルにデータを送る仕組み
UDP（User Datagram Protocol）は、少ない制御でデータを送るシンプルなプロトコルです。
データをデータグラム単位で扱い、その区切りを保って受け渡します。
UDPはTCPのような接続確立を行わない
UDPでは、TCPの3ウェイハンドシェイクのような接続確立を行いません。
アプリケーションは宛先のIPアドレスとポート番号を指定してデータグラムを送ります。
接続を確立しないことと、相手が応答しないことは別です。
UDP自身には再送や順序制御がない
UDP自身は、次の処理を提供しません。
– TCPのようなACKによる到達確認
– 届かなかったデータの再送
– 到着順が入れ替わったデータの並べ直し
データグラムは失われたり、順番が入れ替わったり、重複したりする可能性があります。
必要なら、UDP上のアプリケーションや別のプロトコルが信頼性のための機能を実装します。
たとえばQUICはUDPで運ばれますが、QUIC自身が接続管理や損失からの回復を行います。
UDPでも双方向通信はできる
UDPは一方向にしか通信できない、と誤解されることがありますが、UDPでも双方向通信は可能です。
たとえば、一般的なDNS問い合わせでは、次のようにクライアントとDNSサーバーがUDPでデータをやり取りします。
1. クライアントからDNSサーバーへ問い合わせを送る
2. DNSサーバーからクライアントへ応答を返す
この応答はTCPのACKではなく、DNSというアプリケーションプロトコルの応答です。
UDP自身が到達確認や再送を行っているわけではありません。
TCPとUDPはどう使い分ける？
TCPとUDPは、通信に必要な要件に合わせて選ばれます。
データを正しく届けたい通信ではTCPが使われる
欠損したデータの再送や順序制御が必要な通信では、TCPが適しています。
メールやファイルの一部が欠けると、内容が壊れてしまいます。
Webページもデータを正しく受け取る必要があります。そのため、次のようなプロトコルではTCPが利用されます。
– メールで使われるSMTP、IMAPなど
– FTPなどのファイル転送
– HTTP/1.1
– HTTP/2
ただし、実際に使うトランスポートプロトコルは、アプリケーションプロトコルや実装によって決まります。
リアルタイム性やシンプルな処理を重視する通信ではUDPが使われる
通信前の接続確立や、TCPによる再送・順序制御を必要としない通信では、UDPのシンプルさを活用できます。
利用例には次のようなものがあります。
– 一般的なDNS問い合わせ
– リアルタイム性を重視する音声・映像通信
– 一部のオンラインゲーム
– QUIC
たとえばリアルタイムの音声通話では、遅れて届いた古い音声より、次の音声を時間どおりに再生する方が重要な場合があります。
ただし、これらの用途が常にUDPを使うとは限りません。
UDPを選べば必ず高速になるわけでもなく、性能は遅延やパケットロス、アプリケーションの設計にも左右されます。
DNSはTCPとUDPのどっちを使う？
結論からいうと、DNSはUDPだけではなくTCPも使用します。
通常のDNS問い合わせでは、TCPの接続確立を必要としないUDPが多く使われます。
一方、UDP応答が切り詰められた場合はTCPで再試行することがあります。
DNSサーバー間でゾーン情報を転送するAXFRでもTCPを使い、現在のDNSではTCPのサポートも必要です。
> 現場でのポイント
> ファイアウォールでDNS通信を許可するときに、「DNS＝UDP/53」と考えてUDP/53だけを許可すると、TCPが必要になった通信で名前解決に失敗することがあります。DNSではTCP/53が必要になるケースもあることを覚えておきましょう。
DNSが名前からIPアドレスを調べる仕組みは、[DNSとは？名前と住所をつなぐネットの仕組み]で詳しく解説しています。
Web通信はすべてTCPではない
現在はWeb通信をすべてTCPと考えることはできません。
| HTTPのバージョン | 主に使う通信方式 |
| HTTP/1.1 | TCP |
| HTTP/2 | TCP |
| HTTP/3 | QUIC |
HTTP/3はQUIC上で動作し、QUICのパケットはUDPで運ばれます。
接続管理や信頼性に関する機能はQUICが提供します。
HTTPのバージョンによって使われる仕組みが異なると覚えましょう。
WindowsでTCPとUDPの通信を確認してみよう
Windowsの `netstat` では、TCP接続やTCP/UDPの待受ポートを確認できます。
netstatでTCP/UDPを確認する
コマンドプロンプトを開き、次のコマンドを実行してください。
netstat -ano各オプションの意味は次のとおりです。
– `-a`：すべてのアクティブなTCP接続と、待受中のTCP/UDPポートを表示する
– `-n`：アドレスとポート番号を名前に変換せず、数値で表示する
– `-o`：通信に対応するプロセスID（PID）を表示する
※IPアドレス、ポート番号、PIDは説明用のサンプルです。
Proto Local Address Foreign Address State PID
TCP 192.0.2.10:53124 203.0.113.20:443 ESTABLISHED 4280
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1200
UDP 0.0.0.0:5353 *:* 2360各列は次の意味を持ちます。
– Proto：TCPまたはUDPのどちらを使っているか
– Local Address：自分のPC側のIPアドレスとポート番号
– Foreign Address：通信相手側のIPアドレスとポート番号
– State：TCP接続の現在の状態
– PID：その通信や待受けに対応するプロセスの識別番号
1行目の `ESTABLISHED` はTCP接続が確立していること、2行目の `LISTENING` は接続を待ち受けていることを示します。
UDPの3行目には、TCPのような状態がありません。
ポート番号の役割や、IPアドレスの後ろに付く番号の読み方は、[ポート番号とは？]で詳しく確認できます。
TCPには状態があり、UDPにはTCPと同じ状態表示がない
TCPは接続ごとの状態を管理するため、`ESTABLISHED` や `LISTENING` などが表示されます。UDPはTCPのような接続を確立しないため、UDP行には `ESTABLISHED` に相当する状態がありません。
これが、TCPはコネクション型、UDPはコネクションレス型という違いがPC上で見える例です。
なお、`netstat` は通信パケットそのものを確認するツールではありません。
UDPの行が表示されていても、その瞬間にデータグラムが送受信されていることを示すわけではありません。
TCPとUDPでよくある4つの勘違い
TCPならデータは必ず届く？
いいえ。 TCPは欠損検出、再送、順序制御を備えますが、回線断、経路障害、サーバー停止などがあれば通信を完了できません。正しく届けるための制御をTCP自身が持つと理解しましょう。
UDPは一方向にしか通信できない？
いいえ。DNSの問い合わせと応答のように、双方からUDPデータグラムを送れます。一方、UDP自身はTCPのようなACK、再送、順序制御を提供しません。
UDPならTCPより必ず速い？
いいえ。UDP自身の制御は少なくシンプルですが、性能は遅延、パケットロス、アプリケーション実装などにも影響されます。必要な制御を基準に使い分けます。
同じポート番号ならTCPとUDPも同じ通信？
いいえ。 TCPとUDPは別のプロトコルなので、次の2つは同じ「53番」でも区別されます。
– `TCP/53`
– `UDP/53`
ファイアウォールでもプロトコルとポート番号を組み合わせます。
UDP/53の許可はTCP/53の許可とは別です。
まとめ｜TCPとUDPは「速さ」だけで使い分けるわけではない
1. TCPは、接続確立・ACK・再送・順序制御など、信頼性のあるデータ受け渡しを行う仕組みを持つ
2. UDPは、それらの制御をUDP自身では行わず、データグラム単位で送るシンプルなプロトコル
3. どちらを使うかは単純な速さではなく、通信の目的やアプリケーションの要求によって決まる
まずはWindowsで `netstat -ano` を実行し、TCPとUDPがどう表示されるか確認してみてください。
TCPとUDPの違いを理解したら、次は実際の通信トラブルでどう切り分けるのかを確認してみましょう。
[pingは通るのにWebが開かない原因と確認方法]では、ICMPとWeb通信の違いも含めて、確認の考え方を解説しています。
