Quicksearch
Syndicate This Blog
Thursday, November 19. 2009
HTTP over UDP?
Comments
Display comments as
(Linear | Threaded)
I doubt HTTP over UDP has lower latency than a packet sent in an existing TCP session, which is what SPDY aims for, AFAICT.
More important than getting rid of the rigid request-response character of HTTP, however, is the optimisation of the header information to cut down on the total data that needs to be transferred, IMHO.
With UDP, you lose all the fancy things that make the Internet usable: QoS, congestion management, throughput throttling, window adaptation…
The performance impact would be absolutely disastrous.
That's a *horrible* idea. Without TCP's congestion control/avoidance, the Internet would collapse.
Not to mention, that UDP doesn't provide for reliable transmissions.
wouldn't SCTP be the best fit? the only practical problem is with its availability on different platforms (ie. Windows)
The problem is not the time taken to satisfy a small request but the number of small requests.
When I visit some widely popular web sites (such as mainstream-media sites) it's not uncommon to have over 100 images loaded in a single page view, I often see 250 or more! Maybe you could get some improvement by having the smaller images loaded via UDP, but it would still suck - such web sites need to be designed in a simpler manner!
I've recently changed my blog to use the "minify" plugin which combines Javascript and CSS files to reduce the number of HTTP requests. This type of thing is the solution to any problem that might be solved by UDP.
I actually saw this implemented in my sniffer the other day. Looks like Microsoft uses it to contact update servers and search services... maybe as some sort of initial "ping".
Here's a paper on the topic:
http://www.cs.technion.ac.il/Courses/Computer-Networks-Lab/projects/spring2000/http_udp/index.htm
#4: Try telling the UPnP community (http://www.upnp.org/resources/documents.asp) that HTTP over UDP is a horrible idea. They seem to think it is useful for small requests/responses.
Lotta close-minded opinions on this thread. Pure UDP would not be a good idea, but I do think there's plenty of UDP-appropriate conversations going on between client and server. With clever engineering, and well thought-out protocols, I think TCP+UCP HTTP could produce a much smoother browsing experience.
I have been thinking this over and over for years. UDP is great for all those little dot images and such. If it was enhanced with a hig level fragmentation, then for lost packets you could just ask for the missing piece. All the GET traffic could be moved to UDP, so one socket could service all requests to the web server, no listen, accept, fd limit, socket pass over pipe, linger, whee! Not so easy to use for POST, but you can number them and use a cache filter like rpc or a POST log to discard duplicate POST's. It would have to be keyed so multiple browsersn and users on the same host would not use the same POST key.
Lets start writing an RPC. Would this be a new revision of HTTP? Do we need to beat up a committee?
PS: Even with UDP, there is no reason you cannot design the GET packet to handle many GETs to the same server, even though each file comes back in separate packets. You get a doc, it references 25 css, image and frame pages, and you compose one packet to get them all.
PPS: How about "htdp://" for hyper text datagram protocol?
PPPS: I think many of those net features are in the IP header, not in TCP Header or options, so UDP has them. So many tricks have been employed to deal with the deluge of TCP overhead and inappropriateness: fake keepalive, packet consolidation, .... It should have been UDP in the first place, but TCP was the lazy choice.
Comments