And The Internet Created TCP … and It Was Bad … And So Google Created QUIC

And The Internet Created TCP … and It Was Bad … And So Google Created QUIC

QUIC — Quick UDP Internet Connections

It is well-known that the Internet has changed greatly since its birth, and the protocols that we still use are not fit for purpose. TCP — the protocol that basically built the Web — is a poor standard, and has the overhead of the three-way handshake, and then we have to handshake all of the data transmitted. Why can’t we just make a connection with another host, and then just send the data without adding all the additional things that TCP requires? Well, a chance is coming …

Go fire-up Wireshark, and open your Chrome browser, and have a look at the traffic in the trace, and you might be baffled, as where you would expect lots of TLS 1.2 traffic, there’s lots of QUIC UDP packets:

and if you follow a UDP stream you see the data contained in it:

So I’ll have to go back to my tutorials and re-write them to include QUIC (“Quick”). So what is it? Well it’s Google’s new protocol and which started its life in 2012 (as created by Jim Roskind), but now is integrated fully into Chrome. While Chrome supports it, it is still not supported by many other browsers.

The one thing many security people know is that the three way handshake is slow, and TCP provides a great overhead. Both TCP was really designed in the days where latency didn’t matter that much, and where we used unreliable networks. These days networks are highly reliable, and fast. So why bother with TCP, at all, when UDP just sends the data with a small overhead. These days, there’s perhaps no need to handshake data, as you know it’ll get there reliably. It is now defined by the IETF [here].

It basically works by multiplexing data streams — as defined by HTTP/2 — at either end of the connection, and remove the latency of the handshaking that is required in TCP. We thus get shorter connection time and reduced latency, along with using bandwidth estimations to reduce congestion problem. In a world of IoT and 5G, reduced latency will be a key attribute, and where we will get instant access to sensor data without requiring the massive overhead of TCP. There are also plans for FEC (Forward Error Correction) — as you would find in a CD-ROM, can also be built in, so even if there are errors, the receiver can correct them.

And, finally, watch our for QUIC HTTP/3, and where we map HTTP connections over the QUIC protocol. For IoT and 5G, there is no other way, and TCP will be retired forever, and where we multiplex data stream … just like we did in the telecoms era.