ビデオストリームのTCPとUDP

ネットワークプログラミングの試験から家に帰ってきたところ、「ビデオをストリーミングする場合は、TCPまたはUDPを使用しますか？保存されているビデオとライブビデオストリームの両方について説明してください」という質問がありました。。この質問に対して、彼らは単に保存されたビデオのTCPとライブビデオのUDPの短い答えを期待していましたが、私は帰宅時にこれについて考えました、そしてライブビデオのストリーミングにUDPを使用するほうが良いのでしょうか？つまり、帯域幅があり、サッカーの試合やコンサートをストリーミングしているとしたら、本当にUDPを使用する必要がありますか？

このコンサートまたはTCPを使用して何かをストリーミングしているときに、パケットを失い始め（あなたと送信者の間のネットワークで何か問題が発生しました）、1分間はパケットを受信しません。ビデオストリームが一時停止し、1分後にパケットが再び通過し始めます（IPが新しいルートを見つけました）。その後、TCPは失われた分を再送信し、ライブストリームを送信し続けます。前提として、帯域幅はストリームのビットレートより高く、pingは高すぎないので、短時間で、失われた1分がストリームのバッファーとして機能します。 、パケット損失が再び発生しても、気付かないでしょう。

さて、ビデオチャット中の遅延がひどいので、常にストリームの最後にいる必要がある、たとえばビデオ会議のように、これが良いアイデアではないいくつかのアプライアンスを考えることができますが、サッカーの試合中、またはコンサート中に、ストリームから1分遅れている場合、何が問題になりますか？さらに、すべてのデータを取得することが保証されているため、後でエラーなく受信できるように保存しておくことをお勧めします。

だから私は私の質問に連れて行きます。ライブストリーミングにTCPを使用することについて知らない欠点はありますか？それとも、帯域幅がある場合は、ネットワーク（フロー制御）に「より良い」という前提で、TCPを使用する必要がありますか？

ライブビデオにTCPを使用することの欠点：

1. 通常、ライブビデオストリーミングアプライアンスは、TCPストリーミングを考慮して設計されていません。TCPを使用する場合、OSはすべてのクライアントの未確認セグメントをバッファする必要があります。これは、特にライブイベントの場合は望ましくありません。おそらく、イベントの特異性のために、同時クライアントのリストは長くなります。視聴者が再生アクティビティをずらすため、事前に録画されたビデオキャストは通常​​、これに関してそれほど問題はありません。したがって、TCPはビデオオンデマンドの再生に適しています。
2. IPマルチキャストは、大勢の視聴者のビデオ帯域幅要件を大幅に削減します。TCPはIPマルチキャストの使用を妨げますが、UDPはIPマルチキャストに適しています。
3. ライブビデオは通常、カメラから記録された一定の帯域幅のストリームです。事前に記録されたビデオストリームはディスクから取得されます。TCPのロスバックオフダイナミクスにより、ソースストリームが一定の帯域幅にある場合（ライブイベントの場合と同様）、ライブビデオの配信が困難になります。カメラからディスクにバッファリングする場合は、予測できないネットワークイベントや変動するTCP送信/バックオフレートに十分なバッファがあることを確認してください。UDPはネットワークトランスポート層のドロップを考慮しないため、UDPを使用すると、このアプリケーションをより詳細に制御できます。

ちなみに、ネットワークについて説明するときは、「パッケージ」という言葉を使用しないでください。ネットワークは「パケット」を送信します。

しかし、サッカーの試合やコンサートの最中に、ストリームから1分遅れている場合はどうでしょうか。

一部のサッカーファンには、かなり。ワールドカップの試合などの注目度の高いイベント中に、みんなから歓声とうめき声が聞こえるとき、エンコーディング（または何でも）によってデジタルビデオストリームに数秒の遅延が存在するだけでも非常に煩わしいことが指摘されていますあなたがそれらを引き起こしたゲームの動きを見る前に、隣の（不誠実なアナログプログラムを見ている）。

スポーツについて多くのことを気にしている人（そして、少なくともここドイツでは、デジタルTVを購入する顧客の最大のグループです）にとって、ライブビデオストリームで1分遅れるのはまったく受け入れられないと思います（このように、 dこれが起こらない競争相手に切り替えます）。

通常、ビデオストリームは多少フォールトトレラントです。したがって、一部のパッケージが失われた場合（たとえば、途中のルーターが過負荷になっているため）、コンテンツは引き続き表示できますが、品質は低下します。

あなたのライブストリームがTCP / IPを使用していた場合、されるだろう強制的にこれらのドロップのパッケージを待つ前に、それは新しいデータを処理し続けることができます。

それは二重に悪いです：

• 古いデータは、（既に表示されているので、無益されたフレームのために、おそらくだもの）を再送信することと
• 古いデータが再送信されるまで、新しいデータは到着できません

できるだけ最新の情報を表示することが目標である場合（そして、ライブストリームの場合、フレームが少し悪く見えても、通常は最新の状態にしたい場合）、TCPは適切に機能しません。

記録されたストリームの場合、状況は少し異なります。おそらくより多くのバッファリング（おそらく数分！）が発生し、パッケージの損失によるアーティファクトよりもデータの再送信が必要になります。この場合、TCPは最適です（もちろん、UDPで実装することもできますが、TCPにはライブストリームの場合ほど多くの欠点はありません）。

UDPトランスポートに適したユースケースとTCPトランスポートに適したユースケースがあります。

ユースケースでは、ビデオのエンコーディング設定も指定します。サッカーの試合を放送するときの焦点は品質にあり、テレビ会議の場合は焦点が待ち時間にあります。

マルチキャストを使用して顧客にビデオを配信する場合、UDPが使用されます。

マルチキャストの要件は、ブロードキャストサーバーと顧客間の高価なネットワークハードウェアです。実際には、これは、会社がネットワークインフラストラクチャを所有している場合に、ライブビデオストリーミングにUDPとマルチキャストを使用できることを意味します。その場合でも、ビデオパケットにマークを付けて優先順位を付けるサービス品質も実装されているため、パケット損失は発生しません。

ネットワークハードウェアが顧客へのパケットの配布を処理するため、マルチキャストはブロードキャストソフトウェアを簡素化します。顧客はマルチキャストチャネルをサブスクライブし、ネットワークを再構成してパケットを新しいサブスクライバーにルーティングします。デフォルトでは、すべてのチャネルをすべての顧客が利用でき、最適にルーティングできます。

このワークフローでは、承認プロセスが困難になります。ネットワークハードウェアは、サブスクライブしたユーザーを他のユーザーと区別しません。承認の解決策は、ビデオコンテンツを暗号化し、サブスクリプションが有効なときにプレーヤーソフトウェアで復号化を有効にすることです。

ユニキャスト（TCP）ワークフローにより、サーバーはクライアントの資格情報を確認し、有効なサブスクリプションのみを許可できます。特定の数の同時接続のみを許可することもできます。

インターネット経由でマルチキャストが有効になっていません。

インターネット経由でビデオを配信するには、TCPを使用する必要があります。UDPを使用すると、開発者はパケットの再送信を再実装することになります。Bittorrent p2pライブプロトコル。

「TCPを使用する場合、OSはクライアントごとに未確認のセグメントをバッファリングする必要があります。これは、特にライブイベントの場合は望ましくありません。」

このバッファは何らかの形で存在している必要があります。プレーヤー側のジッタバッファについても同様です。これは「ソケットバッファー」と呼ばれ、サーバーソフトウェアはこのバッファーがいっぱいになったことを認識し、ライブストリームの適切なビデオフレームを破棄できます。サーバーソフトウェアは適切なフレームドロップロジックを実装できるため、ユニキャスト/ TCP方式を使用することをお勧めします。UDPの場合のランダムな欠落パケットは、ユーザーエクスペリエンスを低下させるだけです。このビデオのように：http : //tinypic.com/r/2qn89xz/9

「IPマルチキャストは、大勢の視聴者のビデオ帯域幅要件を大幅に削減します」

これはプライベートネットワークにも当てはまります。マルチキャストはインターネット経由で有効になっていません。

「TCPが損失するパケットが多すぎると接続が停止することに注意してください。UDPはネットワークトランスポート層のドロップを気にしないため、UDPはこのアプリケーションをより詳細に制御できます。」

UDPは、フレーム全体またはフレームのグループのドロップについても考慮しないため、ユーザーエクスペリエンスをこれ以上制御できません。

「通常、ビデオストリームは多少フォールトトレラントです」

エンコードされたビデオはフォールトトレラントではありません。信頼できないトランスポートを介して送信されると、前方エラー訂正がビデオコンテナに追加されます。良い例は、いくつかのオーディオ、ビデオ、EPGなどのストリームを運ぶ衛星ビデオ放送で使用されるMPEG-TSコンテナです。これは、衛星リンクが二重通信ではないために必要です。つまり、受信者は失われたパケットの再送信を要求できません。

二重通信を利用できる場合は、常にパケット損失のあるクライアントにのみデータを再送信し、すべてのクライアントに送信されるストリームに転送エラー修正のオーバーヘッドを含めることをお勧めします。

いずれの場合も、失われたパケットは受け入れられません。帯域幅が妨げられている例外的なケースでは、フレームのドロップは問題ありません。

パケットが欠落していると、次のようなアーティファクトが発生します。

一部のデコーダは、重要な場所でストリームが欠落しているストリームを中断できます。

新しいp2pライブプロトコルBittorent Liveをご覧になることをお勧めします。

ストリーミングに関しては、最初にサーバーの負荷を下げるのでUDPを使用する方が良いですが、主にマルチキャストでパケットを送信できるため、接続されている各クライアントに送信するよりも簡単です。

場合によります。ストリーミングしているコンテンツはどれほど重要ですか？重要な場合はTCPを使用してください。これにより、帯域幅、ビデオ品質（レイテンシを処理するために低品質を使用する必要がある場合があります）、およびレイテンシに問題が発生する可能性があります。ただし、確実にそこに到達するためのコンテンツが必要な場合は、それを使用してください。

それ以外の場合、ストリームが重要でなく、UDPのオーバーヘッドが少ない傾向があるため、UDPは問題ありません。

インターネットでライブイベントを配信する際の最大の問題の1つは「スケール」であり、TCPは適切にスケールできません。たとえば、オンデマンドの映画の再生とは対照的に、サッカーの試合をライブで放映しているときは、見ている人の数が容易に1000倍になる可能性があります。TCPを使用するそのようなシナリオでは、CDN（コンテンツ配信ネットワーク）の死刑判決です。

TCPがうまくスケーリングしない主な理由はいくつかあります。

1. TCPの最大のトレードオフの1つは、送信者と受信者の間で達成可能なスループットの変動性です。インターネット経由でビデオをストリーミングする場合、ビデオパケットはインターネット経由で複数のルーターを通過する必要があり、これらの各ルーターは異なる速度の接続で接続されます。TCPアルゴリズムは、TCPウィンドウを小さくオフにして開始し、パケット損失が検出されるまで増大します。パケット損失は輻輳の兆候と見なされ、TCPはウィンドウサイズを大幅に縮小して輻輳を回避することで応答します。したがって、今度はすぐに実効スループットが低下します。ここで、6-7ルーターホップを使用してクライアントにTCP転送するネットワーク（非常に通常のシナリオ）を想像してみてください。中間ルーターのいずれかがパケットを失うと、そのリンクのTCPは転送速度を低下させます。実際には、ルーター間のトラフィックフローは砂時計のような形をしています。常に中間ルーターの1つの間で上下にゴングします。ベストエフォートのUDPと比較して、効果的なスループットを大幅に下げる。

2. ご存じかもしれませんが、TCPは確認応答ベースのプロトコルです。たとえば、送信者が50ミリ秒離れている（つまり、レイテンシが2ポイント）としましょう。これは、パケットが受信者に送信され、受信者が確認応答を送信するのにかかる時間が100msになることを意味します。したがって、UDPベースの送信と比較して可能な最大スループットはすでに半分になっています。

3. TCPは、マルチキャスティングまたはAMTのマルチキャスティングの新たに出現した標準をサポートしていません。つまり、多くのクライアントが同じコンテンツを視聴している場合、CDNはパケットを複製してネットワークトラフィックを削減する機会がありません。それ自体が、CDN（AkamaiやLevel3など）がライブストリームにTCPを使用しないのに十分な理由です。

TCP UDPの議論を読んでいると、論理的な欠陥に気づきました。1分の遅延につながる1分の遅延を引き起こすTCPパケットの損失は、同じ損失が発生している間、UDPが1分間ドロップすることに関連付けることはできません。より公平な比較は次のとおりです。

TCPでパケット損失が発生します。数学的に完全なパケットをストリーミングしようとしてTCPがパケットを再送信している間、ビデオは停止します。ビデオは1分間遅延し、欠落したパケットが宛先になった後、中断したところから再開します。私たちは皆待っていますが、1つのピクセルを見逃すことはありません。

UDPでパケット損失が発生します。ビデオストリーム中の1秒間、画面の隅が少しぼやけます。誰も気づかず、失われたパケットを探すことなくショーが続きます。

ストリーミングするものはすべて、UDPから最大のメリットを得ます。TCPに1分の遅延を引き起こすパケット損失は、UDPに1分の遅延を引き起こしません。ほとんどのシステムが複数の解決ストリームを使用しているため、パケットが不足しているときに物事がブロック状になっていることを考えると、UDPを使用する方が理にかなっています。

ストリーミング時のUDP FTW。

帯域幅がビットレートよりはるかに高い場合、ユニキャストライブビデオストリーミングにはTCPをお勧めします。

ケース1：連続するパケットが数秒間失われる。=>ライブビデオは、トランスポート層が何であっても（TCPまたはUDP）クライアント側で停止します。ネットワークが回復すると、次のようになります。-TCPが使用されている場合、クライアントのビデオプレーヤーは、最初のパケット損失（タイムシフト）でストリームを再開するか、すべての遅延パケットをドロップし、タイムシフトなしでビデオストリームを再開するかを選択できます。-UDPを使用する場合、クライアント側での選択肢はなく、ビデオはタイムシフトなしでライブで再起動します。=> TCPと同等かそれ以上。

ケース2：一部のパケットがランダムに、しばしばネットワーク上で失われます。-TCPが使用されている場合、これらのパケットはすぐに再送信され、適切なジッタバッファがあれば、ビデオストリームの品質/遅延に影響はありません。-UDPを使用すると、ビデオ品質が低下します。=> TCPの方がはるかに良い

ビデオストリーミングの場合、帯域幅がシステムの制約になる可能性があります。マルチキャストを使用すると、使用されるアップストリーム帯域幅の量を大幅に減らすことができます。UDPを使用すると、接続されているすべての端末にパケットを簡単にマルチキャストできます。また、Pragmatic General Multicast（PGM）と呼ばれる信頼性の高いマルチキャストプロトコルを使用することもできます。私はそれについて何も知りませんし、広く使われているわけでもないと思います。

他のすべての理由に加えて、UDPはマルチキャストを使用できます。同じデータを送信するすべてのTCPユーザーをサポートすると、帯域幅が無駄になります。ただし、TCPを使用するもう1つの重要な理由があります。

TCPは、ファイアウォールとNATをはるかに簡単に通過できます。NATとオペレーターによっては、UDPホールパンチングの問題が原因で、UDPストリームを受信できないこともあります。

「use UDP」の回答はすべて、オープンなネットワークを想定し、「できる限りそれを詰め込む」アプローチを想定しています。古いスタイルのクローズドガーデン専用オーディオ/ビデオネットワークに適しています。

実際の世界では、送信はファイアウォールを通過し（マルチキャストをドロップし、場合によってはudpも発生します）、ネットワークは他のより重要な（$$$）アプリと共有されるため、ウィンドウスケーリングで乱用者を罰する必要があります。

これは、時間の問題というよりも、内容の問題です。TCPプロトコルでは、配信されなかったパケットをチェック、検証、および再配信する必要があります。UDPはこの要件を使用しません。したがって、ビデオのように、UDPを使用して数百万のパケットを含むファイルを送信した場合、一部のパケットが配信時に欠落していると、それらはおそらく欠落しません。