なぜRTP TCPの代わりにUDPを使用するのですか？
UDPがRTPではなくTCPで使用されている理由を知りたいと思いました。 VoIP OSSの一部をハッキングしたため、主要なVoIPツールはUDPのみを使用していました。
DJが指摘したように、TCPは信頼できるデータストリームを取得することに関するものであり、それを実現するために、送信を遅くし、破損したパケットを再送信します。
UDPは通信の信頼性を考慮せず、データの速度を落としたり、再送信したりしません。
たとえば、Webサーバーからファイルを取得するなど、アプリケーションに信頼できるデータストリームが必要な場合は、TCPを選択します。
アプリケーションが破損したパケットや失われたパケットを気にせず、信頼性を高めるためにオーバーヘッドを追加する必要がない場合は、代わりにUDPを選択できます。
VOIPは信頼性の高いパケット送信によって大幅に改善されることはなく、実際、再送信や指数バックオフのようなTCP.
多くの良い答えが与えられましたが、私は一つのことを明確に指摘したいと思います。
基本的に、完全なデータストリームは、リアルタイムのオーディオ/ビデオには良いものですが、厳密に必要ではありません（他の人が指摘しているように）：
重要な事実は、到着が遅すぎるデータには価値がないことです。数秒前に表示されるはずだったフレームの欠落データはどれほど良いですか？
TCP（これもすべてのデータの正しい順序を保証します）を使用する場合、古いデータが取得されるまで、より最新のデータに到達することはできません。これは二重に悪いことです：古いデータの再送信を待つ必要がありますおよび新しいデータ（現在は遅れています）はおそらく同じくらい価値がないでしょう。
RTPは、利用可能なすべてのデータを時間内に転送しようとしますが、転送中に失われた/破損したデータを再送信しようとしないという点で、何らかのベストエフォート型の送信を行います（ *）。それは人生とともに続き、より重要な現在のデータが正しくそこに到達することを望んでいます。
（*）実際、RTPの詳細はわかりません。おそらく再送信を試みますが、再送信すると、TCP is（失われたデータを受け入れない）ほど積極的ではなくなります。
他の人は正しいですが、本当の理由を本当に教えてはいけません。 Sauaはそれについてのちょっとしたヒントですが、ここにもっと完全な答えがあります。
オーディオとビデオはリアルタイムです。ラジオを聴いているとき、またはテレビを見ているときに信号が中断された場合、中断したところからは信号を受信しません。それはいつでも失われます。
その理由は簡単です。ディレイ。 VOIPは、誰かが一方の側に話しかけてから反対側に戻ってから応答が返ってくるまでの遅延を最小限に抑えるように努めています。そうしないと、エラーが発生したときに、人が話をしてから信号が受信されるまでの遅延の量が、役に立たなくなるまで継続的に増加します。
再送信からの各遅延はリプレイする必要があり、それがさらにデータを遅延させることを覚えておいてください、そして、別のエラーはさらに大きな遅延を引き起こします。唯一実行可能な解決策は、リアルタイムで表示できないデータを単にドロップすることです。
再送信から1秒の遅延は、私が何かを言ってからそれを聞くまで1秒であることを意味します。 2秒の1秒の遅延とは、何かを言ってから聞こえるまで2秒であることを意味します。データは話されているのと同じ速度で再生されるため、これは累積的です...
RTPは接続指向ですが、再送信エラーに追いつくためにデータをドロップ（またはスキップ）する必要があります。
技術的にRTPパケットはTCP接続を介してインターリーブできます。ここには多くの素晴らしい答えがあります。
RFC 4588では、RTPデータを使用して再送信を使用する方法を説明しています。RTPストリームを受信するほとんどのクライアントは、通常1 -5秒の長さ。これは、再送信が目的のデータを受信するための時間があることを意味します。
RTPトラフィックは、TCP接続でインターリーブできます。実際にこれが行われると、インターリーブRTP（つまりTCP経由）とRTP UDPを介して送信されることは、ユーザーが利用できる帯域幅が不十分な損失の多いネットワーク上でこれら2つが実行する方法です。インターリーブTCPパケットが到着するためのバッファリング状態。プレーヤーによっては追いつくために先にジャンプする場合があります。RTP接続を使用すると、ビデオにアーティファクト（スミア/ティアリング）が発生します。
UDPは、厳密な順序付けを必要としないさまざまな種類のリアルタイムトラフィックによく使用されます。これは、TCPがアプリケーションにデータを渡す前に順序付けを強制するためです（デフォルトでは、URGポインターを設定することでこれを回避できますが、誰もこれを行うことはないようです）。古いデータを確実に取得するよりも、現在のリアルタイムデータを取得したい環境では、非常に望ましくありません。
RTPはパケット損失の影響をほとんど受けないため、TCPの信頼性は必要ありません。
UDPはヘッダーのオーバーヘッドが少ないため、1つのパケットでより多くのデータを伝送できるため、ネットワーク帯域幅がより効率的に利用されます。
UDPは、高速データ送信も提供します。
したがって、このような場合にはUDPが当然の選択です。
他のすべてに加えて、すてきな正解 この記事 は、TCPとUDP。
UDPは、データが送信される場所、ターゲットで正確に受信する必要がない場所、または安定した接続が必要ない場所で使用されます。
データをビット単位で正確に受信する必要がある場合、ビット損失なしでTCPが使用されます。
ビデオとサウンドのストリーミングでは、途中で失われた一部のビットは結果に影響を与えません。つまり、言及されているように、一部のピクセルはストリームの画像で失敗します。より高い。
リアルタイムトランスポートプロトコルは、ストリーミングオーディオおよびビデオメディアをインターネット経由で配信するために使用されるネットワークプロトコルであり、それによってVoice Over Internet Protocol（VoIP）を有効にします。
RTPは一般に、SIPなどのシグナリングプロトコルと共に使用され、ネットワーク全体の接続をセットアップします。 RTPアプリケーションはTransmission Control Protocol（TCP）を使用できますが、ほとんどの場合、UDPがデータの高速配信を可能にするため、代わりにUser Datagram protocol（UDP）を使用します。
Stoborの回答に応じてMatt Hが言ったことにすばやく加えたいと思います。 Matt Hは、RTP over UDPパケットをチェックサムして、破損したパケットを再送することができると述べました。これは、ほとんどのPBXのオプション機能です。たとえば、アスタリスクでは、次の行を使用して、rtp.conf構成ファイルでUDPトラフィックを介したRTPでチェックサムを有効または無効にできます。
rtpchecksums=yes ; or no if you prefer
乾杯！
単なる注釈：RTPストリームで送信される各パケットには、その前身よりも1高い番号が与えられます。宛先が取るべきアクションは、内挿によって欠落している値を概算することです。