134

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?

greybeard
  • 2,249
  • 8
  • 30
  • 66
Sesh
  • 5,993
  • 4
  • 30
  • 39
  • What do you mean by: "the web"? You mean using a browser? Or over the public internet? – benc Sep 24 '09 at 07:27
  • What I meant to ask was say there is a mp3 hosted on a URL something like http://someserver/somemusic.mp3. If this is streamed to any client - browser, device etc. how does the http transfer this. If I understand the answers below correctly, this is delegated to RTP. – Sesh Sep 25 '09 at 16:12
  • Port 80 UDP is also reserved for HTTP, which I find amusing as I've never seen it used, nor could I imagine a good use for it. – Joshua Dec 05 '10 at 23:42
  • 1
    It is reserved because the IANA committee has a more flexible imagination that you do. ;-) They image that there just might be a good use for it. Besides, to not reserve port 80 for UDP/HTTP would leave it open for some other UDP protocol, which would just cause confusion when talking about port 80. – Jesse Chisholm Jan 26 '15 at 22:39

15 Answers15

134

From RFC 2616:

HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.

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.

Community
  • 1
  • 1
Alnitak
  • 334,560
  • 70
  • 407
  • 495
52

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.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • 18
    Obviously wrong, there is nothing in HTTP that prevents streaming it is just not as efficient as a dedicated protocol would be. HTTP Dyanmic Streaming using chunks: http://www.adobe.com/products/httpdynamicstreaming/ HTTP Pseudo-Streaming: http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/12534/video-delivery-http-pseudo-streaming – Steve-o Jul 07 '10 at 06:47
  • 16
    youtube streams over http. – nos Jun 09 '11 at 12:57
  • 7
    @snowcrash09 I can't even delete it myself, since it's accepted. That's weird. I re-wrote it, I hope it's less offending now. – unwind May 02 '12 at 14:04
  • 1
    Just being pedantic about HTTP and streaming -- way back in the dark ages of QuickTime video, there was `server push`, where the HTTP connection send MJPEG (multiple JPEG images) each as a separate part of a MIME multipart response to the HTTP request. Each JPEG image arrives and replaces the previous in the display. But you are correct @unwind, this is seldom done today, since RTP/RTSP works better. – Jesse Chisholm Jan 26 '15 at 22:32
  • 4
    @nos Youtube isn't streaming. The browser downloads a file into a cache and begins playing from the file before it is completely downloaded. Although this simulates streaming, it is not. – therealscifi Oct 16 '15 at 18:34
  • Not sure how reputable this site is, but [this](https://askleo.com/whats_the_difference_between_streaming_and_downloading_a_video_and_how_does_it_impact_the_limits_my_isp_imposes/) site supports what @SimonStiph says – Honinbo Shusaku Sep 14 '16 at 17:01
  • The new HTTP/3. –  Apr 09 '20 at 16:49
40

Maybe just a bit of trivia, but UPnP will use HTTP formatted messages over UDP for device discovery.

Frank Schwieterman
  • 24,142
  • 15
  • 92
  • 130
  • 4
    To be more specific, the portion of UPnP that uses UDP and HTTP-like messages is called SSDP (Simple Service Discovery Protocol). The message structure is the same, but the `METHOD` set is different. After that, UPnP uses other protocols (and usually TCP) for the rest of what it does. – Jesse Chisholm Jan 26 '15 at 22:35
20

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.

Pabru
  • 231
  • 2
  • 7
jkc
  • 201
  • 2
  • 2
20

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:

  • XMPP's Jingle Raw UDP Transport Method
  • A number for services that use UDT --- UDP-based Data Transfer Protocol, which is the a superset of UDP protocol.
  • The Transport Layer Security (TLS) protocol encapsulating HTTP as well as the above mentioned XMPP and other application protocols does have an implementation that uses UDP in its transport layer; this implementation is called Datagram Transport Layer Security (DTLS).
  • Push notifications in GNUTella are HTTP requests sent over UDP transport.

This article contains further details on streaming over UDP and its reliable superset, the RUDP: Reliable UDP (RUDP): The Next Big Streaming Protocol?

Exotic Hadron
  • 311
  • 2
  • 4
  • 1
    An another question : do major web browsers support web-pages HTTP over UDP? – user2284570 May 15 '15 at 09:52
  • yes because HTTP is in the application layer and UDP in the transport layer. browsers don't write TCP or UDP packets. Nor do they write IP packets. Those are handled by the OS and drivers. Ethernet layer is so low that it can be in chip close to the MAC at this point. – yan bellavance Dec 09 '16 at 01:29
  • 1
    @yanbellavance that's completely incorrect. While browsers and web servers indeed don't generate _raw_ TCP frames (nor UDP ones for that matter) they _do_ have to select the transport to use, and for normal HTTP that's always TCP. The newer QUIC pseudo-protocol does however use UDP. – Alnitak Sep 27 '18 at 09:16
6

Maybe some change on this topic with QUIC

QUIC (Quick UDP Internet Connections, pronounced quick) is an experimental transport layer network protocol developed by Google and implemented in 2013. QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. QUIC's main goal is to optimize connection-oriented web applications currently using TCP.

Sébastien
  • 406
  • 4
  • 9
6

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.

Henry B
  • 7,947
  • 10
  • 42
  • 46
  • 2
    "streaming" over HTTP is commonly called (what I consider most accurately) "pseudo streaming"--a regulated bit rate of data over HTTP. As is much in our world, the marketing types have abused the nomenclature leaving details-oriented folks like ourselves grasping for specifics. – Stu Thompson Dec 17 '08 at 19:36
6

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.

Phil Karn
  • 61
  • 1
  • 2
6

(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

multiplexed transport over UDP

So, from a certain point of view, you could say that HTTP/3 will be using UDP.

Community
  • 1
  • 1
jub0bs
  • 60,866
  • 25
  • 183
  • 186
5

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).

savvy
  • 59
  • 1
  • 1
  • 1
    You can't beat TCP by hand without more information than you're supposed to have at that level. – Joshua Dec 29 '10 at 19:39
  • 3
    "UDP can be used over TCP". They're both transport layer protocols, so it's one or the other. – opyate Feb 27 '12 at 12:50
4

http over udp is used by some torrent tracker implementations (and supporteb by all main clients)

user2946342
  • 41
  • 1
4

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.

HM Manya
  • 83
  • 1
  • 8
2

HTTP/3 (aka QUIC) uses UDP instead of TCP.

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

ChocolateOverflow
  • 460
  • 1
  • 4
  • 11
1

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.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
Pavel
  • 29
  • 1
  • 3
    this doesn't answer the question, However it could be reasoning for an answer. – Hawken Jun 02 '12 at 23:04
  • 2
    re: "best protocol for streaming" given that "speed of individual data chunks" it more important than "all the data getting through". If your stream cannot easily recover from missing chunks, then you'd better go with TCP. Many security video protocol choose TCP for that reason - reliability is more important than raw speed. – Jesse Chisholm Jan 26 '15 at 22:47
0

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

njin
  • 1
  • 1