Taking Google's QUIC For a Test Drive 141
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."
Fuck you, site. (Score:5, Informative)
Javascript required to view *static* content?
No.
Learn how to write a webpage properly.
Re:first impression (Score:4, Informative)
And free ddos (Score:5, Informative)
The current problem with UDP is that many border routers do not check whether outgoing udp packages are from within their network. This is the base for DNS based ddos attacks. They are very difficult to mitigate on server level without creating openings for Joe job attacks instead... Standardizing on udp for other protocols will emphasize this problem
Benchmarking premature; QUIC isn't even 100% coded (Score:5, Informative)
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.
Re:Thank you (Score:4, Informative)
It has existed for decades. It's called TCP.
Did you RTFA? This new protocol appears to have little to no advantages over TCP and significant disadvantages under some circumstances.
alpha is, if your pages are all 10MB single files (Score:5, Informative)
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.
Re:alpha is, if your pages are all 10MB single fil (Score:3, Informative)
wherever you go, there you aren't (Score:5, Informative)
Those fuckers at www.connectify.me redirected my connection attempt to
http://www.connectify.me/no-javascript/ [connectify.me] so that even after I authorized Javascript for their site I was unable to navigate to my intended destination (whatever shit they pulled did not even leave a history item for the originally requested URL).
This sucks because I middle-click many URLs into tabs I might not visit until ten minutes later. It I had a bunch of these tabs open I wouldn't even have been able to recollect where I had originally been. In this case, I knew to come back here.
Those fuckers at www.connectify.me need to procure themselves an Internet clue stick PDQ.
Re:alpha is, if your pages are all 10MB single fil (Score:3, Informative)
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.
What the hell are you talking about? You're conflating HTTP with TCP. TCP has no such limitation. TCP doesn't deal in files at all.
Re:UDP vs TCP (Score:4, Informative)
The general gist is that UDP and TCP both have kind of an ideal mileu. UDP is great for small packets that you want delivered with a minimum of overhead, and if the packet is late, lost, or out of order, it won't kill anything.
TCP is great if you are sending large amounts of data at once, between a pair of systems, and in situations where its important not to lose packets or get them out of order, and you don't care that much if this takes a little extra time (occasionally perhaps a lot of extra time) to accomplish. Also good in situations where you'd like to know when your partner on the other side goes away for some reason.
Most applications are going to be in-between somewhere, so you have to make a decision. For example, if your packets are small and need to be delivered quickly, but you also need reliability, you might go with TCP just to get that reliability. Alternatively, if you can get away with it, you might instead go with UDP, but use dedicated links between the systems and a handshaking protocol at your application layer to prevent collisions.
Alternatively, you might do what Google is doing, and try to reimplement TCP's reliability in your application layer on top of UDP. The thing about UDP is that you can always reimplement any parts of TCP you need on top of it.
Re:Thanks. What were web page results? (Score:4, Informative)
Re:alpha is, if your pages are all 10MB single fil (Score:2, Informative)
I haven't RTFA and I don't know much about QUIC, but if it's what you suggest...
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 ....
...then it sounds like a really horrible idea. If I click on a link will I have to wait for 20MB of images to finish downloading before I can read the content of a webpage, only to find out it wasn't what I was looking for anyway?
Re:UDP vs TCP (Score:5, Informative)
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.