TCP vs RTP：何故RTPが必要なのか？
インターネットを流れるトラフィックのほとんどがTCP(Trasmission Control Protocol)によるものです。 TCPは、全てのデータが正しく相手に伝わることを保証するため品質の高いデータ通信が実現できます。 また、どのパケットが受け取れなくて、どれが受け取れたかなどをわざわざ考えなくても良いので、プログラムを書くのも簡単です。 では、何故、わざわざRTPというものが必要だったのでしょうか？ ここでは、まず最初に何故RTPはTCPではなく、UDPの上に存在しているのかを説明したいと思います。 （もちろん、TCPの上に作ることはRTPの規約上は可能ですが、現実的にはUDPの上でしか実装がないと思います。） その後、何故、UDPの上に共通のRTPというものを構築したのかを説明したいと思います。
RTPは、名前にもある通り、「リアルタイム」なデータを転送するためのプロトコルです。 リアルタイム性を追求すると、TCP提供する信頼性が仇になる事が出てきます。 TCPの信頼性は、送ったデータが相手に届いたか確認して届いていなければ再度送りなおす（再送する）という事を繰り返す事により実現しています。 そのため、全てのデータが確実に届きますが、逆にいうと、全てが正しく届かないと次のデータを送れません。 例えば無線や携帯電話での通話を想像してください。 無線や携帯電話では、一瞬声が聞こえなくなる事がありますが、それでも使えています。 電話などの通話を行なう機器では、「全ての声がなくならずに伝わる事」よりも「途中でデータがなくなってもいいから出来るだけ早く送ること」の方が重要です。
図１と図２にTCPとUDPでのデータ転送の違いを示します（ただし、図はかなり簡略化しているので、正確ではない面を含みます）。 図１はTCPの挙動を示しています。 TCPでは、データがネットワークでロスすると再送を行ないます。 再送を行なうと、その分、次のデータを送るのが遅くなってしまいます。 一方、UDPでは、ロスが発生しても再送を行なわないため、次のデータを送るタイミングが遅れません。
 |
 |
TCPは、再送だけではなく輻輳制御も行ないます。 輻輳制御を簡単に表すと、「ネットワークが混雑してきたら送る量を減らす」です。 インターネットにとって、この輻輳制御は非常に重要な要素です。 この要素がTCPに入っていなければ、そこらじゅうでネットワークが混雑してしまい、まともな通信は出来なかったでしょう （出来ないという状況が発生したからTCPにこの機能が入っているという考え方もありますが）。 しかし、リアルタイム転送を要求する音声や映像などのデータにとっては、この輻輳制御が障害になる時もあります。 TCPというアプリケーションからは見えないレベルで勝手に送信レートを決められてしまうため、状況によってはリアルタイムに送りたいデータの転送に大量の時間がかかってしまう可能性があるからです。 一方、UDPには輻輳制御は存在せず、アプリケーションに全てが任されているので、アプリケーションは好きな方法で転送が出来ます。 これは、輻輳制御をする必要性がないということではありません。 輻輳制御を入れるか入れないか、入れるとしたらどういう方法を採用するかなどが全てアプリケーションプログラマの裁量に一任されているということです。 輻輳を考慮しないアプリケーションを書くことは簡単ですが、特定環境でしか動作しない汎用性の低いものしか出来上がらないので、UDPを使う場合には輻輳を考慮しつつアプリケーションを書くことをお勧め致します。
TCPは、データを受け取ったことを送信側に通知するACKメッセージ（確認応答メッセージ）を定期的に送信しています。 ある一定量データを送った後に、送信側は受信側からのACKを待ちます。 そのため、送信側の受信側の距離が離れていると（RTTが大きいと）TCPは十分な性能が出せません。 RTTが小さい場合にはあまり問題は発生しませんが、地球を半周したり、衛星を経由した通信が間に入った場合にはTCPではネットワークが混雑していなくても性能が出ません。
最後に、TCPは1対1の通信しか行なえません。 そのため、一台のサーバから数万、数十万、数百万、etc、のクライアントに対して同じデータを送りつづける放送型の通信には向きません。 UDPでは、ブロードキャスト（broadcast）型通信やマルチキャスト（multicast）型通信も利用可能なので、放送型の通信に向いています。 （ただし、IPv6にはブロードキャストという通信形態はありません） これもTCPではなくUDPを使うメリットです。
以上のような理由から、RTPはTCPではなく、主にUDPの上に構築されます。 ただし、注意していただきたいのは、TCPが非常に使いにくいように書いてしまいましたが、そのような事がどのような環境でも真実であるとは限らないことです。 パケットのロスが十分少なく、RTTが十分に小さく、放送型の通信を行う必要もない環境ではTCPにすることのメリットも多くあります。 ただし、TCPの上にRTPを乗せることにメリットがあるとは思えないので、アプリケーション独自の方法を使ってデータの転送を行なうことになると思います。 （もちろん、TCPを使う既存のプロトコルに乗せるという選択肢も十分あります）
何故、RTPというプロトコルが必要だったかですが、リアルタイムにマルチメディアデータを通信するにはUDPだけでは不十分であったことが挙げられます。 UDPの提供するサービスは、ポート番号による通信の識別と、CRC（Cyclic Redundancy Check）によってデータ部分が破損していないかチェックする機能ぐらいしかありません。 リアルタイムにマルチメディアデータ転送をしたいと思ったときにはもっと様々な情報が必要になります。 そのような情報を汎用的に提供するのがRTPです。
次は、実際にRTPはどのようなものかを説明します。
| | | 1 | | | 2 | | | 3 | | |
