HTTP 是否使用 UDP？
这可能是一个愚蠢的问题：
- HTTP 是否使用过用户数据报协议？
例如：
如果使用 HTTP 传输 MP3 或视频，它内部是否使用 UDP 进行传输？
This might be a silly question:
- Does HTTP ever use the User Datagram Protocol?
For example:
If one is streaming MP3 or video using HTTP, does it internally use UDP for transport?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
来自 RFC 2616：
因此，尽管没有明确说明，但不使用 UDP，因为它不是“可靠的传输”。
编辑 - 最近，QUIC 协议（更严格地说是伪传输或会话层协议）确实使用 UDP 来承载 HTTP/2.0 流量，并且 Google 的大部分流量已经使用此协议。 目前，它正在朝着 HTTP/3 的标准化方向发展。
From RFC 2616:
So although it doesn't explicitly say so, UDP is not used because it is not a "reliable transport".
EDIT - more recently, the QUIC protocol (which is more strictly a pseudo-transport or a session layer protocol) does use UDP for carrying HTTP/2.0 traffic and much of Google's traffic already uses this protocol. It's currently progressing towards standardisation as HTTP/3.
通常情况下，不会。
流媒体很少通过 HTTP 本身使用，并且 HTTP 很少通过 UDP 运行。 不过，请参阅RTP。
对于您的示例（在评论中），您没有显示资源的协议。 如果该协议是 HTTP，那么我不会将访问称为“流”； 即使它在某种意义上是因为它通过网络串行发送（可能很大）资源。 通常，资源在播放之前会保存到本地磁盘，因此网络传输并不是通常所说的“流式传输”。
不过，正如评论者指出的那样，确实可以通过 HTTP 进行流式传输，而且有些人已经做到了。
Typically, no.
Streaming is seldom used over HTTP itself, and HTTP is seldom run over UDP. See, however, RTP.
For something as your example (in the comment), you're not showing a protocol for the resource. If that protocol were to be HTTP, then I wouldn't call the access "streaming"; even if it in some sense of the word is since it's sending a (possibly large) resource serially over a network. Typically, the resource will be saved to local disk before being played back, so the network transfer is not what's usually meant by "streaming".
As commenters have pointed out, though, it's certainly possible to really stream over HTTP, and that's done by some.
也许只是一些琐事，但 UPnP 将使用基于 UDP 的 HTTP 格式消息来进行设备发现。
Maybe just a bit of trivia, but UPnP will use HTTP formatted messages over UDP for device discovery.
是的，HTTP作为应用协议，可以通过UDP传输协议进行传输。
以下是一些使用 UDP 和底层协议来传输 HTTP 数据并将其流式传输给最终用户的服务：
本文包含有关 UDP 流式传输及其可靠超集 RUDP 的更多详细信息：可靠的 UDP (RUDP)：下一个大流协议？
Yes, HTTP, as an application protocol, can be transferred over UDP transport protocol.
Here are some of the services that use UDP and an underlying protocol for transferring HTTP data and streaming it to the end-user:
This article contains further details on streaming over UDP and its reliable superset, the RUDP: Reliable UDP (RUDP): The Next Big Streaming Protocol?
当然，不一定非要通过TCP传输。 我在 UDP 之上实现了 HTTP，用于卫星电视广播行业。
Of course, it doesn't necessarily have to be transmitted over TCP. I implemented HTTP on top of UDP, for use in the Satellite TV Broadcasting industry.
（这是一个老问题，但值得更新答案。）
很可能，HTTP/3 将使用 QUIC 协议，描述为
因此，从某个角度来看，你可以说 HTTP/3 将使用 UDP。
(This is an old question, but it deserves an updated answer.)
In all likelihood, HTTP/3 will be using the QUIC protocol, which is described as
So, from a certain point of view, you could say that HTTP/3 will be using UDP.
如果您正在传输不一定通过 HTTP 传输的 mp3 或视频，事实上如果是通过 HTTP，我会感到惊讶。 它可能是 TCP 上的另一个协议，但我认为没有理由不能通过 UDP 进行流传输。
如果你这样做，你必须考虑到你的数据是否会到达另一端是不确定的，但我可以认为你了解 UDP。
回答你的问题，不，HTTP 不使用 UDP。
对于你所说的，mp3/视频流可以通过 UDP 发生，在我看来永远不应该通过 HTTP 发生。
If you are streaming an mp3 or video that may not necessarily be over HTTP, in fact I'd be suprised if it was. It would probably be another protocol over TCP but I see no reason why you cannot stream over UDP.
If you do you have to take into account that there is no certainty that your data will arrive at the other end, but I can take it that you know about UDP.
To answer you question, No, HTTP does NOT use UDP.
For what you talk about though, mp3/video streaming COULD happen over UDP and in my opinion should never happen over HTTP.
也许对这个主题有一些改变 QUIC
Maybe some change on this topic with QUIC
我认为有些答案遗漏了重要的一点。 UDP 和 TCP 之间的选择不应基于数据类型（例如音频或视频）或应用程序是否在传输完成之前开始播放（“流式传输”），而是基于数据类型（例如音频或视频）或应用程序是否开始播放数据（“流式传输”）它是实时。 实时数据（根据定义）对延迟敏感，因此通常最好通过 RTP/UDP（基于 UDP 的实时协议）发送。
对于文件中存储的数据来说，延迟不是问题，即使它是音频和/或视频，因此最好通过 TCP 发送，以便可以纠正任何数据包丢失。 发送方可以提前读取并保持网络管道充满，接收方还可以使用大量播放缓冲，这样就不会因偶尔的 TCP 重传或短暂的网络速度下降而中断。 限制情况是在播放开始之前传输整个录音。 这消除了播放停止的任何风险，但通常不切实际。
TCP 处理实时数据的问题不在于重传，而在于过多的缓冲，因为 TCP 试图尽可能高效地使用管道，而不考虑延迟。 UDP 保留应用程序数据包边界并且没有内部存储，因此不会引入任何延迟。
I think some of the answers are missing an important point. The choice between UDP and TCP should not be based on the type of data (e.g., audio or video) or whether the application starts to play it before the transfer is completed ("streaming"), but whether it is real time. Real time data is (by definition) delay-sensitive, so it is often best sent over RTP/UDP (Real Time Protocol over UDP).
Delay is not an issue with stored data from a file, even if it's audio and/or video, so it is probably best sent over TCP so any packet losses can be corrected. The sender can read ahead and keep the network pipe full and the receiver can also use lots of playout buffering so it won't be interrupted by the occasional TCP retransmission or momentary network slowdown. The limiting case is where the entire recording is transferred before playback begins. This eliminates any risk of a playback stall, but is often impractical.
The problem with TCP for real-time data isn't retransmissions so much as excessive buffering as TCP tries to use the pipe as efficiently as possible without regard to latency. UDP preserves application packet boundaries and has no internal storage, so it does not introduce any latency.
答案：是
原因：请参阅 OSI 模型。
说明：
HTTP 是一种应用层协议，可以使用 UDP 协议进行封装，可以提供比 TCP 更快的可靠通信。 服务器守护程序和客户端显然需要支持这个新协议。 Quake 2 协议证明UDP 可以在TCP 上使用，为确保流量控制（例如块ID）的结构化通信系统提供基础。
The answer: Yes
Reason: See the OSI model.
Explaination:
HTTP is an application layer protocol, which could be encapsulated with a protocol that uses UDP, providing arguably faster reliable communication than TCP. The server daemon and client would obviously need to support this new protocol. Quake 2 protocol proves that UDP can be used over TCP to provide a basis for a structured communication system insuring flow control (e.g. chunk ids).
一些 torrent 跟踪器实现使用 http over udp（并且所有主要客户端都支持）
http over udp is used by some torrent tracker implementations (and supporteb by all main clients)
理论上，可以将 UDP 用于 http，但这可能会出现问题。 例如，在您的示例中，正在流式传输 mp3 或视频，则会出现排序问题，并且某些位可能会丢失，因为 UDP 不是面向连接的，没有重传机制。
In theory yes it is possible to use UDP for http but that might be problematic. Say for instance in your example a mp3 or a video is being streamed there will be problem of ordering and some bits might go missing as UDP is not connection oriented there is no retransmit mechanism.
HTTP/3（又名 QUIC）使用 UDP 而不是 TCP。
https://http3-explained.haxx.se/en/the-协议/功能-udp
HTTP/3 (aka QUIC) uses UDP instead of TCP.
https://http3-explained.haxx.se/en/the-protocol/feature-udp
UDP 是最好的流式传输协议，因为它不像 TCP 那样要求丢失数据包。 如果它不提出要求，流程会更快并且没有任何缓冲。
甚至流延迟也小于 TCP。 这是因为 TCP（作为一种安全得多的协议）要求丢失包，从而覆盖现有包。
因此 TCP 是一种过于先进的协议，无法用于流式传输。
UDP is the best protocol for streaming, because it doesn't make demands for missing packages like TCP. And if it doesn't make demands, the flow is far more faster and without any buffering.
Even the stream delay is lesser than TCP. That is because TCP (as a far more secure protocol) makes demands for missing packages, overwriting the existing ones.
So TCP is a protocol too advanced to be used for streaming.
我们还有 UDSP，一种基于 UDP 的低延迟、实时、双向、强制加密且可靠的数据传输协议。
实际上合并正在进行中，不要运行。
https://github.com/universalweb/Network
We also have UDSP a UDP based low-latency, real-time, bi-directional, encryption enforced, and reliable Data Transport Protocol.
Actually merging in progress, do not run.
https://github.com/universalweb/Network