1. ホーム
  2. networking

[解決済み] ビデオストリームにおけるTCPとUDPの比較

2022-11-28 06:01:47

質問

ネットワークプログラミングの試験から帰ってきたところですが、そこで聞かれた問題のひとつに もしあなたがビデオをストリームしようとするならば、TCPとUDPのどちらを使用しますか?保存されたビデオとライブビデオストリームの両方について説明しなさい。 . この質問に対して、彼らは単純に、保存されたビデオにはTCP、ライブビデオにはUDPという短い答えを期待していたのですが、帰り際に考えたのですが、ライブビデオのストリーミングには必ずしもUDPを使った方がいいのでしょうか?つまり、そのための帯域幅があり、サッカーの試合やコンサートをストリーミングしている場合、本当に UDP を使用する必要があるのでしょうか?

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

さて、これが良いアイデアではない家電製品もあります。例えば、ビデオ会議で が必要です。 というのも、ビデオチャット中の遅延はひどいものですが、サッカーの試合やコンサートでは、ストリームから1分遅れても問題ないでしょう?さらに、すべてのデータを取得することが保証されており、エラーなしで受信しているときに後で見るために保存しておく方がよいでしょう。

そこで、私の質問になります。ライブ ストリーミングに TCP を使用することについて、私が知らない欠点があるのでしょうか。それとも、帯域幅がある場合は、ネットワーク (フロー制御) に対してより良い TCP を使用する必要があるのでしょうか?

どのように解決するのですか?

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

  1. あなたが言及したように、TCP はすべてのクライアントのために未承認のセグメントをバッファリングします。 場合によっては、これは望ましくないことです。たとえば、非常に人気のあるライブ イベントの TCP ストリーミングの場合、同時クライアントのリスト (およびバッファリング要件) が大きくなります。 この場合、同時クライアントのリスト (およびバッファリング要件) は大きくなります。録画済みビデオ キャストは、視聴者が再生アクティビティをずらす傾向があるため、一般にこの問題はあまり発生しません。

  2. TCP の配信保証は、インタラクティブな会話には役立たないブロック機能です。 ネットワーク接続が 15 秒間低下したと仮定してください。 会話の一部を聞き逃したとき、私たちは当然、相手に繰り返してもらいます (あるいは、聞き逃したと思われる場合は、相手が積極的に繰り返してくれます)。 UDPは、この15秒間、会話の一部を聞き逃したとしても気にせず、何事もなかったかのように作業を続けます。 一方、TCPが最後の15秒間を再生するようにアプリを設計することもできます(そして、相手はそのことを望まないか、知らないかもしれません)。 TCPによるこのような再生は問題を悪化させ、会話の他の当事者と同期をとることをより困難にします。 パケットロスに直面したときの TCP と UDP の動作を比較すると、UDP の方が対話式の会話の状態に同期していることが容易であると言えます。

  3. IP マルチキャストは、大勢の視聴者のためのビデオ帯域幅の要件を大幅に削減します。マルチキャストは UDP を必要とします (そして、TCP とは互換性がありません)。 注意 - マルチキャストは一般にプライベート ネットワークに制限されています。 インターネット上でのマルチキャストは一般的でないことに注意してください。 また、マルチキャストネットワークの運用は、一般的なユニキャストネットワークの運用よりも複雑であることも指摘しておきます。

参考までに、ネットワークを説明するときに「パッケージ」という単語を使わないでください。 ネットワークはパケットを送ります。