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