TCP and QUIC: Origins
The origins of the Transmission Control Protocol (TCP) can be traced all the way back to a paper published in 1974. Since then, TCP has been serving us well, and it will keep doing that in the foreseeable future. Although it’s remarkable that a 44-year old protocol has been adapted to the massive scale of the Internet, there are definitely improvements that could be made.
In 2012, Google started developing Quick UDP Internet Connections (QUIC). In 2014, they started its deployment on Google services, Chrome, and mobile apps. Today, QUIC is the default protocol for all Google-related products.
But why a new protocol? Unsurprisingly, the quick answer is “performance”; for Google, even the last millisecond of latency saved has a measurable impact on its revenue. In saying that, let’s see how are TCP and QUIC different.
Comparison between the TCP stack and QUIC
Here is how an application stack differs between TCP and QUIC:
As we can see, QUIC sits on top of UDP while encryption is part of the protocol. Since UDP is a connectionless protocol, QUIC handless all of the logic to guarantee a reliable connection between a client and a server. In addition, QUIC is built in the application layer, meaning that any updates don’t require OS changes.
The main performance improvement of QUIC over TCP come from two key differentiators:
- Connection handshake: TCP required a 3-way handshake to establish a connection, and, on top of that, you also need to negotiate the TLS connection. QUIC is built on top of UDP so it requires 1 packet to establish the connection, including TLS. Actually, if the client and the server have spoken in the past, then we are talking about a zero-handshake connection – that happens 75% the time.
- Multiplexing: the communication between the client and the server is multiplexed and this overcomes the head-of-line blocking issues that are common with TCP connections.
These and a few other QUIC features (improved congestion control, forward error correction) give it an edge over TCP. Google has done extensive testing and measurements and they have found that it improves Youtube video rebuffers by 15-18% and Google search latency by 3.6-8%. These numbers may seem low, but when you consider the fact that existing TCP applications have been highly optimized by Google, you understand that moving the needle by even a few percentage points is very significant.
In addition, you can put things into perspective if you consider that these improvements make up 35% of Google’s egress traffic which corresponds to 7-10% of the whole Internet traffic (as of January 2018). These improvements have a huge impact on the Internet traffic and user experience.
If you are using Chrome right now, there is an 88% chance that your connection is over QUIC and not TCP. It looks like QUIC is here to stay, especially when it’s backed by Google and has proven to be valuable. It remains to be seen if and when it will be adopted by other major companies.
