Slashdot Mirror
Taking Google's QUIC For a Test Drive
agizis writes "Google presented their new QUIC (Quick UDP Internet Connections) protocol to the IETF yesterday as a future replacement for TCP. It was discussed here when it was originally announced, but now there's real working code. How fast is it really? We wanted to know, so we dug in and benchmarked QUIC at different bandwidths, latencies and reliability levels (test code included, of course), and ran our results by the QUIC team."
Javascript required to view *static* content?
No.
Learn how to write a webpage properly.
As someone working with the project.
The benchmarking here is premature.
The code is not yet implementing the design, it is just barely working at all.
Again, they're not (yet) testing QUIC-- they're testing the very first partial implementation of QUIC!
That being said, it is great to see that others are interested and playing with it.
As I understand it, QUIC is largely about multiplexing - downloading all 35 files needed for a page concurrently. The test was the opposite of what QUIC is designed for
TCP handles one file at at a time* - first download the html, then the logo, then the background, then the first navigation button ....
QUIC gets all of those page elements at the same time, over a single connection. The problem with TCP and the strength of QUIC is exactly what TFA chose NOT to test. By using a single 10 MB file, their test is the opposite of web browsing and doesn't test the innovations in QUIC.
* browsers can negotiate multiple TCP connections, which is a slow way to retrieve many small files.
> reliable UDP protocol
You want a reliable *unreliable* datagram protocol protocol?
Sounds like something guaranteed to fail.
Everyone tries to reinvent TCP. Almost always they make something significantly worse. This is no exception.
Also FatPhil on SoylentNews, id 863
UDP and TCP have different uses; one isn't better than the other, they just do different things.
UDP is message-based. When I send a UDP message the remote end either gets the whole message or none of it. This can make parsing in applications a lot easier; rather than putting delimiters into a stream and trying to pick apart the data as it comes in in chunks I can be sure that I'm always working with a complete message, and the messages can by of different types/sizes/etc. as dictated by my application-layer needs. But there's a maximum size for messages, and if I need to send more data than fits in a single message it's up to my application to ensure they get put into the right order when they are received.
UDP is unreliable, in that if a UDP packet gets drop the message is lost and no notification is made to the sender. Often this is bad, but in certain instances it is valuable. One such instance is data with a short lifetime, such as games or streaming media. If I'm in the middle of a game and a packet gets dropped it doesn't do me any good to get that packet 2 seconds later -- the game has moved on. This unreliable nature also makes UDP simpler; there's no need to setup a "connection" to send UDP data -- you just slap an IP address on the packet and send it along, and the other end will get it or not and use it or not and you don't have to care. So if you're writing a server that will handle billions of clients UDP has a lot less overhead as it doesn't have to keep track of billions of "connections" (or have billions ports available).
TCP is a streaming protocol. You put data in on one end and it pops out in the same order on the other. This is great if you're sending a single file -- you can be sure the other end will get all the bits in the right order. But it also means if you have something important to say you have to wait in line until all of the preceding data has been transmitted, possibly including things that will be expired by the time they are received. It also means your application-layer protocol has to have some method to separate messages if you send more than one thing over a single connection.
TCP has reliable delivery. Often this is a good thing, as the sender can be sure the receiver got all the data (and got it in the right order). But in order to make the protocol reliable the receiver must acknowledge each and every packet from the sender, and the sender and receiver must store information about each other so they can keep track of this ongoing bi-directional connection. So there's at least a couple of round-trip exchanges necessary to setup a TCP connection, and when you connect to a server it must have a free TCP port number for each and every client it's connected to, and enough memory to keep track of all of the connections.
QUIC (and several other new-ish protocols) are proposing a sort of compromise protocol -- a protocol that's both message-based and reliable, and frequently that allows messages of any size. Such protocols provide the delivery assurances of TCP without the waiting-in-line issues the streaming model can produce, and they reduce the amount of setup overhead by allowing clients to open a single connection to the server and fetch many different things.