这可能是个愚蠢的问题：
例如：
如果使用HTTP流式播放MP3或视频，它是否在内部使用UDP进行传输？
答案 0 :(得分：103)
来自RFC 2616：
通常会进行HTTP通信 通过TCP / IP连接。该 默认端口是TCP 80，但其他 端口可以使用。事实并非如此 阻止实施HTTP 在任何其他协议之上 互联网或其他网络。 HTTP 只假设可靠的运输; 任何提供此类协议的协议 保证可以使用;映射 HTTP / 1.1请求和响应 结构到运输数据 有问题的协议的单位是 超出此范围 说明书
因此虽然没有明确说明，但不使用UDP，因为它不是“可靠的传输”。
编辑 - 最近，QUIC协议（更严格地说是伪传输或会话层协议）确实使用UDP来传输HTTP / 2.0流量，而且Google的大部分流量已经使用了这个协议。但它尚未作为RFC发布。
答案 1 :(得分：38)
通常，没有。
流媒体很少用于HTTP本身，而HTTP很少在UDP上运行。但请参阅RTP。
对于某些内容（在评论中），您没有显示资源的协议。如果该协议是HTTP，那么我不会将访问称为“流”;即使它在某种意义上说是因为它通过网络串行发送（可能很大的）资源。通常，资源将在播放之前保存到本地磁盘，因此网络传输通常不是“流式传输”的意思。
正如评论者指出的那样，当然可以通过HTTP实现流式传输，并且这已经由某些人完成了。
答案 2 :(得分：34)
也许只是一些琐事，但UPnP将使用UDP格式的消息通过UDP进行设备发现。
答案 3 :(得分：17)
当然，它不一定必须通过TCP传输。我在UDP之上实现了HTTP，用于卫星电视广播行业。
答案 4 :(得分：17)
是的，作为应用程序协议的HTTP可以通过UDP传输协议进行传输。 以下是一些使用UDP和底层协议传输HTTP数据并将其传输给最终用户的服务：
本文包含有关UDP流传输及其可靠超集的更多详细信息，RUDP：Reliable UDP (RUDP): The Next Big Streaming Protocol?
答案 5 :(得分：3)
如果您正在播放可能不一定通过HTTP的mp3或视频，事实上如果是的话，我会感到惊讶。它可能是TCP上的另一个协议，但我认为没有理由不能通过UDP流。
如果你这样做，你必须考虑到你的数据无法确定到达另一端，但我可以认为你知道UDP。
要回答你的问题，不，HTTP不使用UDP。 对于你所谈论的内容，mp3 /视频流可能会发生在UDP上，而且我认为永远不会通过HTTP发生。
答案 6 :(得分：3)
尝试使用node-httpp：
运行HTTP over UDP答案 7 :(得分：2)
答案：是
原因：请参阅OSI模型。
<强>阐释：
HTTP是一种应用层协议，可以使用UDP协议封装，提供比TCP更快的可靠通信。服务器守护程序和客户端显然需要支持这个新协议。 Quake 2协议证明UDP可以通过TCP使用，为结构化通信系统提供基础，确保流量控制（例如块ID）。
答案 8 :(得分：2)
http over udp被一些torrent跟踪器实现使用（并且所有主要客户端都支持）
答案 9 :(得分：2)
我认为某些答案缺少重点。 UDP和TCP之间的选择应该不是是基于数据类型（例如音频或视频），还是基于应用程序是否在传输完成之前开始播放（“流”），而是基于这是实时。实时数据（按定义）对延迟敏感，因此通常最好通过RTP / UDP（UDP实时协议）发送。
即使文件是音频和/或视频，延迟也不是文件存储数据的问题，因此，最好通过TCP发送，这样可以纠正任何数据包丢失。发送方可以提前阅读并保持网络管道畅通，接收方也可以使用大量播出缓冲，因此不会因偶尔的TCP重传或网络暂时中断而中断。极限情况是在回放开始之前传输了整个记录。这样可以消除播放停顿的任何风险，但这通常是不切实际的。
TCP实时数据的问题不是重传，而是过多的缓冲，因为TCP试图尽可能有效地使用管道而不考虑延迟。 UDP保留了应用程序数据包边界，并且没有内部存储，因此不会引入任何延迟。
答案 10 :(得分：1)
UDP是流媒体的最佳协议，因为它不会要求丢失像TCP这样的软件包。如果它没有提出要求，流程会更快，没有任何缓冲。
甚至流延迟也比TCP小。这是因为TCP（作为一种更安全的协议）要求丢失包，并覆盖现有包。
因此，TCP是一种过于先进的协议，无法用于流式传输。
答案 11 :(得分：1)
（这是一个老问题，但是值得更新。）
In all likelihood，HTTP / 3将使用QUIC protocol，它被描述为
通过UDP的多路传输
所以from a certain point of view，您可以说HTTP / 3将使用UDP。
答案 12 :(得分：0)
HTTP/3（又名 QUIC）使用 UDP 而不是 TCP。