TCPとUDPの違いとは？リアルタイム音声・動画通信でUDPが選ばれる理由を再送制御と遅延から解説

TCPとUDPは、どちらもインターネット上でデータを運ぶために使われる代表的なトランスポート層のプロトコルですが、通信の考え方が大きく異なります。特に音声通話、ビデオ会議、オンラインゲーム、ライブ配信など、リアルタイム性を重視する通信ではUDPが利用されることがあります。

その大きな理由は、TCPがデータの欠落を再送によって補い、順番どおりに相手へ届けようとするのに対し、UDPは基本的に再送や到着順の保証を行わず、新しいデータを優先して送り続けられるためです。

リアルタイム通信では「少し前の音声を完全に取り戻すこと」よりも、「今の音声や映像をできるだけ早く届けること」のほうが重要な場合があります。ここではTCPとUDPの違いを整理しながら、再送制御、パケットロス、遅延、ジッタの観点からUDPが選ばれる理由を解説します。

TCPとUDPの基本的な違い

TCPはTransmission Control Protocol、UDPはUser Datagram Protocolの略です。どちらもIPネットワーク上でアプリケーション同士の通信に利用されますが、提供する機能が異なります。

項目	TCP	UDP
接続	コネクション型	コネクションレス型
到着確認	行う	基本的に行わない
再送制御	行う	基本的に行わない
順序保証	行う	行わない
重複排除	行う	プロトコル自身では保証しない
遅延への影響	信頼性確保のため増える場合がある	比較的抑えやすい
代表的な用途	Web、ファイル転送、メールなど	音声・映像、ゲーム、DNSなど

単純に「TCPは遅くUDPは速い」と覚えるより、TCPは信頼性を強く保証し、UDPは必要最低限の配送機能だけを提供すると理解するほうが正確です。

TCPでは失われたデータを再送する

TCPでは、送信したデータが相手へ届いたかを確認しながら通信します。途中でデータが失われたと判断すると、必要なデータを再送します。

例えばA、B、C、Dというデータを順番に送信し、Bだけネットワーク途中で失われたとします。TCPではBを再送し、アプリケーションには原則としてA、B、C、Dの順序でデータを渡します。

送信側: A → B → C → D
             × Bが消失
受信側: A →   → C → D

TCP: Bを再送

アプリケーションへ: A → B → C → D

ファイル転送ではこの仕組みが非常に重要です。ファイルの一部が1バイトでも欠ければ内容が壊れる可能性があるため、多少待ってでも正しいデータをそろえる必要があります。

リアルタイム音声では「古いデータの再送」が役に立たないことがある

一方、リアルタイムの音声通話では事情が違います。例えば「こんにちは」という音声を細かく分割して送信している途中で、一部の音声パケットが失われたとします。

その失われた音声を500ミリ秒後に再送して受信しても、その時点では会話がすでに先へ進んでいる可能性があります。過去の音声を遅れて再生すると、会話全体の遅延を増やしてしまいます。

リアルタイム通信では「失われた過去のデータを完全に復元すること」より、「最新のデータを遅れず届けること」を優先したほうが自然な通信になる場合があります。

UDPでは失われたパケットを待たず次へ進める

UDPそのものには、TCPのような到着確認や自動再送、順序保証がありません。そのため一つのパケットが失われても、後続のパケットはそのまま受信できます。

送信: A → B → C → D
          × Bが消失
受信: A →   → C → D

リアルタイム音声なら、Bの部分が一瞬途切れたり音質が低下したりする可能性はありますが、CやDがすぐ届けば会話自体は進み続けます。

つまりUDPは「欠損を許容してでも時間を優先したい」用途と相性がよいのです。

TCPの順序保証が遅延を生む理由

TCPでは、データをアプリケーションへ順番どおり渡すことを重視します。そのため先頭側のデータが欠落すると、後ろのデータがすでに届いていても、欠落した部分を待つ状況が生じます。

このように、一つの欠損が後続データの配送まで待たせてしまう現象は、リアルタイム通信では大きな問題になります。

例えば映像の新しいフレームがすでに届いているのに、古いデータの再送待ちによって表示が止まれば、映像のカクつきや遅延として利用者に感じられます。

UDPは「高速」なのではなく制御が少ない

UDPについて「TCPより高速なプロトコル」と説明されることがありますが、少し注意が必要です。同じネットワーク上でUDPのパケットだけが物理的に特別速く移動するわけではありません。

UDPにはTCPが持つ接続管理、再送、順序制御などがないため、通信に必要な制御が少なく、待ち時間を抑えやすいという特徴があります。

したがって「UDPそのものがネットワーク速度を上げる」というより、信頼性確保のための待機や再送をアプリケーションの判断に任せられるため、低遅延な設計をしやすいと理解するとよいでしょう。

パケットロスが起きても音声や動画は成立することがある

音声や動画では、多少のデータ欠損が発生しても人間が内容を理解できることがあります。例えば20ミリ秒分の音声が一度失われても、周囲の音から補間することで違和感を小さくできる場合があります。

映像でも、フレームの一部が失われた場合に前の映像を短時間利用したり、後続フレームへ切り替えたりすることで再生を継続できます。

このような性質があるため、リアルタイムメディアでは「すべてのパケットを必ず届ける」ことより「一定時間内に届いたデータだけで再生を続ける」設計が適しています。

UDPなら何の制御もしないわけではない

重要なのは、UDPを使うからといってアプリケーション側で何も制御しないわけではないことです。UDP自体には再送や順序保証がありませんが、その上に別の仕組みを実装できます。

例えばリアルタイム音声や映像では、パケットへシーケンス番号やタイムスタンプを付けて、到着順を判断したり欠損を検知したりします。

つまりUDPを使う目的は信頼性を捨てることではなく、どのデータを再送するか、どの程度の欠損を許容するかをリアルタイム通信に適した形でアプリケーション側が判断できるようにすることです。

RTPはリアルタイム音声・動画でよく使われる

UDP上で音声や映像を扱う場合には、RTP（Real-time Transport Protocol）が利用されることがあります。RTPではシーケンス番号やタイムスタンプなど、リアルタイムメディアを扱うために便利な情報を持たせられます。

例えばシーケンス番号が100、101、103と届けば、102のパケットが欠けた可能性を検知できます。

100 → 101 → 103
             ↑
        102が欠落

またタイムスタンプを利用すれば、音声や映像をどのタイミングで再生するべきか判断できます。このようにUDP単体の弱点を上位プロトコルで補います。

ジッタとはパケット到着時間のばらつき

リアルタイム通信では平均的な遅延だけでなく、パケット到着時間のばらつきも重要です。このばらつきをジッタと呼びます。

例えば音声パケットが20ミリ秒ごとに送信されても、ネットワークの混雑によって受信間隔が10ミリ秒、40ミリ秒、15ミリ秒のようにばらつくことがあります。

そのまま再生すると音声が途切れやすいため、受信側ではジッタバッファを利用して、少量のデータを一時的にためてから一定間隔で再生する方法があります。

ジッタバッファを大きくしすぎると遅延が増える

ジッタバッファを大きくすれば、多少遅れて到着したパケットも利用できるため音声は安定しやすくなります。しかし、その分だけ再生開始まで待つため遅延が増えます。

例えば100ミリ秒分の音声を常にためてから再生する設計なら、それだけで少なくとも100ミリ秒程度の待ち時間要因が追加されます。

そのためリアルタイム通信では、パケットロス、ジッタ、遅延のバランスを取りながらバッファ量を調整する必要があります。

音声通話では遅延が会話のしやすさに直結する

ファイルダウンロードなら、完了が1秒遅くなっても大きな問題にならないことがあります。しかし会話では、遅延が大きくなると相手の発言が終わったか分からず、双方が同時に話し始めるなど不自然な状態になります。

音声通信では、エンコード、ネットワーク転送、ジッタバッファ、デコード、再生など複数の場所で遅延が積み重なります。そのためネットワーク部分で余計な再送待ちを増やさないことが重要です。

UDPが利用されるのは、このEnd-to-Endの遅延をなるべく小さく保つ設計をしやすいためです。

動画でも「古いフレーム」より「新しいフレーム」が重要

ライブ映像やビデオ会議でも同様です。例えば現在時刻が10秒なのに、8秒時点の映像パケットを再送して完全復元することに時間を使えば、画面が現実より遅れ続ける可能性があります。

リアルタイム動画では、ある程度の映像欠損を許容しながら、できるだけ現在に近いフレームへ追いつくことが重要です。

特にインタラクティブなビデオ会議では、画質を完全に維持することより会話のタイミングを保つほうが優先される場面が多くあります。

オンラインゲームでもUDPが使われる理由は似ている

リアルタイムゲームでも、プレイヤーの位置や向きなど頻繁に更新される情報にはUDPが利用されることがあります。

例えばプレイヤーの位置情報が1秒間に何十回も送られている場合、100ミリ秒前の位置情報を再送するより最新の位置を受け取ったほうが役立ちます。

ただしアイテム購入、ログイン、チャットなど、「失われてはいけない情報」には別の信頼性確保方法を使うことがあります。1つのアプリケーションでもデータの性質によって通信設計を分けます。

UDPでも重要なパケットだけ再送できる

UDPを使用しているアプリケーションでも、必要であれば独自に再送処理を実装できます。重要なのは「すべてをTCPと同じ方法で再送しない」ことです。

例えば動画では、後続映像を復号するために特定の重要データだけ再送を要求し、時間価値の低い古いパケットは捨てる、といった制御が可能です。

このようにリアルタイム通信では、「失われたら全部再送」という一律の方針ではなく、データごとの重要度と時間的価値を考えた制御が適しています。

FECで再送せず欠損を復元する方法もある

再送による待ち時間を避けるため、FEC（Forward Error Correction：前方誤り訂正）を利用する方法もあります。

FECでは、送信するデータにあらかじめ冗長な情報を追加しておき、一部のパケットが失われても受信側で復元できるようにします。

その分だけ通信量は増えますが、「パケットが消える→再送要求→再送パケット到着」という往復時間を待たずに済む場合があります。低遅延が重要な通信では有効な選択肢です。

TCPがリアルタイム通信に絶対使えないわけではない

ここまでUDPの利点を説明しましたが、「音声・動画は必ずUDP、TCPは使えない」と考えるのは正しくありません。

ネットワーク環境によってUDP通信が制限される場合には、TCPやHTTPS系の経路へフォールバックする仕組みが利用されることがあります。また、リアルタイム性がそれほど重要でない動画配信ではTCP系の通信が広く利用されています。

つまりUDPが特に有利なのは、双方向通話など「少しのパケット欠損より低遅延を優先する」リアルタイム用途です。

動画配信サービスがTCPを使うことも多い理由

YouTubeのようなオンデマンド動画視聴では、リアルタイム通話ほど低遅延を求めない場合があります。再生前に数秒分の映像をバッファしておけば、ネットワークの一時的な揺らぎを吸収できます。

そのため動画という同じメディアでも、「ビデオ会議」と「録画済み動画のストリーミング」では通信要件が異なります。

通信方式はデータの種類だけで決めるのではなく、どれだけの遅延を許容できるか、欠損を許容できるか、完全なデータが必要かで選択することが重要です。

QUICはUDP上で信頼性を実現する

近年のネットワークでは、UDPを土台として独自の信頼性や暗号化、輻輳制御などを実装するQUICも利用されています。

QUICが興味深いのは、「UDP＝信頼性がないから単純な用途専用」というわけではなく、UDPの上に用途に適した高度な通信制御を構築できることを示している点です。

ただし、一般的なリアルタイム音声でUDPを使う理由を理解するときは、まずTCPの再送・順序保証とUDPの自由度の違いを押さえることが基本です。

TCPとUDPの使い分けを目的別に整理

用途	重要な要件	選ばれやすい方式
ファイル転送	1バイトも欠けないこと	TCP系
Webページ取得	データの整合性	TCPまたはQUIC系
メール	内容が完全に届くこと	TCP系
音声通話	低遅延	UDP系が有力
ビデオ会議	低遅延・連続性	UDP系が有力
リアルタイムゲーム	最新状態の高速反映	UDP系を使う場合が多い

実際のアプリケーションでは複数の方式を併用することもあるため、この表は絶対的な分類ではなく、設計思想を理解するための目安です。

「UDPはパケットロスしても気にしない」は正確ではない

UDPについて「データが消えても気にしない通信」と説明されることがありますが、より正確には、UDPプロトコル自身が再送や順序保証を行わないということです。

アプリケーション側ではパケットロスを検知し、音声補間、FEC、重要データだけの再送、ビットレート低下など適切な対処を行えます。

つまりリアルタイム通信では、信頼性をなくしているのではなく、「時間的価値を考慮した信頼性制御」へ置き換えていると考えると理解しやすくなります。

ネットワーク混雑時にはUDPでも遅延する

UDPを利用すれば必ず低遅延になるわけでもありません。ネットワークが混雑していればUDPパケットもキューに入り、遅延したり破棄されたりします。

さらに送信側が回線容量を無視して大量のUDPデータを送り続ければ、パケットロスが増え、音声や映像品質が悪化します。

そのため実際のリアルタイム通信では、回線状況に合わせて映像ビットレートや送信量を調整する輻輳制御も重要です。

具体例｜500ミリ秒後に届く完璧な音声と今すぐ届く少し欠けた音声

TCPとUDPの違いを感覚的に理解するなら、電話での会話を想像すると分かりやすくなります。

「おはようございます」という発言のごく一部が欠けたとしても、「おは…ございます」のように聞こえれば内容を推測できる可能性があります。UDP系のリアルタイム通信では、この状態でも後続音声を遅らせず再生する設計ができます。

一方、欠けた部分が届くまで毎回500ミリ秒待って完璧な音声を再生すると、音質は完全でも会話の反応が徐々に遅くなります。リアルタイム通信では後者のほうが使いにくいことがあります。

再送が有効かどうかはRTTにも左右される

再送による追加遅延は、ネットワークのRTT（Round Trip Time：往復遅延）にも関係します。送信側が欠損を認識し、再送し、それが再び相手へ届くまでには一定の時間が必要です。

同じ国内の近距離通信なら比較的短くても、海外との通信やモバイル回線では往復時間が大きくなる場合があります。

リアルタイム音声では、再送パケットが届くころには再生期限を過ぎている場合があるため、「届いてももう使えないパケット」を待たない設計が重要になります。

リアルタイム通信では「パケットの締切」がある

ファイルの一部分は、10秒後に届いてもファイル完成時に使えます。しかしリアルタイム音声の20ミリ秒分のパケットには、実質的な再生期限があります。

例えば時刻1.000秒の音声を1.500秒に再生しようとしても、すでに会話は先へ進んでいます。このようなデータは、正確性だけでなく「期限内に届くこと」に価値があります。

UDPがリアルタイム通信に適している本質は、失われたデータを必ず待つのではなく、期限切れデータを捨てて新しいデータを優先できる点にあります。

まとめ｜UDPは欠損より遅延を避けたいリアルタイム通信に向いている

TCPは到着確認、再送、順序保証などによって、データを正確に届けることを重視するプロトコルです。ファイル転送やメールなど、一部でも失われると困る通信に適しています。

一方UDPは、プロトコル自身では再送や順序保証を行いません。そのためパケットが失われても後続データを待たせず送受信でき、音声通話、ビデオ会議、オンラインゲームなど最新情報の価値が高い通信で低遅延な設計をしやすくなります。

リアルタイム音声では、古い音声パケットを再送して完全にそろえるより、多少の欠損を補間しながら最新音声を再生するほうが自然な会話になります。映像でも同様に、過去のフレームの完全復元より現在の映像へ追いつくことが重要な場合があります。

TCPは「完全性を優先して必要なら待つ」、UDPを使ったリアルタイム通信は「期限を過ぎたデータを待たず最新情報を優先する」と考えると、両者の違いを理解しやすくなります。

ただしUDPを使えば自動的に高品質になるわけではありません。実際の音声・動画システムでは、RTP、ジッタバッファ、FEC、選択的な再送、輻輳制御などを組み合わせ、パケットロスと遅延のバランスを取ることが重要です。