これはばかげた質問かもしれません:
- HTTPはユーザーデータグラムプロトコルを使用しますか?
例えば:
HTTPを使用してMP3またはビデオをストリーミングしている場合、内部で転送にUDPを使用していますか?
これはばかげた質問かもしれません:
例えば:
HTTPを使用してMP3またはビデオをストリーミングしている場合、内部で転送にUDPを使用していますか?
回答:
通常はありません。
ストリーミングがHTTP自体で使用されることはほとんどなく、HTTPはUDPで実行されることはほとんどありません。ただし、RTPを参照してください。
(コメント内の)例として、リソースのプロトコルを示していません。そのプロトコルがHTTPである場合、私はアクセスを「ストリーミング」とは呼びません。これは、ある意味では、ネットワークを介して(おそらく大きな)リソースをシリアルに送信しているためです。通常、リソースは再生される前にローカルディスクに保存されるため、ネットワーク転送は通常「ストリーミング」が意味するものではありません。
しかし、コメンターが指摘したように、実際にHTTPを介してストリーミングすることは確かに可能であり、それは一部によって行われます。
server push
HTTP接続はMJPEG(複数のJPEG画像)をそれぞれHTTPリクエストに対するMIMEマルチパート応答の個別の部分として送信していました。各JPEG画像が到着し、前の画像に置き換わります。しかし、あなたは正しい@unwindです。RTP/ RTSPがより適切に機能するため、これが今日行われることはほとんどありません。
RFC 2616から:
HTTP通信は通常、TCP / IP接続を介して行われます。デフォルトのポートはTCP 80ですが、他のポートを使用することもできます。これは、HTTPがインターネットまたは他のネットワーク上の他のプロトコルの上に実装されることを排除するものではありません。HTTPは信頼できるトランスポートのみを前提としています。そのような保証を提供する任意のプロトコルを使用できます。問題のプロトコルのトランスポートデータユニットへのHTTP / 1.1要求および応答構造のマッピングは、この仕様の範囲外です。
したがって、明示的には述べていませんが、UDPは「信頼できるトランスポート」ではないため使用されません。
編集 -最近では、QUICプロトコル(厳密には疑似トランスポートまたはセッションレイヤープロトコル)はHTTP / 2.0トラフィックの伝送にUDPを使用しており、Googleのトラフィックの多くはすでにこのプロトコルを使用しています。現在、HTTP / 3としての標準化が進んでいます。
ちょっとした雑学かもしれませんが、UPnPはUDP経由でHTTP形式のメッセージを使用してデバイスを検出します。
METHOD
セットが異なります。その後、UPnPは残りの処理に他のプロトコル(通常はTCP)を使用します。
はい、HTTPはアプリケーションプロトコルとして、UDPトランスポートプロトコルを介して転送できます。以下は、UDPと、HTTPデータを転送してエンドユーザーにストリーミングするための基になるプロトコルを使用するサービスの一部です。
この記事には、UDPを介したストリーミングとその信頼できるスーパーセットであるRUDPの詳細が含まれています。信頼できるUDP(RUDP):次の大きなストリーミングプロトコルですか
多分QUICでこのトピックにいくつかの変更
QUIC(Quick UDP Internet Connections、発音クイック)は、Googleによって開発され、2013年に実装された実験的なトランスポート層ネットワークプロトコルです。QUICは、ユーザーデータグラムプロトコル(UDP)を介した2つのエンドポイント間の多重接続のセットをサポートし、セキュリティ保護を提供するように設計されましたTLS / SSLに相当し、接続とトランスポートのレイテンシが短縮され、輻輳を回避するために各方向の帯域幅が推定されます。QUICの主な目標は、現在TCPを使用している接続指向のWebアプリケーションを最適化することです。
必ずしもHTTPを介しているとは限らないMP3またはビデオをストリーミングしている場合、実際にはそうであったとしたら驚きます。おそらくTCPを介した別のプロトコルですが、UDPを介してストリーミングできない理由はわかりません。
もしそうならあなたはあなたのデータが反対側に到着する確実性がないことを考慮に入れなければなりません、しかし私はあなたがUDPについて知っているとそれをとることができます。
いいえ、HTTPはUDPを使用しません。しかし、あなたが話していることについては、mp3 /ビデオストリーミングはUDP上で発生する可能性があり、私の意見ではHTTP上で発生するべきではありません。
理論的には、はい、httpにUDPを使用することは可能ですが、問題が生じる可能性があります。たとえば、mp3またはビデオがストリーミングされている例で、UDPは接続指向ではないため再送信メカニズムがないため、順序付けの問題が発生し、一部のビットが失われる可能性があるとします。
UDP is not connection oriented there is no retransmit mechanism
。
いくつかの回答には重要な点が欠けていると思います。UDPとTCPのどちらを選択するかは、データのタイプ(オーディオやビデオなど)や、転送が完了する前にアプリケーションが再生を開始するかどうか(「ストリーミング」)ではなく、リアルタイムかどうかに基づく必要があります。リアルタイムデータは(定義により)遅延の影響を受けやすいため、RTP / UDP(Real Time Protocol over UDP)経由で送信するのが最適です。
遅延は、オーディオやビデオであっても、ファイルからの保存データの問題ではないため、パケット損失を修正できるように、TCP経由で送信することをお勧めします。送信者は先読みしてネットワークパイプをフルに保つことができ、受信者は大量のプレイアウトバッファリングを使用することもできるため、不定期のTCP再送信や一時的なネットワークスローダウンによって中断されることはありません。制限的なケースは、再生が始まる前に録音全体が転送される場合です。これにより、再生が停止するリスクがなくなりますが、多くの場合、実用的ではありません。
リアルタイムデータのTCPの問題は、TCPがレイテンシに関係なくパイプをできるだけ効率的に使用しようとするため、過度のバッファリングほど再送信ではないことです。UDPはアプリケーションパケットの境界を保持し、内部ストレージを持たないため、レイテンシが発生しません。
答え:はい
理由: OSIモデルを参照してください。
説明:
HTTPは、UDPを使用するプロトコルでカプセル化できるアプリケーション層プロトコルであり、TCPよりも間違いなく高速で信頼性の高い通信を提供します。サーバーデーモンとクライアントは明らかにこの新しいプロトコルをサポートする必要があります。Quake 2プロトコルは、TCPを介してUDPを使用して、フロー制御(チャンクIDなど)を保証する構造化通信システムの基礎を提供できることを証明しています。
node-httppを使用してHTTP over UDPを実行してみます。
udp上のhttpは、いくつかのtorrentトラッカーの実装で使用されています(すべてのメインクライアントでsupporteb)
UDPは、TCPのような欠落しているパッケージを要求しないため、ストリーミングに最適なプロトコルです。そして、それが要求を行わない場合、フローははるかに速く、バッファリングもありません。
ストリームの遅延でさえTCPよりも小さいです。これは、TCP(はるかに安全なプロトコル)が不足しているパッケージを要求し、既存のパッケージを上書きするためです。
したがって、TCPはストリーミングに使用するには高度すぎるプロトコルです。