TCPとUDP 〜几帳面な書留郵便と、投げっぱなしの生中継〜
1. 素朴な疑問：なぜ「絶対に間違えない通信」と「カクつく通信」があるの？
インターネットを使っていると、不思議な違いに気づきます。
ネットショッピングでクレジットカード番号を入力したり、銀行でお金を振り込んだりするとき、数字が1文字でも化けたり抜け落ちたりすることは絶対にありません。もし「10,000円」の送金データからゼロが1個抜け落ちて「1,000円」になったら大事件です。
ところが、Zoomでオンライン会議をしたり、YouTubeでリアルタイムの生配信を観たり、スマホゲームで対戦したりしているときはどうでしょうか？ 時々画面がカクつき、相手の声が「ア……オ……」とロボットのように途切れ、一瞬ワープしたように映像が飛びます。
なぜ、同じ光ファイバーやWi-Fiを使っているのに、**「1文字の狂いも許さない完璧な通信」と「データが多少こぼれ落ちても平気で突き進む通信」**の2種類が存在するのでしょうか？
その答えは、第10話で学んだOSI参照モデルの**第4層（トランスポート層）に住む、性格が真逆な2人の配達員「TCP」と「UDP」**の使い分けにあります。
2. 概念の芯：「超几帳面な書留郵便（TCP）」vs「投げっぱなしの生中継（UDP）」
第3層（ネットワーク層）の「IP」は、手紙を相手の住所（IPアドレス）に向けてバケツリレーで運んでくれる仕組みでした。 しかし、IP自身は**「途中で手紙が電線から落ちて消えても一切気にしない（届いたらラッキー）」という、極めて無責任な性格（コネクションレス / ベストエフォート）**をしています。
この無責任なIPの背中に乗って、「実際にどうやってデータを相手に渡すか」を取り仕切るのが、トランスポート層の2大プロトコルです。
- TCP（Transmission Control Protocol） ＝ 相手の受領印をもらうまで絶対に許さない**「超几帳面な書留郵便」**
- UDP（User Datagram Protocol） ＝ 相手がキャッチできたか知ったことではない**「豪快なドッジボールの連続投球」**
| 比較項目 | TCP（ティー・シー・ピー） | UDP（ユー・ディー・ピー） |
|---|---|---|
| 通信のタイプ | コネクション型（事前に「送るよ」と合意する） | コネクションレス型（事前の挨拶なしでいきなり送る） |
| 信頼性 | 完璧（データの抜け・順序の狂いを100%修復） | 無保証（途中でパケットが消えても無視する） |
| スピード | 確認のやり取りが多い分、少し遅い | 余計な確認をしないため、極限まで速い |
| 主な用途 | Web閲覧（HTTP）、メール（SMTP）、ファイル転送（FTP） | 音声通話（VoIP）、生配信、オンラインゲーム、DNS問い合わせ |
Webサイトの文字やプログラムのダウンロードは、1文字でも欠けたらファイル全体が壊れて動かなくなります（即死）。だから、多少時間がかかっても**絶対に間違いのない「TCP」**を使います。
一方、Zoomのビデオ通話や生放送は、**「過去の正確さ」よりも「今現在のリアルタイム性」が命です。 多少データがこぼれ落ちて声が途切れても、会話を止めるわけにはいきません。だから、スピード最優先の「UDP」**を使うのです。
3. 本題：几帳面すぎるTCPの「3ウェイハンドシェイク」と「再送パズル」
では、超几帳面なTCPは、どうやって「1文字の欠落も許さない完璧な通信」を実現しているのでしょうか？ そこには、人間顔負けの3つの厳密なルールがあります。
① 送る前の儀式：「3ウェイハンドシェイク」
TCPは、いきなりデータを送りつけるような失礼なことはしません。 通信を始める前に、必ず**3往復の挨拶（ハンドシェイク）**を交わして、お互いの準備が万全であることを確認します。
- SYN（接続要求）：「通信を始めたいです。私の最初の番号は100番です」
- SYN + ACK（確認応答＋接続要求）：「100番ですね、了解しました！ 私も通信したいです。私の番号は500番です」
- ACK（確認応答）：「500番ですね、了解しました！ では始めましょう！」
この「3回のやり取り」を経て初めて、データの送信が始まります。電話でいう「もしもし」「はい、聞こえますよ」「じゃあ本題に入ります」の挨拶を、機械同士が律儀に行っているのです。
② バラバラの荷物を並べ直す「シーケンス番号」
大きなファイル（写真や動画）は、第10話で学んだとおり、細切れの小さなパケットに切り分けられて送られます。 しかし、インターネットのバケツリレーを通る間に、パケットが届く順番はめちゃくちゃに入れ替わってしまいます。
これを直すために、TCPはすべてのパケットに**「通し番号（シーケンス番号）」**を振っています。
- パケット1番：「むかしむかし」
- パケット2番：「あるところに」
- パケット3番：「おじいさんが」
受信側は、たとえ「2番 → 3番 → 1番」という狂った順番で届いても、番号を見て元の正しい順番にピシッと並べ直してからアプリに渡します。
③ 途中で荷物が消えたら再送させる「ACKとタイムアウト」
もし通信の途中で、2番のパケットだけが電線からこぼれ落ちて消えてしまったらどうするでしょうか？
受信側のTCPは、3番を受け取った瞬間に**「おい、1番の次は『2番』のはずだぞ！ 2番が届いてないから早く送れ！」と受領印（ACK）を使って送信側に文句を言います。 送信側も、送ったパケットに対して一定時間待っても「届いたよ！」という返事（ACK）が返ってこなければ（タイムアウト）、「あ、途中で事故に遭ったな」と判断して、同じパケットをもう一度再送します**。
相手が「確かに全部受け取りました」とサインするまで、何度でも諦めずに再送し続ける。これがTCPの鉄壁の信頼性の正体です。
触って試す：ロスと再送の対比体験
📦 パケットロス体験シミュレータ（送るパケットは5個）
1番〜5番のパケットをいっせいに送ります。ただし途中で3番のパケットが1個消えてしまいます。几帳面なTCPと、投げっぱなしのUDPで、結果がどう違うか見比べてください。
📮 TCP（書留郵便）
まだ送っていません。
⚾ UDP（投げっぱなしの生中継）
まだ送っていません。
「送信する」を押してみてください。
4. なぜ「投げっぱなし（UDP）」が必要なのか？ 生配信の真実
「こんなに完璧なら、世の中の通信を全部TCPにすればいいじゃないか！」と思いますよね。 しかし、想像してみてください。あなたがZoomで同僚とリアルタイムで会話している最中に、TCPの『几帳面さ』が発動したらどうなるかを。
もし通話にTCPを使っていると、たった1文字の音声パケットが消えただけで、そのパケットが再送されて手元に届くまで、後ろのすべての音声がストップ（一時停止）してしまいます。 そして再送が追いついた瞬間、溜まっていた声が「早送り」のように一気に再生されることになります。これでは会話のキャッチボールになりません。
生配信で一番大切なのは「過去の正確さ」ではなく「今の鮮度」
通話や生放送において、「0.5秒前に言いかけた、消えてしまった『の』という声」は、もう取り戻す価値のないゴミデータです。 そんな過去のデータをわざわざ再送してもらうために会話を止めるくらいなら、 「消えた声はもう諦めて捨てろ！ それより、相手が今しゃべっている『最新の声』を1ミリ秒でも速く届けてくれ！」 というのが人間の本音です。
UDPは、事前の挨拶（ハンドシェイク）も、通し番号の整頓も、届いたかどうかの確認（ACK）も一切しません。 送る側は、マイクから入ってきた音声をパケットに詰めて、相手めがけてマシンガンのようにひたすら投げつけるだけです。
途中でいくつか地面に落ちて消えても、誰も振り返りません。拾い直す時間すら惜しいからです。 この「過去を潔く切り捨てる冷徹な割り切り」があるからこそ、私たちは地球の裏側にいる人とも、タイムラグなしで顔を見ながら会話できるのです。
5. 現実世界のドラマ：最新のWeb（HTTP/3）が「TCP」を捨てた日
最後に、いまインターネットの最前線で起きている**「歴史的な大事件」**を紹介しましょう。
1990年代にWeb（ホームページ）が誕生して以来、Webの通信（HTTP/1.1やHTTP/2）は、30年ものあいだ絶対に安全な「TCP」の上で動いてきました。 「Webページの文章や画像は、1文字も欠けてはいけない」のだから、几帳面なTCPを使うのは当然の選択でした。
ところが2020年代、Googleを中心とするエンジニアたちが、世界中を驚かせる決断を下しました。 なんと、最新のWeb規格である「HTTP/3」において、長年連れ添ったTCPをあっさりゴミ箱に捨て、あのいい加減なはずの「UDP」に乗り換えたのです。一体なぜでしょうか？
原因は「几帳面すぎる性格」が生んだ悲劇
現代のWebサイトは、1つのページに何十枚もの画像、アイコン、プログラム（JavaScript）が敷き詰められています。 従来のTCPは几帳面すぎるため、「端っこの小さなアイコン画像のパケットが1個消えた」だけで、その再送を待つために、まったく関係のないメインの文章や写真の表示まで画面全体をストップさせて待たせるという悪癖（ヘッドオブラインブロッキング）を抱えていたのです。
通信回線が光ファイバーや5Gになり、昔に比べて電線からパケットが落ちる事故自体が激減した現代、TCPの重たい確認作業（ハンドシェイクや巻き添えストップ）は、**「慎重すぎて逆に遅い老害」**になってしまいました。
そこでGoogleの天才たちはこう考えました。 「土台には、足が一番速くて余計なお節介をしない『UDP』を使おう。その上で、本当に必要な再送や安全確認だけを、自分たちで作った賢いプログラム（QUIC / クイック）でスマートにやればいいじゃないか！」
あなたが今スマホでYouTubeやGoogle検索を開くとき、裏ではすでにこの新しい「UDPベースの高速通信（HTTP/3）」が動いています。 「几帳面さ」と「スピード」。半世紀にわたる2つの配達員のせめぎ合いは、今も形を変えながら、インターネットをさらに速く進化させ続けているのです。
📝 3行で頭に入る「試験・実務の要点まとめ」
- トランスポート層（第4層）の役割：エンドツーエンド（アプリ間）の信頼性の高い通信制御を担当する。アプリを識別するためにポート番号（Webなら80/443など）を使用する。
- TCP（コネクション型）：**3ウェイハンドシェイク（SYN/ACK）**で接続を確立し、シーケンス番号で順序制御、ACKとタイマーで再送制御、ウィンドウ制御で受信側のバッファ溢れを防ぐフロー制御を行う高信頼プロトコル。
- UDP（コネクションレス型）：事前の接続確立やエラー訂正を行わず、パケットを一方的に送出するプロトコル。ヘッダーサイズが小さく（8バイト）、オーバーヘッドが最小限のため、リアルタイム通信や同報配信、DNS問い合わせに最適。