The QUIC Internet. It’s the future!
The arrival of QUIC protocol
Given the interest medium readers showed for my previous article, I decided to write about an in-depth review of the future internet with QUIC protocol. Have a look at the following article if you’re interested.
QUIC (pronounced “quick”) is a transport layer (TL) protocol developed on top of UDP (User Datagram Protocol). Common TL protocols include TCP and UDP. TCP is the most common protocol used in network communication that we encounter, on a daily basis.
HTTP, the web browsing protocol (an application layer protocol) is a connection-oriented protocol. HTTP runs on top of TCP, which is the transport layer protocol for the web. This enables stable connectivity that is often required for reliable message transmission. Unlike UDP, TCP ensures the delivery of data reliably, the order of delivery, and supports flow control. Flow control ensures that the data rates are compatible, no faster than either party can tolerate/afford.
In contrast, UDP follows the “fire and forget” approach, where no guarantee or care is given if the data is received at the other end. One example is the DHT (distributed hash table) of BitTorrent. You might have seen the UDP trackers in uTorrent application. Read the following Quora discussion if you’re interested.
The Existing HTTP
The existing internet runs on top of TCP/IP stack.
In the TCP/IP stack, HTTP lies on the top application layer. Hence, for each HTTP request to initiate, a TCP connection must be initiated. Under HTTP2, improvements in the Application layer were performed allowing several improvements such as Multiplexing and Server push.
In HTTP-1 there were many separate connections for different resources. The overhead was significant due to the connection-oriented nature of TCP. The in HTTP-2 the connections were made to retain, and used the same connection with multiplexing to fetch more data. Hence, connection initiation overheads were reduced. Now let’s see how the QUIC based internet further enhances the web experience.
The TCP+TLS Internet
The traditional Internet used TCP connections which required the 3-way handshake mechanism.
SYN — The client wants to initiate a connection with a server. So the client machine sends a data segment with SYN (Synchronize Sequence Number). Its a data packet with a bit flag in TCP header.
SYN/ACK — Server responds to the client with SYN-ACK signal bits set. ACK stands for the acknowledgment. Now the TCP header has two bits active. Connections are bidirectional in TCP due to its reliability features.
ACK — Finally the client acknowledges the server that it’s all good to communicate.
TLS Extension
TLS stands for transport layer security which ensures web encryption. This ensures that nobody inspecting the data packets will be able to read the content within. The following diagram shows, how TLS works on TCP.
Before each request to complete, all of the above handshake steps must be completed. This makes the connection initiation process heavy and time-consuming.
Things are getting worse with the TCP slow start process. This is a TCP algorithm that estimates the congestion of the network and the speeds that can be agreed upon by both parties. Because of this, the connections can never use the total bandwidth of the network from the beginning.
HTTP-1.1 introduced keep-alive to mitigate this scenario by keeping the connections without ending them after each request. However, multiplexing was not available back then and requests had to be serially performed.
Although HTTP-2 used multiplexing to tunnel multiple requests across the same TCP connection, packet losses in TCP hinder the anticipated gains. This is because the ordered nature of TCP enforce the order of packet delivery. TCP only sees a stream of data between two sources. Yet inside, there could be multiple resources whose order of delivery is not a huge issue. This issue causes data to be unnecessarily delayed in cases of packet losses (Which is quite common in the congested complex networks). This is also called the HOL blocking (Head of Line Blocking) problem.
QUIC Internet
QUIC comes into play to attack the HOL Blocking problem in TCP internet. QUIC replaces TCP and tries to address the limitations caused by the TCP protocol.
QUIC streams share the same QUIC connection, so no additional handshakes and slow starts are required to create new ones, but QUIC streams are delivered independently such that in most cases packet loss affecting one stream doesn’t affect others. This is possible because QUIC packets are encapsulated on top of UDP datagrams.
Quoted from CloudFlare
We can see that we are going back to UDP, where connection initiations are much faster at the cost of reliability. In future HTTP streams will be mapped to QUIC based streams for the delivery of data. Hence HTTP-2 will be able to unleash the full capacity of its specification. Why call it HTTP-3? Keep reading!
QUIC also incorporates the TLS handshake within its connection initiation handshake. This means the QUIC protocol by default has TLS protection with half of the connection initiation delay.
Why HTTP-3?
Though the HTTP-2 can run on top of QUIC there are few catches in the QUIC streams. QUIC has no guarantee of the order of requests served unlike in TCP. Previous HTTP header compression (HPACK) heavily relies on the ordering in TCP. This makes HTTP-2 unusable on top of QUIC. Furthermore, HTTP-3 will be much simpler in terms of functionality since many of its functions have been moved to the QUIC layer.
Few Screenshots from Chrom Dev tools running on OSX.
Conclusion
In this article, I wanted to explain how the transport layer and application layer behaves in the HTTP-3. I hope you enjoyed reading this article as much as I did so writing. Cheers!
References:
Cloudflare Blog: HTTP3 past and future
YouTube Video: TCP 3 way handshake
Wikipedia: QUIC
An article you might like,
