We tunnel everything through HTTP these days. Poor old port 80 is the backdoor through the firewall, but the hole is small and only truly suited to certain protocols. One of the crazy wrappers is taking streaming video and putting it in the HTTP envelope. This is nuts as HTTP is of course running on TCP/IP which gives you reliable ordered packets. The overhead of making sure this is the case is large, and is not needed for fire and forget type applications. Video, VoIP, gaming, they all favour UDP as you just want to shove bytes down as fast as you can and if you miss a packet or two it doesn’t matter, you are onto the next.
Wikipedia tells the tale:
Difference between TCP and UDP
TCP (”Transmission Control Protocol”) is a connection-oriented protocol, which means that upon communication it requires handshaking to set up end-to-end connection. A connection can be made from client to server, and from then on any data can be sent along that connection.
- Reliable – TCP manages message acknowledgment, retransmission and timeout. Many attempts to reliably deliver the message are made. If it gets lost along the way, the server will re-request the lost part. In TCP, there’s either no missing data, or, in case of multiple timeouts, the connection is dropped.
- Ordered – if two messages are sent along a connection, one after the other, the first message will reach the receiving application first. When data packets arrive in the wrong order, the TCP layer holds the later data until the earlier data can be rearranged and delivered to the application.
- Heavyweight – TCP requires three packets just to set up a socket, before any actual data can be sent. It handles connections, reliability and congestion control. It is a large transport protocol designed on top of IP.
- Streaming – Data is read as a “stream,” with nothing distinguishing where one packet ends and another begins. Packets may be split or merged into bigger or smaller data streams arbitrarily.
UDP is a simpler message-based connectionless protocol. In connectionless protocols, there is no effort made to setup a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction, from source to destination without checking to see if the destination is still there, or if it is prepared to receive the information. With UDP messages (packets) cross the network in independent units.
- Unreliable – When a message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgment, retransmission and timeout.
- Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.
- Lightweight – There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP.
- Datagrams – Packets are sent individually and are guaranteed to be whole if they arrive. Packets have definite bounds and no split or merge into data streams may exist.
What if we had nice UDP support in the browser itself, something that could fall back to HTTP if necessary. You would need that to make sure that the firewall gods wouldn’t stop things working, but think of the YouTube traffic and how much better streaming video would be! And games! And, Skype!
Can we do it, or is there too much inertia around “HTTP won. It’s good enough”
March 25th, 2008 at 10:10 am
I can’t see how this would work well with current firewalls and NAT systems, but there must be some way.
It would probably have to start in Flash: “open this firewall port for higher quality YouTube”.
March 25th, 2008 at 10:23 am
I for one will vouch for UDP, as it is the most effective protocol for communicating between a team of mobile robot agents. I like its attitude: send things fast, no worries if it doesn’t get there.
Very interesting to think it extended into the browser world….
March 25th, 2008 at 11:14 am
Migrating to HTTP over UDP at first would make more sense wouldn’t it?
http://www.cs.technion.ac.il/Courses/Computer-Networks-Lab/projects/spring2000/http_udp/index.htm
March 25th, 2008 at 11:39 am
Sure, why not, but I don’t think your problem is with your browser.
As far as I can tell, plugins like Flash implement their own networking:
“Note that Flash Player deploys the protocols directly, so server communication and file management will work while the SWF file runs in Flash Player locally outside the browser. This is ideal because the browser provides an interface that is often unnecessary or in conflict with the interface contained in the Flash application.”
http://www.adobe.com/devnet/flash/articles/local_network_playback_02.html
So, for stuff like “livecasting” ala Justin tv or flash games, that’s prolly a great idea, but one for Adobe to implement.
For stuff like Youtube, which is streaming but not live, I usually want to watch the whole video, and so it’s not so okay to drop some frames here and there. As such, I’m not sure that reimplementing TCP’s reliability in the application layer is a step forward, per se.
Turning to browser-only apps, I’m going to go on an uneducated bend here and say, if you’re coding something in Ajax where the TCP overhead is your bottleneck, you’re probably coding something _crazy_.
Disclaimer: I could be wrong, have no professional experience in the area.
March 26th, 2008 at 2:42 am
Huh? Isn’t UDP part of IP? TCP/IP encompasses datagrams and connection-orientated transports of do I have to go back to CompSci lectures? Please correct this schoolboy/pre-grad error
March 26th, 2008 at 6:45 am
UDP has existed for some years, nobody has used it and I don’t think it’s casual. I have been involved in some hard-wire communication projects and it’s very rare the case where you can say that order is not important. I’m not talking about reliability, but about ordering.
Imagine the typical messaging system: a chat, a stock trade system, etc. Now, suppose a network cut that lasts for thirty seconds, where messages get accumulated during this period, and delivered NOT IN THE ORIGINAL ORDER to the other side.
The only case I have studied of where UDP was used implemented their own mini version of TCP for serializing packet arrival. That’s Uncool.
March 26th, 2008 at 11:13 am
Just a couple of points:
1) Flash is working on UDP support, as part of project Pacifica (they need it for VOIP and, maybe, youtube). So, this is not just a wishful thinking.
2) UDP is used by DNS and many other short communication protocols. It is more suitable for the niches, but it is not useless (@Ignacio). Just look at /etc/services, they list a good number of UDP endpoints.
December 4th, 2009 at 11:17 am
As Alexandre Rafalovitch sais, UDP is as important as TCP. And there’s more than TCP/UDP in the internet, there’s a specific protocol for streaming/VoIP..
In my opinion, the main advantage of using UDP on the web is AJAX.
Does anyone had used Wikipedia’s search bar? The one located behind the logo. It makes a transfer every time you type in a character. So you need to start a TCP connection, transferring 3 packets for this single purpouse, then the character itself, and finally closing the connection with 2 more packets.. over and over!!
Another good advantage could be server-to-client connection, or server-side events. This means that the server could send new data to clients without them to request it. (Get new post as they are sended by the autor, tweeter..)
August 12th, 2010 at 9:37 am
UDP would be a win-win. The world already has a protocol to marshall packets via UDP: it’s called TFTP. It’s simple, it works, and it’s used to bootstrap routers remotely. It prevents direct access to system resources; in short, it has so few functions that it’s quite secure. And because it’s UDP it’s F A S T.
November 18th, 2011 at 11:38 am
As a web developer I’d love to have access to UDP in the client to do client-side reporting, just as it’s being used currently to do server-side metrics with projects like https://github.com/etsy/statsd