TCP と UDP は、どちらが安全ですか?

安全（暗号化）とは別の話です。TCP も UDP も中身は暗号化しません。TCP が保証するのは「届いたこと」と「順番」で、盗み見を防ぐのは TLS の仕事です。HTTPS は TCP の上に TLS を重ねています。

同じポート番号を TCP と UDP の両方で使えますか?

使えます。ポート番号は TCP と UDP で別々に管理されるので、TCP の 53 番と UDP の 53 番は別の窓口です。DNS は問い合わせに UDP の 53 番を使い、返事が大きいときやゾーン転送では TCP の 53 番も使います。だからセキュリティグループのルールは「プロトコル＋ポート」で書きます。

動画配信サイトは UDP ですか?

用途によります。録画済みの動画を配信するサービスの多くは HTTP（TCP）の上で小さなファイルに分けて送っています。一方、ビデオ会議のように「いまこの瞬間」が大事な通信では UDP が使われます。遅れて届いた映像に価値が無いので、送り直すより次を送る方がよいからです。

FOR BEGINNERS未経験向け

Bネットワーク基礎段1入口層仕組み

TCP と UDP の違い｜「届いたか確かめる」か「速く送る」かを、用途で使い分ける

2026年09月03日約11分で読めます執筆: Cloudory 執筆者（AWS 認定全冠（AWS Certification をすべて保持））

ネットワークとは何かで、TCP は「確認しながら送る」、UDP は「確認せずに送る」と1行だけ書きました。そこから AWS に進むと、セキュリティグループの画面には「プロトコル: TCP、ポート: 22」のような行が並び、ロードバランサーには「Application」と「Network」の2種類があり、どちらも TCP と UDP の違いを知っている前提で書かれています。この記事は、その1行を、手紙を小分けにして送る話から組み立て直します。

この記事の結論

インターネットではデータを小分けにして送ります。小分けの1つがパケットで、その運び方に TCP と UDP の2種類があります。
TCP は、つなぐ・番号を振る・届いたか確かめる・足りなければ送り直す、の4つをやる届け方です。中身が欠けてはいけない通信（Web・メール・SSH）に使います。
UDP は、確かめずに送る届け方です。軽くて速い代わりに、落ちたパケットは戻りません。いまこの瞬間が大事な通信（動画会議・ゲーム・DNS の問い合わせ）に使います。
TCP は送る前に「もしもし・はい・どうぞ」の3往復で接続を作ります。これが3ウェイハンドシェイクです。
セキュリティグループのルールは「TCP の 22 番」のように、プロトコルとポートの組で書きます。TCP と UDP は別の窓口です。

パケットとは「小分けにした手紙」。運び方が2種類ある

ネットワークでは、大きなデータを1つの塊のまま送りません。写真1枚も、Web ページ1つも、小さな断片に切って、1つずつ送ります。この断片がパケットです。長い手紙を何枚もの便箋に分け、1枚ずつ別の封筒で出すようなものです。

小分けにするのは、1本の線を何人もで共有するためです。1人の大きなデータが線を占領すると、他の人の通信が止まります。小さく切って交互に流せば、全員が同時に使えます。その代わり、便箋は別々の道を通ることがあり、順番が入れ替わったり、途中で1枚だけ落ちたりします。

ここで「落ちた便箋をどうするか」で、運び方が2つに分かれます。届いたかを確かめ、足りなければもう一度送るのが TCP（Transmission Control Protocol）。確かめずに次を送るのが UDP（User Datagram Protocol）です。どちらもネットワークとは何かで見た4層のうち、トランスポート層の約束事です。

TWO WAYS TO DELIVER小分けの手紙の運び方

確かめて送るのが TCP、確かめずに送るのが UDP

TCP

欠けてはいけないデータに

送る前に3往復で接続を作る
パケットに番号を振り、順番に並べ直す
届いたか確かめ、足りなければ送り直す

UDP

いまが大事なデータに

接続を作らない。いきなり送る
番号も確認も無い
落ちても送り直さない。軽くて速い

出典: RFC 9293（TCP）・RFC 768（UDP）

TCP とは「つないで・確かめて・送り直す」届け方

TCP は、中身が1文字も欠けてはいけない通信のための届け方です。やることは4つあります。

つなぐ。 送る前に、相手と「話せる状態」を作ります。
番号を振る。 便箋の1枚ずつに通し番号を付けます。受け取る側は、番号順に並べ直せます。
届いたか確かめる。 受け取った側は「ここまで受け取った」と返事（確認応答）をします。
足りなければ送り直す。 返事が来ない番号があれば、送った側がもう一度送ります。

3ウェイハンドシェイクは「もしもし・はい・どうぞ」

1つ目の「つなぐ」が、3ウェイハンドシェイクです。電話にたとえると分かりやすい手続きです。

THREE-WAY HANDSHAKEもしもし・はい・どうぞ

本文を送る前に、話せる状態を3往復で作る

SYN
もしもし — 送る側が「話していいですか」
相手の窓口（ポート）に向けて頼む
SYN-ACK
はい、聞こえます — 受ける側が応答する
ここで返事が無ければ、窓口が開いていない
ACK
では始めます — 送る側が確認し、本文へ
以後は番号つきのパケットと確認応答の往復

出典: RFC 9293 §3.5

もしもし（SYN）。 送る側が「話していいですか」と頼みます。
はい、聞こえます（SYN-ACK）。 受ける側が「いいですよ、こちらも準備できました」と返します。
では始めます（ACK）。 送る側が「分かりました」と返し、ここから本文を送りはじめます。

なぜ3往復もするのか。相手が「いない」「混んでいて応答できない」「そのポートで待っていない」のに本文を送りはじめても無駄だからです。本文を送る前に、相手が応答できる状態であることを確かめるのが3往復の目的です。逆にいえば、ここで返事が来なければ「相手の窓口が開いていない」と分かります。ping と DNS で分かる「つながる」の仕組みの「届くのに開かない」は、この段階で止まっている状態です。

TCP の仕様は 1981 年の RFC 793 で決まり、現在は RFC 9293 にまとめ直されています。40年以上、この4つのやり方の骨格は変わっていません。

CHECK 1ここまでの確認

TCP の3ウェイハンドシェイクを「もしもし・はい・どうぞ」にたとえたとき、この3往復は何のためにある?

答えと解説

答え: 2. 送る前に、相手が応答できる状態かを確かめて接続を作るため

3ウェイハンドシェイクは、データを送りはじめる前に「話せる状態」を作る手続きです。暗号化は TLS、住所を調べるのは DNS の仕事です。「TCP とは」の段落を読み直してください。

UDP とは「確かめずに送る」届け方

UDP は、TCP の4つを全部やらない届け方です。つながず、番号も振らず、届いたか確かめず、送り直しもしません。宛先と窓口（ポート）と中身だけを書いて、投函して終わりです。仕様の RFC 768 はわずか3ページで、やることが少ないことがそのまま長さに出ています。

なぜそんな乱暴なものが使われるのか。確かめないぶん、軽くて速いからです。TCP は本文の前に3往復が要り、送るたびに返事を待ち、落ちれば送り直しで遅れます。UDP はそれが無いので、相手に着くまでの時間が短く、送る側も受ける側も手間が少なくて済みます。

この速さが効くのは、「遅れて届くくらいなら、落ちてもいい」データです。ビデオ会議で 0.5 秒前の映像が今ごろ届いても意味が無く、それより次の瞬間の映像がほしい。ゲームの操作も同じです。DNS の問い合わせは、1回の質問と1回の答えで終わる短いやり取りなので、そのために3往復して接続を作るのは割に合いません。答えが来なければ、もう一度聞けば済みます。

CHECK 2ここまでの確認

UDP について正しいのはどれ?

答えと解説

答え: 2. 接続を作らず、届いたかも確かめない。その分、軽くて速い

UDP は接続も確認も送り直しもしません。だから軽くて速く、落ちても構わない用途に向きます。「UDP とは」の段落を読み直してください。

どちらを使うか — 用途で決まっている

TCP か UDP かを、自分で毎回選ぶことはありません。アプリごとの約束事（HTTP・SSH・DNS）が、どちらを使うかを決めています。読む側に要るのは、「なぜそちらか」を説明できることです。

用途	約束事	届け方	ポート	なぜそちらか
Web	HTTP / HTTPS	TCP	80 / 443	ページの HTML が1文字欠けても壊れる
サーバーに入る	SSH	TCP	22	打ったコマンドが欠けたり入れ替わったりしては困る
名前から住所を引く	DNS	UDP（大きい返事は TCP）	53	1問1答で短い。落ちたら聞き直せばよい
動画会議・音声	RTP など	UDP	アプリごと	遅れた映像に価値が無い。落ちても次を送る
ゲーム	アプリごと	UDP が多い	アプリごと	いまの位置が大事。過去の位置は要らない

RELIABILITY VS SPEED信頼性と速さの天秤

確かめれば遅くなり、確かめなければ落ちる

TCP — 信頼性

欠けない
順番どおり
落ちたら送り直す

UDP — 速さ

返事を待たない
手間が少ない
落ちても次を送る

支点は「欠けてはいけないか、いまが大事か」

Web・メール・SSH は左、動画会議・ゲーム・DNS の問い合わせは右

軸は1つです。信頼性（欠けずに、順番どおりに届くこと）を取るなら TCP、速さを取るなら UDP。両方は同時に取れません。TCP が届いたかを確かめるには待つ時間が要り、UDP が速いのは確かめないからです。この「片方を取ると片方が減る」関係は、クラウドの設計のあちこちに出てきます。

なお、HTTP の新しい版である HTTP/3 は UDP の上に QUIC という仕組みを載せて、確認や送り直しを自前でやります。「UDP は確かめない」の例外ではなく、確かめる仕事を上の層に移した形です。未経験のうちは、表の5行が読めれば十分です。

CHECK 3ここまでの確認

セキュリティグループのルールに「UDP の 53 番を許可」と書いた。何を通す設定?

答えと解説

答え: 3. DNS の問い合わせ

DNS の問い合わせは UDP の 53 番です。SSH は TCP の 22 番、HTTPS は TCP の 443 番。ルールは「プロトコルとポートの組」で書きます。「どちらを使うか」の表を読み直してください。

クラウドで効く場面 — セキュリティグループとロードバランサー

AWS でこの違いが最初に効くのは、セキュリティグループのルールです。ルールは「どのプロトコルの、どのポートを、どこから通すか」の組で書きます。

TCP  22   自分の IP からだけ   ← SSH で入る
TCP  443  0.0.0.0/0            ← HTTPS を全世界から受ける
UDP  53   VPC の内側から       ← DNS の問い合わせ（自分で DNS サーバーを立てたとき）

TCP の 53 番と UDP の 53 番は別の窓口です。片方だけ開けて「なぜか DNS が引けない」となるのは、この違いを知らないと切り分けられません。ルールの書き方そのものは VPC とは何かで扱います。

2つ目は、ロードバランサーの種類です。AWS には Application Load Balancer（ALB）と Network Load Balancer（NLB）があり、ALB は HTTP / HTTPS の中身（パスやヘッダー）を読んで振り分け、NLB は TCP / UDP の段階で中身を読まずに振り分けます。「Web なら ALB、ゲームや音声のような UDP の通信や、中身を読まずに速く通したいなら NLB」という選び分けの出発点は、この記事の2種類の届け方です。どちらを選ぶかの判断は上の段の記事に譲ります。

まとめ

データは小分けの手紙（パケット）で送られ、その運び方に TCP と UDP があります。TCP は、つなぐ・番号を振る・確かめる・送り直す。送る前の3往復が3ウェイハンドシェイクです。UDP は確かめずに送る。軽くて速いが、落ちたら戻りません。欠けてはいけないデータは TCP、いまが大事なデータは UDP。セキュリティグループのルールは「TCP の 22 番」のようにプロトコルとポートの組で書き、TCP と UDP は別の窓口として数えます。HTTP がこの TCP の上でどう頼み、どう返すかは HTTP と HTTPS の仕組みにあります。

参照ソース

RFC 9293 “Transmission Control Protocol (TCP)” — 3ウェイハンドシェイク（SYN / SYN-ACK / ACK）、シーケンス番号、確認応答と再送の仕様の根拠（2022年。RFC 793 の統合改訂版）
RFC 768 “User Datagram Protocol” — UDP が接続を作らず、到達の保証も再送もしない仕様の根拠（1980年）
RFC 1035 “Domain Names - Implementation and Specification” — DNS の問い合わせが UDP の 53 番を使い、TCP の 53 番も使うことの根拠（1987年）
Service Name and Transport Protocol Port Number Registry（IANA） — SSH 22・DNS 53・HTTP 80・HTTPS 443 の割り当ての根拠（2026年9月時点）
セキュリティグループのルール（Amazon VPC ユーザーガイド） — ルールがプロトコル・ポート範囲・送信元の組で書かれることの根拠（2026年9月時点）
Elastic Load Balancing とは（Elastic Load Balancing ユーザーガイド） — ALB が HTTP / HTTPS の層、NLB が TCP / UDP の層で振り分けることの根拠（2026年9月時点）

SCOREこの記事の確認テスト

0/3問正解

各章の「ここまでの確認」に答えると、ここに集まります。結果はこの端末のブラウザにだけ残り、サーバには送りません。

FAQよくある質問

TCP と UDP は、どちらが安全ですか?: 安全（暗号化）とは別の話です。TCP も UDP も中身は暗号化しません。TCP が保証するのは「届いたこと」と「順番」で、盗み見を防ぐのは TLS の仕事です。HTTPS は TCP の上に TLS を重ねています。
同じポート番号を TCP と UDP の両方で使えますか?: 使えます。ポート番号は TCP と UDP で別々に管理されるので、TCP の 53 番と UDP の 53 番は別の窓口です。DNS は問い合わせに UDP の 53 番を使い、返事が大きいときやゾーン転送では TCP の 53 番も使います。だからセキュリティグループのルールは「プロトコル＋ポート」で書きます。
動画配信サイトは UDP ですか?: 用途によります。録画済みの動画を配信するサービスの多くは HTTP（TCP）の上で小さなファイルに分けて送っています。一方、ビデオ会議のように「いまこの瞬間」が大事な通信では UDP が使われます。遅れて届いた映像に価値が無いので、送り直すより次を送る方がよいからです。

この記事を書いた人

Cloudory 執筆者Cloudory 編集部

AWS 認定全冠（AWS Certification をすべて保持）／ 2025・2026 Japan All AWS Certifications Engineers 選出

インフラ・クラウドの設計と運用に従事。AWS 認定を全冠し、AWS Japan の Japan All AWS Certifications Engineers に2年連続で選出

サービスの仕様・試験の版・料金は AWS の公式ドキュメントと試験ガイドを、ネットワークの仕組みは RFC を一次情報にしています。AWS が公表していない合格率や受験者数は書きません。「体感の難易度」は執筆者本人の経験と明記して書き、本人の経験の外側は公開されたポストモーテムと Well-Architected を根拠にします。

執筆者について編集ポリシー訂正と更新の記録記事の誤りを知らせる