TCP と UDP の違い

届かなかったことに、送った側は気づけない

ネットワークにデータを流しても、途中で捨てられることがあります。混雑した中継機は、あふれた分を黙って捨てるからです。

困るのは、捨てられたことが送り主に知らされない点です。何も言われないので、送り主は届いたと思い込んだままになります。この不安を引き受けてくれるのが TCP、引き受けないのが UDP です。どちらも同じ段で使える、並んだ選択肢です。

どちらを使うかはアプリを書くときに選びます。選んだ結果はコードの見た目にほとんど現れませんが、うまくいかなかったときの挙動がまるで変わります。

確実に届けるために、TCP が肩代わりしていること

TCP は「必ず、順番どおりに届く」を約束します。約束を守るために、内部で次のことをしています。

• 送る前に相手と挨拶を交わし、両方向で話が通じることを確かめる
• 送る塊 1 つ 1 つに通し番号を振り、受け取り側で順番に並べ直す
• 受け取り側に「ここまで受け取った」と返事をさせ、返事が来ない分を送り直す
• 混雑を検知したら、送る速度を自分から落とす

書く側は、この仕組みを一切意識しません。送ったデータは届く、順番も守られる、という前提でコードを書けます。Web の通信がそのまま TCP に乗っているのも、面倒を全部下に押し付けられるからです。

見落としやすいのは、これらが全部、送り主と受け取り側の 2 者だけで完結している点です。途中の中継機は何も手伝いません。混んでいると教えてもくれないし、落とした分を覚えてもいません。両端だけで辻褄を合わせる設計だからこそ、どんな回線の上でも同じように動きます。

約束しないほうが速い場面がある

UDP は逆です。挨拶をせず、通し番号を振らず、返事も待たず、送り直しもしません。宛先を書いて投げたら終わりです。

一見すると劣化版ですが、そうではありません。TCP は順番を守るために、後ろの塊が先に届いていても、前の塊が届くまで上のアプリへ渡さずに待たせます。通話や対戦ゲームでは、この待ち時間そのものが致命傷になります。1 コマ落ちた過去を取り戻すより、いまの音と映像を先に進めたい。そういう場面では、諦める設計のほうが体感がはっきり良くなります。

「速い遅い」の差ではなく、「何を諦めるか」の差だと捉えてください。守りたいものが到達なら TCP、いまこの瞬間なら UDP です。そして UDP を選んだ場合、落ちた分の後始末はアプリ側の仕事になります。何もしなくていいわけではありません。

実際の選び方はほぼ決まっています。作るものが Web サービスや API なら、意識せずとも TCP に乗ります。UDP を自分で選ぶのは、通話や配信、対戦ゲームのように待ち時間が致命的な場面か、既存のやり方では遅すぎると実測で分かったときです。まず TCP、理由があるときだけ UDP、という順番で考えてください。