TCPとUDPの違い——確実さと速さ、どちらを選ぶか

インターネットを流れるデータは、すべて何らかの**通信方式（プロトコル）**に乗っています。 Webページをひらくときもメールをやりとりするときも動画を見るときも、裏では小さなデータのかたまり（パケット）が行き交っています。

その通信方式として代表的なのが、TCP と UDP です。どちらも「データを届ける」ために使われますが、「どうやって届けるか」の考え方が大きく異なります。この違いを一言でまとめると、こうなります。

TCPは「確実に届ける」、UDPは「速く届ける」。

本記事では、それぞれのたとえ話を交えながら、このトレードオフをひもといていきます。

TCPは「書留郵便」——届いたか確認しながら進む

TCPを一言でたとえるなら、書留郵便です。

普通の郵便は、ポストに投函したら相手が受け取ったかどうかわかりません。でも書留なら、相手が受け取ったというサインが返ってきます。届かなかった場合は再送できます。複数の荷物を送るときは、番号を振って順番通りに届けます。

TCPはまさにこの仕組みです。

この「確認のやりとり」があるおかげで、TCPはどんなに途中で混雑しても、最終的には正確なデータを届けられます。

WebページやAPIのやりとり（HTTP）、ファイルのアップロード、メール送信など、1ビットたりとも欠けてはいけないものはすべてTCPで動いています。

ただし、確認のやりとりには往復の時間がかかります。相手に届いたか確認してから次のデータを送るため、どうしても少し遅くなります。

書留郵便が普通郵便より届くのに時間がかかるように、TCPはUDPより遅延が生じやすいです。

UDPを一言でたとえるなら、ラジオ放送です。

ラジオ局は、リスナーが聴いているかどうかを確認せずに電波を送り続けます。途中でノイズが入って音が途切れても、局は気にしません。「届いたか」を確認する仕組みがないぶん、放送は止まらず流れ続けます。

UDPも同じです。

これだけ聞くと「欠陥があるのでは？」と思うかもしれません。でも、実は**「確認しない」こと自体がメリットになる場面**があります。

動画ストリーミングや音声通話を想像してみてください。

1秒間に何十フレームもの映像が流れています。仮にそのうちの1フレームが届かなかったとして、再送を待っていたら？その間も映像は進んでいます。再送されたデータが届くころには、もう「過去のフレーム」になっています。

そんなとき、欠けたフレームを届け直すより、次のフレームをどんどん送り続けるほうが実用的です。映像や音声は多少のノイズや欠けがあっても、人間の感覚では気にならないことが多いからです。

UDPは確認を省いた軽さで、こういったリアルタイム性が求められる通信に向いています。

TCPとUDPは、どちらが上という話ではありません。それぞれが異なるトレードオフを持つ道具です。

現実のシステムでは、この2つを場面ごとに使い分けています。たとえば、動画プレイヤーで動画をストリーミング再生するのはUDPですが、その動画ファイルをダウンロードするのはTCPです。同じ動画に関わる通信でも、目的によって方式が変わります。

また、最新のWeb通信規格（HTTP/3）は、TCPではなくUDPを土台に使いつつ、アプリ層で信頼性を確保する仕組みを独自に組み込んでいます。速さと確実さを両立しようとする最新の工夫です。

「TCPとUDPって何が違うの？」と聞かれたとき、書留とラジオのたとえを思い出してもらえると、すっと答えられるはずです。