HTTP/3が必要な理由

対照的なTCPとUDP

　TCPがなぜ足かせになり、それを解決するためになぜUDPを使うのか。それを理解するために、TCPとUDPの歴史を振り返っておこう（図2）。

図2●TCPとUDPの歴史

インターネットが生まれた当初のTCPは、トランスポート層とネットワーク層の処理をまとめて行うものだった。1978年にトランスポート層を担当するTCPとネットワーク層を担当するIPに分離した。さらに、1980年にTCPの弱点を補うプロトコルとしてUDPが生まれた。

[画像のクリックで拡大表示]

　TCPが最初に登場したのは1974年である。現在のTCPとは異なり、ルーティングなどのネットワーク層の処理とトランスポート層の処理をまとめて行うプロトコルだった。これが1978年にトランスポート層を担当するTCPとネットワーク層を担当するIP^▼とに分離。現在のインターネットを支えるTCP/IPになった。さらに1980年には、TCPが抱える弱点を補う形でUDPが生まれた。

　インターネットが採用しているパケット通信は、回線の状況によってパケットが失われる危険性がある。そこで、TCPはデータを確実に届ける仕組みを備えている（詳細は第2回で解説）。

　それと引き換えに、TCPは処理の負荷が高いという弱点を持つことになった。リアルタイム性が求められる用途に向かないのだ。そこで、データを確実に届ける仕組みを持たない代わりに処理の負荷が低いUDPが開発された。

　一言でいうと、正確さを重視するのがTCP、速さを重視するのがUDPだ。両者に共通しているのはポート番号^▼を指定する機能だけであり、その他の特徴は対照的である（図3）。

図3●データが届く保証がない代わりに負荷が低いUDP

TCPは、データを確実に届ける仕組みを備えているが、引き換えに処理の負荷が高い。これに対しUDPは、データを確実に届ける仕組みを持たない代わりに処理の負荷が低いというメリットがある。

[画像のクリックで拡大表示]

　TCPは事前に確立した通信路（コネクション）を使ってデータをやりとりする。また、データの受信側は、データを受け取ったことを送信側に通知する。これによりデータを確実に届けられる。

　一方、UDPは事前確認なしで一方的にデータを送る。データの受信側は、データを受け取っても送信側には通知しない。このため、UDPだけではデータが確実に届く保証はない。そうした保証が必要な場合には、アプリケーション層で信頼性確保のための処理を実装する必要がある。

　その半面、UDPには複雑な処理が存在しないので、処理の負荷が低いというメリットがある。このため、音声や動画の送信にはTCPよりもUDPが向いている（図4）。

図4●音声や動画の送信には向かないTCP

UDPではパケットが相手に到着したかどうかを確認しないため、パケットロスが発生しても音声や動画が一瞬乱れるだけで済む。一方、TCPはパケットが相手に到着したかどうかをいちいち確認し、一定時間待って応答がない場合はパケットを再送する。このため、パケットロスが発生すると再送処理のためにリアルタイム性が失われる。

[画像のクリックで拡大表示]

　UDPではパケットが相手に到着したかどうかを確認しない。このため、パケットロスが発生すると音声や動画が一瞬乱れるものの、それ以上の影響はない。

　一方、TCPではパケットロス時の再送処理がリアルタイム性に悪影響をもたらす。前述したように、TCPではデータの受信側が受け取ったことを送信側に返答する。一定時間たっても返答がない場合、送信側はパケットを送り直す。その結果、パケットロス時には大きな遅延が発生してしまう。

　こうした問題があるため、例えば音声や動画の配信を行うRTP^▼というプロトコルでは、TCPではなくUDPを採用している。