What is QUIC and is it really?quick?

If you have never heard of the word QUIC and you are a developer, whose work is somehow related to the fascinating world of protocols which administer the communications between devices located anywhere in the world, or you are just someone who is curious, then hang on, cause the content in this article can get really disturbing (just kidding).

First and foremost thing, what does QUIC stands for?

Quick UDP Internet Connection, an Internet Transfer Protocol that is set to replace Transmission Control Protocol (TCP) in the coming years for sure. HTTP 3, the latest version of Hyper Text Transfer Protocol (HTTP), is built on top of QUIC. QUIC has not been officially published yet, but I think we can except it by the end of 2021.

You must have noticed that QUIC contains an acronym within itself, UDP or the User Datagram Protocol which is a transport layer protocol, which forms the base of the QUIC protocol. QUIC is built on top of UDP layer just as TCP is built on top of IP layer.

History

Now for a bit of history about QUIC. QUIC was developed by Jim Roskind at Google. It was introduced publicly 2 years before HTTP 2 was published, that is in 2013. The name Quick UDP Internet Connection was given by Google, but when it came under the supervision of the Internet Engineering Task Force (IETF), they changed its name to QUIC. Confused?? What the IETF did was that they named the protocol QUIC which was not an acronym. They thought maybe it made a difference.

How is QUIC different from TCP?

The major difference between QUIC and TCP is that, QUIC is built on top of UDP which is an unreliable protocol, unreliable in the sense that UDP does not care about whether the packet was successfully delivered to the other end or not, it’s job is just to send the packet. But TCP is itself a reliable protocol, it makes sure that your packet reaches the other end. Both TCP and UDP are Transport Layer Protocols, and QUIC is built on top of UDP. 

HTTP 1.1 and HTTP 2 both can work on top of TCP, but only HTTP 3 is supported to work with QUIC.

TCP requires TLS 1.2 or TLS 1.3 in order to encrypt the HTTP requests, but QUIC has TLS 1.3 built within itself.

HTTP 2 had the concept of streams. Earlier we could send only 1 request at a time through a TCP connection. Researchers thought that we weren’t using all of TCP’s capacity of sending packets by sending 1 request per connection. So, they introduced streams in HTTP 2, remember they introduced streams in HTTP 2, they did not make any changes to the underlying TCP layer. HTTP 2 could send multiple requests in the form of streams at the same time through a single TCP connection. But, there was drawback in this, in case data from one of the streams got lost, then the party sending the requests had to send that whole packet which had the part of the stream which was lost and also containing parts of other streams, because of this the processing of other streams was halted because data from one of the streams got lost. This was impractical in terms of time. In short the streams in HTTP 2 were not independent. QUIC had the concept of streams integrated in itself and the streams here were independent. So, HTTP 3 had access to streams from the underlying QUIC layer and it did not had to manage them.

What makes QUIC so much better?

The best thing about QUIC is that it is quick. It is faster than TCP. The main reason for this is the reduced number of round trips which needs to be completed before the actual encrypted is sent to the other party. Since TCP is a reliable transport protocol, so it needs to complete a TCP handshake, in order to get in sync with server, so that if any of the packets get lost during transmission then the receiving ends know which packet is lost. But UDP being an unreliable network does not require this. After TCP handshake there is the TLS handshake (2 round trips in case of TLS 1.2 and 1 round trip in case of TLS 1.3). In case of QUIC, it has TLS 1.3 integrated within it, so it completes the TLS handshake along with the other information which it needs to send in the beginning of the connection. TCP along with TLS needs minimum of 2 to 3 round trips whereas in case of QUIC it requires 0 to 1 round trips.

QUIC uses TLS 1.3 only, whereas TCP supports TLS 1.2 in addition to 1.3. So QUIC does not suffer from the attcks which come as a drawbacks of TLS 1.2 like, slow speed and vulnerability to attacks like RC4 and BEAST exploits. 

QUIC uses a special identifier (I think it uses a UUID) as a connection ID to identify each connection between a client and a server. So, if for any reason you get disconnected from your network or your IP address changes for some reason, then you don’t have to initiate the handshake between you and server again, as the connection does not depend on your IP address, you have the connection ID and using it you can continue with your request from that very point when you got disconnected. In case of TCP connections, the whole TCP and TLS handshake has to be carried out again.

Now to the most important question. Is it really fast?

In the above section I discussed how QUIC needs less number of round trips to and from the server before it actually starts transmitting encrypted data. This, decrease in the round trips, greatly affects the speed of transmitting and receiving data and even if the connection is lost due to some reason, then also the client does not have to perform the whole handshake process again(also discussed above). All of these together make QUIC much faster than HTTP 2.

It is because of it's speed that companies are starting to integrate it in their systems.

Companies besides Google which have integrated QUIC in their system are facebook and youtube. There are some other not so well-known companies which have started using QUIC.

builtwith.com has a list of 3,817,311 websites currently using QUIC and the stats graph shows that the usage of QUIC has sky rocketed after 2015.