HTTP 使用 UDP 吗？

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

  • HTTP 用过用户数据报协议吗？

例如:

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

207940 次浏览
小开
最佳答案

一般来说，没有。

流很少通过 HTTP 本身使用，HTTP 也很少通过 UDP 运行。

对于您的示例(在注释中) ，您没有显示资源的协议。如果那个协议是 HTTP，那么我不会把访问称为“流式”; 即使从某种意义上来说，它是因为它通过网络连续发送一个(可能很大的)资源。通常，在回放之前，资源将被保存到本地磁盘，所以网络传输不是通常所说的“流”。

但是，正如评论者指出的那样，通过 HTTP 实现流当然是可能的，而且有些人已经这样做了。

小开

也许只是一些琐碎的小事，但是 UPnP 将使用 UDP 上的 HTTP 格式的消息来发现设备。

小开

如果您正在流一个 mp3或视频，可能不一定是通过 HTTP，事实上，我会感到惊讶，如果它是。它可能是另一个 TCP 协议，但我认为没有理由不能通过 UDP 流。

如果你这样做，你必须考虑到，有没有确定性，你的数据将到达另一端，但我可以认为，你知道 UDP。

为了回答你的问题，不，HTTP 不使用 UDP。 对于你所说的，虽然，mp3/视频流可以发生在 UDP 和在我看来，永远不应该发生在 HTTP。

小开

来自 RFC 2616:

HTTP 通信通常发生 通过 TCP/IP 连接 默认端口是 TCP 80，但其他 端口可以使用 阻止 HTTP 的实现 在任何其他协议之上 互联网，或在其他网络 只假定有可靠的运输; 任何提供这种 保证可以被使用; 映射 HTTP/1.1请求和响应的 传输数据的结构 所涉及的协议单位是 超出了这个范围 规格。

因此，尽管它没有明确说明，UDP 没有被使用，因为它不是一个“可靠的传输”。

EDIT ——最近，QUIC 协议(更严格地说是一个伪传输或会话层协议)确实使用 UDP 来传输 HTTP/2.0流量，而 Google 的大部分流量已经使用了这个协议。它目前正朝着 HTTP/3标准化的方向发展。

小开

答案是: 是的

原因: 查看 OSI 模型。

解说:

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

小开

UDP 是流媒体的最佳协议，因为它不会对丢失的包(如 TCP)提出要求。如果它不提出要求，那么流就会快得多，而且没有任何缓冲。

即使流延迟也比 TCP 小。这是因为 TCP (作为一个更加安全的协议)需要丢失包，覆盖现有的包。

因此，TCP 是一个过于先进的协议，不能用于流。

小开

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

小开

是的，HTTP 作为一个应用程序协议，可以通过 UDP 传输协议传输。 下面是一些使用 UDP 和底层协议传输 HTTP 数据并将其流向最终用户的服务:

  • XMPP 的静格原始 UDP 传输方法
  • 使用 UDT-- UDT 的服务的编号，这是 UDP 协议的超集。
  • 传输层安全(TLS)协议封装了 HTTP 以及上面提到的 XMPP 和其他应用程序协议，它的传输层确实有一个使用 UDP 的实现，这个实现被称为数据传输层加密(DTLS)。
  • GNUTella 中的推送通知是通过 UDP 传输发送的 HTTP 请求。

本文包含有关 UDP 上的流及其可靠的超集 RUDP: 可靠的 UDP (RUDP) : 下一个大型流协议？的进一步详细信息

小开

一些种子跟踪器实现使用 http over udp (所有主客户端都支持 http over udp)

小开

也许 QUIC在这个话题上会有一些改变

QUIC (QUIC，发音快速)是一个实验性的传输层网络协议，由谷歌开发并于2013年实施。QUIC 支持在两个端点之间通过用户数据报协议(UDP)进行多路连接，其设计目的是提供相当于 TLS/SSL 的安全保护，同时减少连接和传输延迟，并在每个方向进行带宽估计以避免拥塞。QUIC 的主要目标是优化当前使用 TCP 的面向连接的 Web 应用程序。

小开

理论上是可以为 http 使用 UDP 的，但是这可能会有问题。例如，在您的示例中，一个 mp3或视频正在流媒体播放，这时会出现排序问题，并且一些比特可能会丢失，因为 UDP 不是面向连接的，没有重新传输机制。

小开

我认为有些答案忽略了一个重要的问题。UDP 和 TCP 之间的选择应该基于 没有的数据类型(例如，音频或视频)或应用程序是否开始播放它在传输完成之前(“流”) ，但它是否是 真正的时间。实时数据(根据定义)是延迟敏感的，所以通常最好通过 RTP/UDP (Real Time Protocol over UDP)发送。

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

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

小开

(这是一个古老的问题，但应该有一个更新的答案。)

在所有可能性 中，HTTP/3将使用 QUIC protocol，这被描述为

UDP 上的多路传输

因此，从某个角度来看，您可以说 HTTP/3将使用 UDP。

小开

HTTP/3(又名 QUIC)使用 UDP 代替 TCP。

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


提交答案