これはばかげた質問かもしれません:
例:
HTTPを使用してMP3またはビデオをストリーミングしている場合、内部でトランスポートにUDPを使用しますか?
通常、いいえ。
ストリーミングがHTTP自体で使用されることはほとんどなく、HTTPがUDPで実行されることはほとんどありません。ただし、 RTP を参照してください。
(コメント内の)例として、リソースのプロトコルを表示していません。そのプロトコルがHTTPの場合、アクセスを「ストリーミング」とは呼びません。 Wordのある意味では、ネットワークを介して(場合によっては大きな)リソースをシリアルに送信しているためです。通常、リソースは再生される前にローカルディスクに保存されるため、ネットワーク転送は通常「ストリーミング」が意味するものではありません。
ただし、コメンターが指摘しているように、実際にHTTPでストリーミングすることは確かに可能であり、それは一部の人によって行われています。
RFC 2616 から:
HTTP通信は通常、TCP/IP接続を介して行われます。デフォルトのポートはTCP 80ですが、他のポートも使用できます。これは、HTTPがインターネットまたは他のネットワーク上の他のプロトコルの上に実装されることを妨げるものではありません。 HTTPは信頼できるトランスポートのみを想定しています。そのような保証を提供する任意のプロトコルを使用できます。問題のプロトコルのトランスポートデータユニットへのHTTP/1.1リクエストおよびレスポンス構造のマッピングは、この仕様の範囲外です。
したがって、明示的にそうは言っていませんが、UDPは「信頼できるトランスポート」ではないため使用されません。
EDIT-最近では、QUICプロトコル(厳密には擬似トランスポートまたはセッション層プロトコル)は、HTTP/2.0トラフィックとGoogleのトラフィックの多くはすでにこのプロトコルを使用しています。ただし、RFCとしてはまだ公開されていません。
ちょっとした雑学かもしれませんが、UPnPはデバイス検出のためにUDP上でHTTP形式のメッセージを使用します。
はい。アプリケーションプロトコルとしてのHTTPは、UDPトランスポートプロトコルを介して転送できます。以下は、HTTPデータを転送してエンドユーザーにストリーミングするためにUDPと基礎となるプロトコルを使用するサービスの一部です。
この記事には、UDPを介したストリーミングとその信頼できるスーパーセットであるRUDPの詳細が含まれています。 Reliable UDP(RUDP):The Next Big Streaming Protocol?
もちろん、必ずしもTCPで送信する必要はありません。私は衛星テレビ放送業界で使用するために、UDPの上にHTTPを実装しました。
QUIC を使用してこのトピックを変更することもできます
QUIC(クイックUDPインターネット接続、クイックと発音)は、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とTCPの間の選択はnotである必要があります。データのタイプ(オーディオまたはビデオなど)、または転送が完了する前にアプリケーションが再生を開始するかどうか( "ストリーミング」)が、それがリアルタイムであるかどうか。リアルタイムデータは(定義上)遅延の影響を受けやすいため、多くの場合、RTP/UDP(UDP上のリアルタイムプロトコル)を介して送信するのが最適です。
遅延は、たとえファイルがオーディオやビデオであっても、ファイルに保存されたデータでは問題にならないため、おそらくパケット損失を修正できるようにTCPで送信するのが最適です。送信者は先読みしてネットワークパイプをいっぱいに保つことができ、受信者は大量の再生バッファリングを使用できるため、時折のTCP再送信や一時的なネットワークの速度低下によって中断されません。制限的なケースは、再生が始まる前に記録全体が転送される場合です。これにより、再生が停止するリスクがなくなりますが、多くの場合非実用的です。
リアルタイムデータのTCPの問題は、TCPが待機時間に関係なくパイプを可能な限り効率的に使用しようとするほどの過剰なバッファリングほどの再送信ではありません。 UDPはアプリケーションパケットの境界を保持し、内部ストレージを持たないため、遅延が発生しません。
答え:はい
理由: OSIモデルを参照してください。
説明:
HTTPはアプリケーション層プロトコルであり、UDPを使用するプロトコルでカプセル化でき、TCPよりも間違いなく高速で信頼性の高い通信を提供します。サーバーデーモンとクライアントは、明らかにこの新しいプロトコルをサポートする必要があります。 Quake 2プロトコルは、UDPをTCP経由で使用して、フロー制御(チャンクIDなど)を保証する構造化された通信システムの基盤を提供できることを証明しています。
Node-httppでUDP over HTTPを実行してみてください。
http over udpは、一部のトレントトラッカーの実装(およびすべてのメインクライアントによるsupporteb)で使用されます。
(これは古い質問ですが、更新された回答に値します。)
すべての可能性において 、HTTP/3は QUICプロトコル を使用します。
uDP経由の多重化トランスポート
つまり、 特定の観点から 、HTTP/3はUDPを使用していると言えます。
UDPは、TCPのようなパッケージの欠落を要求しないため、ストリーミングに最適なプロトコルです。また、要求がなければ、フローははるかに高速で、バッファリングもありません。
ストリーム遅延でさえTCPよりも小さいです。これは、TCP(はるかに安全なプロトコルとして)が欠落しているパッケージを要求し、既存のパッケージを上書きするためです。
したがって、TCPは、ストリーミングに使用するには高度すぎるプロトコルです。