Aln*_*tak 109
来自RFC 2616:
HTTP通信通常通过TCP/IP连接进行.默认端口为TCP 80,但可以使用其他端口.这并不妨碍HTTP在Internet上或其他网络上的任何其他协议之上实现.HTTP只假定可靠的传输; 可以使用任何提供此类保证的协议; HTTP/1.1请求和响应结构到所讨论协议的传输数据单元的映射超出了本规范的范围.
因此,尽管没有明确说明,但不使用UDP,因为它不是"可靠的传输".
编辑 - 最近,QUIC协议(更严格地说是伪传输或会话层协议)确实使用UDP来承载HTTP/2.0流量,而且Google的大部分流量已经使用了这个协议.但它尚未作为RFC发布.
unw*_*ind 39
通常,没有.
流式传输很少用于HTTP本身,而HTTP很少在UDP上运行.但是,请参阅RTP.
对于某些内容(在注释中),您没有显示资源的协议.如果该协议是HTTP,那么我不会将访问称为"流"; 即使它在某种意义上说是因为它通过网络串行发送(可能很大的)资源.通常,资源将在播放之前保存到本地磁盘,因此网络传输不是"流"通常所指的.
正如评论者所指出的那样,确实可以通过HTTP进行实际流式传输,这是由一些人完成的.
Fra*_*man 35
也许只是一些琐事,但UPnP将使用UDP格式的消息进行设备发现.
Exo*_*ron 19
是的,HTTP作为应用程序协议,可以通过UDP传输协议进行传输.以下是一些使用UDP和底层协议传输HTTP数据并将其传输给最终用户的服务:
本文包含有关UDP流传输及其可靠超集的更多详细信息,RUDP:可靠UDP(RUDP):下一个大流媒体协议？
如果您正在流式传输可能不一定通过 HTTP 传输的 mp3 或视频，事实上，如果是这样，我会感到惊讶。它可能是 TCP 上的另一种协议，但我看不出为什么您不能通过 UDP 进行流式传输。
如果您这样做，您必须考虑到您的数据是否会到达另一端是不确定的，但我可以认为您了解 UDP。
要回答您的问题，不，HTTP 不使用 UDP。不过，对于您所谈论的内容，mp3/视频流可以通过 UDP 发生，在我看来，永远不应该通过 HTTP 发生。
小智 5
答案：是的
原因：请参阅 OSI 模型。
说明：
HTTP 是一种应用层协议，可以用使用 UDP 的协议封装，提供比 TCP 更快的可靠通信。服务器守护进程和客户端显然需要支持这个新协议。Quake 2 协议证明UDP 可用于TCP 之上，为确保流量控制（例如块ID）的结构化通信系统提供基础。
我认为有些答案遗漏了一个重要的观点。UDP 和 TCP 之间的选择不应该基于数据类型（例如，音频或视频）或应用程序是否在传输完成之前开始播放（“流”），而应该是实时的。实时数据（根据定义）对延迟敏感，因此通常最好通过 RTP/UDP（基于 UDP 的实时协议）发送。
延迟不是来自文件的存储数据的问题，即使它是音频和/或视频，因此最好通过 TCP 发送，以便可以纠正任何数据包丢失。发送方可以提前读取并保持网络管道已满，接收方还可以使用大量播放缓冲，因此它不会被偶尔的 TCP 重传或暂时的网络减速所中断。限制情况是在播放开始之前传输整个录音。这消除了播放停顿的任何风险，但通常是不切实际的。
TCP 用于实时数据的问题不在于重传，而在于过度缓冲，因为 TCP 试图尽可能有效地使用管道而不考虑延迟。UDP 保留应用程序数据包边界并且没有内部存储，因此它不会引入任何延迟。