インターネットの通信は、もともと「必ず届く」「必ず速い」といったことを厳密に保証する仕組みではありません。
TCP/IPは、基本的にベストエフォート型の考え方で作られており、通信の混雑や回線状況によって、速度や遅延、到達性が変動することがあります。
それにもかかわらず、現在は動画配信、音声通話、Web会議、ライブ配信などを、多くの人が日常的に快適に利用しています。
保証しないはずの通信方式で、なぜこれほど高品質なサービスが実現できているのでしょうか。
その理由は、TCP/IPの仕組みが変わったというよりも、ベストエフォート型の通信を土台にしながら、その上にさまざまな技術が積み重ねられてきたからです。
TCPやQUICによる制御、CDNやキャッシュ、適応型配信、5Gやエッジコンピューティングなどが組み合わさることで、現在の快適な通信環境が成り立っています。
この記事では、まずTCP/IPの基本であるベストエフォート通信とは何かを整理し、そのうえで動画や音声を快適に送れる理由、さらに今後の通信技術がどのように進化していくのかを分かりやすく解説します。
まずは、TCP/IPの土台となっている「ベストエフォート通信」の考え方から見ていきましょう。
ベストエフォート通信とは何か
ベストエフォートとは、「雑な通信」という意味ではありません。
正確には、IPネットワーク自体は「できるだけ届ける」が、「必ず届く」「必ず順番通り届く」「必ず一定速度が出る」とは約束しない、という意味です。
IPの基本仕様では信頼性、フロー制御、順序制御はIP自身の役割ではなく、必要であれば上位層で実装する考え方になっています。

インターネット層IP
[送信側]
|
| パケットを送る
v
+-------------------+
| IPネットワーク |
| ベストエフォート |
+-------------------+
| | | |
| | | +--> 届かないことがある
| | +------> 順番が入れ替わることがある
| +----------> 重複することがある
+--------------> 遅れることがある
v
[受信側]この設計の利点は、ネットワーク内部をできるだけ単純に保てることです。
中を複雑にしすぎないことで、世界規模で拡張しやすくなり、新しいアプリケーションも上位層で作りやすくなりました。
インターネットがここまで広がった背景には、この単純さがあります。
それでも動画や音声が快適になったのはなぜか
理由は1つではありません。ポイントは、ベストエフォートを保証型に作り替えたのではなく、失敗しにくくし、失敗しても目立ちにくくする仕組みを何層にも重ねたことです。
高品質に見える理由は「1つ」ではない
[IP: ベストエフォート]
|
v
[TCP / QUIC の制御]
再送 / 輻輳制御 / 多重化
|
v
[CDN / キャッシュ]
近くから配信 / stale応答
|
v
[アプリ側の工夫]
ABR / バッファ / コーデック
|
v
[アクセス網の進化]
光回線 / 4G / 5G / QoS
|
v
[結果]
高品質な動画・音声・会議が実現回線そのものが大きく進化した
最も分かりやすい理由は、回線と設備の性能向上です。
光回線、4G、5G、データセンター間ネットワーク、家庭内Wi-Fi、端末性能、サーバー性能が大きく伸びたことで、混雑や遅延そのものが起きにくくなりました。
5G Standalone では、低遅延やスライシングなどを前提とした基盤整備が進んでいます。
TCPが「確実性」を補ってきた
ベストエフォートなIPの上で、TCPは再送、順序制御、フロー制御、輻輳制御を行います。
つまり、IPが保証しない部分をTCPが補ってきました。
Web閲覧やファイル転送では、多少遅くても正確に届くことが重要なので、TCPは非常に相性のよい仕組みでした。
HTTP/2もTCP上で動作しており、1本のTCP接続の中で複数のリクエストとレスポンスを多重化することで、HTTP/1.1より効率よく通信できるようになっています。
送信
↓
TCP
・抜けたデータは再送
・順番を整える
・相手に合わせて流量調整
↓
IP
・宛先へ運ぶ
↓
ネットワーク
↓
受信一方、HTTP/3はTCPを使わず、QUICを介してUDP上で動作します。
つまり、HTTP/1.1とHTTP/2は「TCP系」、HTTP/3は「QUIC系」と考えると位置関係が理解しやすくなります。
HTTP/1.1 → TLS → TCP → IP
HTTP/2 → TLS → TCP (1本のTCP接続の中で複数の通信を多重化) → IP
HTTP/3 → QUIC → UDP → IPCDNとキャッシュが「遠さ」を減らした
動画や画像が快適になった大きな理由の1つがCDNとHTTPキャッシュです。
ユーザーの近くにコンテンツの複製を置くことで、遠いサーバーまで毎回取りに行かなくて済みます。
HTTPキャッシュは応答再利用で遅延と帯域消費を抑え、stale-while-revalidate のような仕組みは、少し古い応答を先に返しつつ裏で更新することで体感速度を高めます。
[ユーザー]
|
| リクエスト
v
[近くのCDNエッジ]
|\
| \-- キャッシュあり --> すぐ返す
|
\---- キャッシュなし --> [オリジンサーバー]
|
+--> 取得後、エッジに保存動画は「止まらないこと」を優先するようになった
現代の動画配信は、ネットワークの状態が悪くなったら即停止する作りではありません。
HLSのような適応型配信では、回線状況に合わせて画質を自動的に上下させます。
つまり、品質を固定するのではなく、品質を少し動かしてでも再生を続ける設計になっています。
低遅延HLSの仕組みも、公開ネットワーク上で遅延を抑えつつ大規模配信する方向を示しています。
回線が良い
↓
高画質セグメントを選ぶ
回線が悪化
↓
低画質セグメントへ切り替える
結果
↓
止まりにくい低遅延HLS(HTTP Live Streaming)
低遅延HLSは、通常のHLSより配信の遅れを小さくする仕組みです。
通常のHLSは、動画を数秒単位の小さなファイルに分けて順番に配信するため、安定しやすい一方で遅延が大きくなりやすい特徴があります。
低遅延HLSは、その分割をさらに細かくし、セグメントが全部できあがる前から少しずつ先に送ることで、ライブ配信の遅れを短くします。
イメージとしては、通常のHLSが
「1本の動画片が完成してから送る」
方式なのに対し、
低遅延HLSは
「できた部分から先に送る」
方式です。
そのため、ライブ配信やスポーツ中継のように、できるだけリアルタイム性がほしい場面で使われます。
音声やWeb会議は「完全性」より「遅れにくさ」を重視する
リアルタイム音声やWeb会議では、全部を完全に届けることより、「今の声が今聞こえる」ことの方が重要です。
ETFでも、インタラクティブなリアルタイム通信では低遅延で半信頼的な配送が必要だと整理されています。
そこで再送だけに頼らず、冗長データや補完、ジッタバッファ、低遅延コーデックを使って、多少欠けても会話を続けられるようにしています。
Opusはその代表的な音声コーデックです。
損失への対処
(1) 再送
パケット欠落
|
+--> 送り直す
|
+--> 正確だが、間に合わないことがある
(2) 冗長化・補完
通常データ + 補助データ
|
+--> 少し欠けても再生継続しやすい
|
+--> リアルタイム向きHTTP/3とQUICで何が変わったのか
近年の大きな転機がHTTP/3とQUICです。
HTTP/2はTCP上で多重化を行い、HTTP/1.1より効率よく複数リクエストを扱えますが、土台がTCPである以上、損失時の影響を完全には避けられません。
HTTP/3はQUIC上で動き、低遅延な接続確立、ストリーム多重化、移動体通信への強さといった利点を持ちます。
QUIC自体はUDPベースの新しいトランスポートで、暗号化や再送制御も統合しています。
HTTP/1.1
[要求1] --> [応答1] --> [要求2] --> [応答2]
順番待ちが多い
HTTP/2
[要求1][要求2][要求3] --> まとめて流す
|
+-- ただし土台はTCP
HTTP/3
├─ Stream 1 ─────────────→ 正常に進む
├─ Stream 2 ─────────────→ 正常に進む
└─ Stream 3 ─────────────→ 正常に進む
※ 1つのStreamが遅れても、他のStreamには影響しにくい接続確立と接続の継続性
通常、TCP + TLS 1.3では接続に1-RTT(1往復)を要しますが、QUICの0-RTTではこれをショートカットします。
QUICにおける 0-RTT (Zero Round Trip Time) ハンドシェイクは、クライアントがサーバーに対して「以前接続したことがある」という情報を利用し、接続確立の往復(RTT)を待たずに1パケット目からアプリケーションデータ(HTTPリクエストなど)を送信します。
| 特徴 | HTTP/2 (以前) | HTTP/3 (現在) |
| 接続確立 | 2-3回往復 (Handshake) | 0-RTT / 1-RTT (極めて高速) |
| 接続の継続性 | IPが変わると切断 | Connection ID によりIPが変わっても継続 |

重要なのは、インターネットの土台をIPから変えたわけではないことです。
変わったのは、IPの上でどのようにデータを運ぶかという部分です。
ベストエフォートを捨てたのではなく、その上でより速く、切れにくく、移動体にも強い方式へ進化させたのがQUIC(Quick UDP Internet Connections)です。
これは通信の発達として正しい方向なのか
インターネット全体として見ると、かなり合理的な方向です。
IPを単純なまま保ち、その上に多様な機能を載せる設計は、柔軟性とスケーラビリティを両立しやすいからです。
もし最初からネットワーク全体に厳密な保証を求めていたら、世界規模でこれほど多様なアプリケーションを広げるのは難しかったはずです。
ただし、すべての用途にベストエフォートだけで十分というわけではありません。
自動運転、産業制御、遠隔医療のように、遅延や信頼性を強く求める用途では、より厳しい品質制御が必要です。
そのため5Gでは QoS、ネットワークスライシング、MEC が重視されています。
スライシングでは用途ごとに帯域や遅延などの性質を分けられ、MECでは処理を利用者の近くへ寄せられます。
今後はどうなるのか
今後もIPそのものはかなり長く残る可能性が高いです。
5Gや将来の6Gの議論は、IPを捨てる方向ではなく、IPを前提としながら、その上の制御や無線側の能力を高度化する方向で進んでいます。
ITUのIMT-2030では、6Gに向けて知能化、持続可能性、高信頼性などが重視されています。
今後は、まずQUIC系の比重がさらに増えていくと考えられます。
特にWebやモバイル通信では、HTTP/3とQUICの利点が大きいためです。
次に、エッジ化が進みます。MECのように、処理をユーザーの近くへ寄せることで往復遅延を減らします。
さらに、5Gスライシングのように、全部を保証型にするのではなく、必要な通信だけ品質制御を強化する方向も強まります。加えて、AIによるネットワーク最適化も今後の大きな流れです。
これまで
[インターネット全体]
|
+--> ほぼベストエフォート
これから
[インターネット全体]
|
+--> 基本はベストエフォート
|
+--> 必要な用途だけ品質制御を強化
|
+--> 5G QoS
+--> スライシング
+--> MEC
+--> 将来の6G制御
まとめ
TCP/IPがベストエフォートであること自体は、今も変わっていません。
IPは依然として「できるだけ届ける」層であり、厳密な到達保証や帯域保証を直接行う層ではありません。
それでも動画や音声が快適に使えるのは、TCPやQUICの制御、CDNとキャッシュ、適応型配信、低遅延コーデック、バッファ、5Gやエッジ処理など、複数の技術がうまく積み上がったからです。
今後の方向性を一言で言えば、ベストエフォートを土台に残しつつ、必要な通信だけを賢く、近くで、選択的に強化するという形です。
これはオープンなインターネットの強さを保ちながら、現代の高品質サービスに必要な条件も満たす、かなり現実的な進化だと言えます。
参考リンク
TCP/IPとベストエフォート通信の基礎
- RFC 1122: Requirements for Internet Hosts — Communication Layers
URL:https://datatracker.ietf.org/doc/html/rfc1122 - RFC 791: Internet Protocol
URL:https://www.rfc-editor.org/rfc/inline-errata/rfc791.html
HTTP/2・HTTP/3・QUIC
- RFC 9113: HTTP/2
URL:https://www.rfc-editor.org/info/rfc9113 - RFC 9114: HTTP/3
URL:https://www.rfc-editor.org/rfc/rfc9114 - RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
URL:https://www.rfc-editor.org/rfc/rfc9000
キャッシュ・動画配信
- RFC 9111: HTTP Caching
URL:https://www.rfc-editor.org/rfc/rfc9111 - Apple Developer: Enabling Low-Latency HTTP Live Streaming (HLS)
URL:https://developer.apple.com/documentation/http-live-streaming/enabling-low-latency-http-live-streaming-hls
音声・リアルタイム通信
- RFC 6716: Definition of the Opus Audio Codec
URL:https://www.rfc-editor.org/rfc/rfc6716 - RFC 8836: WebRTC Data Channels
URL:https://www.ietf.org/rfc/rfc8836.html
5G・MEC・ネットワークスライシング
- GSMA: What is 5G Standalone?
URL:https://www.gsma.com/solutions-and-impact/technologies/networks/5g-network-technologies-and-solutions/5g-standalone-networks/ - GSMA: An Introduction to 5G Network Slicing
URL:https://www.gsma.com/solutions-and-impact/technologies/networks/5g/introduction-to-5g-network-slicing/ - ETSI: Multi-access Edge Computing (MEC)
URL:https://www.etsi.org/technologies/multi-access-edge-computing/mec
6G / IMT-2030
- ITU: IMT towards 2030 and beyond (IMT-2030)
URL:https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt-2030/Pages/default.aspx - ITU: ITU advances the development of IMT-2030 for 6G mobile technologies
URL:https://www.itu.int/en/mediacentre/Pages/PR-2023-12-01-IMT-2030-for-6G-mobile-technologies.aspx
HTTP Live Streaming
- HTTP Live Streaming Overview
URL:https://developer.apple.com/documentation/http-live-streaming


