HTTP 使用 UDP 吗？答案

【问题标题】：Does HTTP use UDP?HTTP 使用 UDP 吗？
【发布时间】：2010-09-24 07:31:38
【问题描述】：

这可能是一个愚蠢的问题：

HTTP 是否曾经使用过用户数据报协议？

例如：

如果使用 HTTP 流式传输 MP3 或视频，它是否在内部使用 UDP 进行传输？

【问题讨论】：

“网络”是什么意思？你的意思是用浏览器？还是通过公共互联网？
我的意思是说有一个 mp3 托管在一个类似 someserver/somemusic.mp3 的 URL 上。如果这是流式传输到任何客户端 - 浏览器、设备等，http 是如何传输的。如果我正确理解下面的答案，这将委托给 RTP。
端口 80 UDP 也为 HTTP 保留，我觉得这很有趣，因为我从未见过它使用过，我也无法想象它有什么用处。
保留它是因为 IANA 委员会比您有更灵活的想象力。 ;-) 他们认为它可能会有很好的用途。此外，不为 UDP/HTTP 保留端口 80 会使其对某些其他 UDP 协议开放，这只会在谈论端口 80 时引起混淆。

标签： http udp

【解决方案1】：

来自RFC 2616：

HTTP 通信通常发生通过 TCP/IP 连接。这默认端口是 TCP 80，但其他可以使用端口。这不阻止 HTTP 实现在任何其他协议之上 Internet，或在其他网络上。 HTTP 只假定可靠的传输；任何提供此类的协议可以使用担保；映射 HTTP/1.1 请求和响应结构到传输数据有问题的协议的单位是在这个范围之外规范。

所以虽然没有明确说明，但没有使用 UDP，因为它不是“可靠传输”。

编辑 - 最近，QUIC 协议（更严格地说是一种伪传输或会话层协议）确实使用 UDP 来传输 HTTP/2.0 流量，而且 Google 的大部分流量已经使用了它协议。它目前正在以HTTP/3 进行标准化。

【讨论】：

是否有任何网络服务器可以配置为接受非 TCP 连接？
这里对apache进行了修改pel.cis.udel.edu使用SCTP协议而不是TCP。
@nos 是的，Google 也有 SPDY。不过，两者都是可靠的传输机制。
@Alnitak SPDY 是应用层协议，而不是传输层协议。
@WalkingWiki 你当然是对的——在那种情况下，SPDY 取代了 HTTP，而不是 TCP。

【解决方案2】：

通常不会。

流式传输很少通过 HTTP 本身使用，HTTP 很少通过 UDP 运行。但是，请参阅RTP。

作为您的示例（在评论中），您没有显示资源协议。如果该协议是 HTTP，那么我不会将访问称为“流式传输”；即使它在某种意义上是因为它通过网络连续发送（可能很大）资源。通常，资源会在播放前保存到本地磁盘，因此网络传输不是通常所说的“流式传输”。

不过，正如评论者所指出的那样，确实可以通过 HTTP 进行流式传输，而且这是由一些人完成的。

【讨论】：

显然错了，HTTP 中没有任何东西可以阻止流式传输，它只是没有专用协议那么高效。使用块的 HTTP 动态流：adobe.com/products/httpdynamicstreaming HTTP 伪流：longtailvideo.com/support/jw-player/jw-player-for-flash-v5/…
YouTube 通过 http 流式传输。
@snowcrash09 我什至不能自己删除它，因为它已被接受。这很奇怪。我重写了它，我希望它现在不那么冒犯了。
只是对 HTTP 和流媒体的迂腐——回到 QuickTime 视频的黑暗时代，有 server push，其中 HTTP 连接将 MJPEG（多个 JPEG 图像）作为单独的一部分发送对 HTTP 请求的 MIME 多部分响应。每个 JPEG 图像到达并替换显示中的前一个图像。但你是对的@unwind，今天很少这样做，因为 RTP/RTSP 效果更好。
@nos Youtube 没有流式传输。浏览器将文件下载到缓存中，并在文件完全下载之前开始播放。尽管这模拟了流式传输，但事实并非如此。

【解决方案3】：

也许只是一些琐事，但 UPnP 将通过 UDP 使用 HTTP 格式的消息进行设备发现。

【讨论】：

更具体地说，UPnP 中使用 UDP 和 HTTP 类消息的部分称为 SSDP（简单服务发现协议）。消息结构相同，但METHOD 集合不同。之后，UPnP 使用其他协议（通常是 TCP）来完成它的其余工作。

【解决方案4】：

是的，HTTP 作为一种应用协议，可以通过 UDP 传输协议进行传输。以下是一些使用 UDP 和底层协议传输 HTTP 数据并将其流式传输给最终用户的服务：

XMPP 的 Jingle Raw UDP 传输方法
使用 UDT 的服务的编号 --- 基于 UDP 的数据传输协议，它是 UDP 协议的超集。
封装 HTTP 的传输层安全 (TLS) 协议以及上述 XMPP 和其他应用程序协议确实有一个在其传输层中使用 UDP 的实现；这种实现称为数据报传输层安全性 (DTLS)。
GNUTella 中的推送通知是通过 UDP 传输发送的 HTTP 请求。

本文包含有关 UDP 流式传输及其可靠超集 RUDP 的更多详细信息：Reliable UDP (RUDP): The Next Big Streaming Protocol?

【讨论】：

另一个问题：主流浏览器是否支持基于 UDP 的 HTTP 网页？
是的，因为 HTTP 在应用层，UDP 在传输层。浏览器不写入 TCP 或 UDP 数据包。他们也不写IP数据包。这些由操作系统和驱动程序处理。以太网层太低了，此时它可以在靠近 MAC 的芯片中。
@yanbellavance 这完全不正确。虽然浏览器和 Web 服务器确实不会生成 raw TCP 帧（也不会生成 UDP 帧），但它们确实必须选择要使用的传输，而对于普通 HTTP总是 TCP。然而，较新的 QUIC 伪协议确实使用 UDP。

【解决方案5】：

当然，它不一定必须通过 TCP 传输。我在 UDP 之上实现了 HTTP，用于卫星电视广播行业。

【讨论】：

【解决方案6】：

如果您正在流式传输不一定通过 HTTP 的 mp3 或视频，事实上，如果是，我会感到惊讶。它可能是 TCP 上的另一种协议，但我看不出为什么你不能通过 UDP 流式传输。

如果你这样做，你必须考虑到你的数据是否会到达另一端，但我可以认为你知道 UDP。

回答你的问题，不，HTTP 不使用 UDP。不过，就您所说的而言，mp3/视频流可以通过 UDP 发生，我认为永远不应该通过 HTTP 发生。

【讨论】：

HTTP 上的“流式传输”通常被称为（我认为最准确的）“伪流式传输”——一种通过 HTTP 的受监管的数据比特率。与我们的世界一样，营销类型滥用命名法，让像我们这样注重细节的人抓住细节。

【解决方案7】：

QUIC可能会在这个主题上有所改变

QUIC（Quick UDP Internet Connections，发音为 quick）是由 Google 开发并于 2013 年实施的实验性传输层网络协议。QUIC 支持通过用户数据报协议 (UDP) 在两个端点之间建立一组多路复用连接，旨在提供等同于 TLS/SSL 的安全保护，同时减少连接和传输延迟，以及每个方向的带宽估计以避免拥塞。 QUIC 的主要目标是优化当前使用 TCP 的面向连接的 Web 应用程序。

【讨论】：

【解决方案8】：

我认为有些答案遗漏了重要的一点。 UDP 和 TCP 之间的选择应该不基于数据类型（例如，音频或视频）或应用程序是否在传输完成之前开始播放它（“流式传输”），而是是否这是实时。实时数据（根据定义）对延迟敏感，因此通常最好通过 RTP/UDP（基于 UDP 的实时协议）发送。

延迟不是来自文件的存储数据的问题，即使它是音频和/或视频，所以它可能最好通过 TCP 发送，这样任何数据包丢失都可以得到纠正。发送方可以提前读取并保持网络管道已满，接收方也可以使用大量播放缓冲，因此不会因偶尔的 TCP 重新传输或暂时的网络减速而中断。限制情况是在播放开始之前传输整个记录。这消除了播放停止的任何风险，但通常是不切实际的。

实时数据的 TCP 问题不在于重传，而是过度缓冲，因为 TCP 试图尽可能高效地使用管道而不考虑延迟。 UDP 保留了应用程序包的边界并且没有内部存储，因此它不会引入任何延迟。

【讨论】：

【解决方案9】：

答案：是的

原因：参见 OSI 模型。

说明：

HTTP 是一种应用层协议，它可以封装在使用 UDP 的协议中，提供比 TCP 更快的可靠通信。服务器守护进程和客户端显然需要支持这个新协议。 Quake 2 协议证明 UDP 可以通过 TCP 为结构化通信系统提供基础，确保流量控制（例如块 ID）。

【讨论】：

如果没有比您在该级别应该拥有的更多信息，您无法手动击败 TCP。
“UDP 可以通过 TCP 使用”。它们都是传输层协议，所以是其中之一。

【解决方案10】：

（这是一个老问题，但值得更新答案。）

In all likelihood，HTTP/3 将使用QUIC protocol，描述为

基于 UDP 的多路复用传输

所以，from a certain point of view，你可以说 HTTP/3 将使用 UDP。

【讨论】：

【解决方案11】：

尝试使用 node-httpp 在 UDP 上运行 HTTP：

https://github.com/InstantWebP2P/node-httpp

【讨论】：

【解决方案12】：

http over udp 被一些 torrent 跟踪器实现使用（并且所有主要客户端都支持）

【讨论】：

请提供参考资料以支持您的陈述。
当我读到它时，Torrent UDP Tracker 协议是二进制的，根本不像 HTTP 那样格式化。 xbtt.sourceforge.net/udp_tracker_protocol.html

【解决方案13】：

理论上是的，可以将 UDP 用于 http，但这可能会有问题。例如，在您的示例中，正在流式传输 mp3 或视频，将会出现排序问题，并且由于 UDP 不是面向连接的，因此某些位可能会丢失，因此没有重传机制。

【讨论】：

很好：UDP is not connection oriented there is no retransmit mechanism.

【解决方案14】：

UDP 是流式传输的最佳协议，因为它不会要求 TCP 等丢失的包。如果它不提出要求，流程会更快，而且没有任何缓冲。

甚至流延迟也小于 TCP。那是因为 TCP（作为一种更安全的协议）要求丢失的包，覆盖现有的包。

所以 TCP 是一种太先进的协议，无法用于流式传输。

【讨论】：

这没有回答问题，但它可能是一个答案的推理。
re：“最好的流媒体协议”，因为“单个数据块的速度”比“所有数据通过”更重要。如果您的流无法轻松地从丢失的块中恢复，那么您最好使用 TCP。出于这个原因，许多安全视频协议选择 TCP - 可靠性比原始速度更重要。

【解决方案15】：

HTTP/3（又名 QUIC）使用 UDP 而不是 TCP。

https://http3-explained.haxx.se/en/the-protocol/feature-udp

【讨论】：