An Overview of QUIC Protocol
HTTP/3 is on the horizon. It is exciting to see how this upcoming version will change the overall web communications because it has some critical improvements over the current protocol, HTTP/2. These improvements have been largely achieved by the new transport layer protocol called QUIC protocol. In this article, let us have a quick look at QUIC and see how it works.
QUIC stands for Quick UDP Internet Connections. As defined in the IETF internet-draft QUIC is a multiplexed and secure general-purpose transport protocol. It mainly operates on the transport layer of the network stack, between the IP layer and the application layer. One of the main goals of establishing this protocol has been to reduce the latency of web communication that is a bottleneck existing in the current communication stack.
One interesting question is why QUIC is implemented over UDP? UDP communications are known to be connectionless and unreliable in their very nature. So why would we ‘upgrade’ our current reliable form of communication to something unreliable? In the first place, the problem is that there is no other option than TCP and UDP to really choose from. Most of the communication devices out there in the world only understands these two protocols and you cannot practically use a communication protocol unless the devices know how to run that. The good thing about QUIC is that even though it functions over UDP, QUIC has placed mechanisms in place to make the connections reliable.
Before diving deep into more details, let’s have a look at where QUIC stands.
The stack to the left represents the current communication model of the web, based on HTTP/2, TLS and TCP. The stack to the right is the emerging communication model HTTP/3 which is based on QUIC.
There are two things to notice in this image. One is that QUIC actually expands into the application layer territory without being limited to the transport layer itself. The reason lies in the underlying implementation of the protocol. As mentioned earlier, because it is very hard to escape from both TCP and UDP completely, QUIC is implemented at the application level rather than at the OS level. In other words, this is implemented in userspace, not in kernel space like TCP or UDP. The second thing to notice in this image is that QUIC covers the TLS layer functions. In fact, QUIC uses encryption by default. This also comes as one of the major differences between HTTP version 2 and 3 because unlike in HTTP/2, there is no unencrypted version in the QUIC protocol.
Why is QUIC better? There are several key features that make QUIC desirable over the TCP + TLS + HTTP/2. Let’s discuss them.
Low-latency connection establishment
This is one of the biggest improvements we can get with QUIC. To establish a connection in the TCP + TLS protocol it takes at least 3 round trips from the client to the server. First, the TCP handshake needs to happen. Then, the TLS handshake takes place and the server has to share its certificates with the client. After verifying the certificates, the exchange of keys and session establishment happen. Finally, application data can be communicated between the client and the server. This process takes at least 3 round trips.
However, QUIC is different. Connection establishment in QUIC takes only 1 RTT (Round Trip Time) and it is possible to re-establish a connection in 0 RTT.
The above two diagrams summarize these two scenarios. In the first-ever exchange between a client and a server, the client initiates the communication by sending a Client Hello message. The server responds to this with initial configuration data, certificates and source address token. The client can then acknowledge the completion of the hello message. After authenticating the server, the client can immediately start sending encrypted application data. The details needed to establish a session is also bundled in the first round trip, so the client and server can immediately establish an encrypted communication channel.
After the first contact, it is configurable to re-establish the client-server connection in practically 0 round trip time. The server information is cached at the client end, making it possible to send the Client Hello message immediately followed by encrypted data.
Multiplexed Streams
A client and a server communicating over the QUIC protocol basically uses multiplexed streams to send and receive information. Multiplexed streams avoid the head of line blocking problem prevalent in TCP connections.
The TCP head of line blocking problem arises when a packet gets lost or dropped before reaching its destination. Applications using HTTP/2 and TCP, communicate with a server usually using a single TCP connection. Within a single connection, they can send and receive data over multiple streams simultaneously. However, if one packet gets lost during the transmission, all streams have to halt their operation until the lost packet is received from retransmission.
QUIC eliminates this issue by having multiplexed streams. That means each stream belonging to a connection is independent of each other. In case of a packet loss, only the relevant stream will be affected and others can continue their data transmission as normal. Moreover, upon arrival at the destination, they can be reassembled and passed over to the application without having to wait for a lost packet in another stream.
Better Flow Control and Congestion Control
Flow control is essential to prevent a fast sender from overwhelming a receiver with data packets than the receiver can handle. In QUIC, flow control mechanisms are implemented at both stream level and connection level. Stream level flow control is important to ensure that a single stream does not dominate the receiving buffer. The same goes out for connection flow control as well.
Stream level and connection-level flow control are done as follows. The receiver can control the maximum amount of data a sender can transmit in one stream at a time. Also, connection-wise, a receiver can configure the number of streams from which the sender can transmit data to the receiver. The receiver may gradually increase the number of bytes its willing to receive per each transmission by sending out MAX_STREAM_DATA frames.
Also, there is a richer signalling process in QUIC than in TCP when it comes to flow control and congestion control. For example, if a retransmitted packet is assigned a new sequence number (not the original sequence number). This helps to distinguish between the dropped and the retransmitted packet easily when sending back acknowledgements. Another additional feature is that the delay between the receipt of a packet and sending of the acknowledgement is recorded. This helps to calculate the Round Trip Time for the data more accurately. Moreover, QUIC supports up to 256 NACK ranges in contrast to the 3 SACK ranges in TCP.
Encryption and Authentication
As mentioned earlier, QUIC is encrypted by default. The payload section is fully encrypted and some parts of the header are also encrypted. It is an improvement over TCP because in TCP, the headers are completely in plain text and unauthenticated. This makes the TCP connections vulnerable to some types of attacks. However in QUIC, even though there are some parts in the header that are not encrypted they are authenticated at the receiving end. It prevents any attacker from manipulating the header information while in transit.
QUIC uses TLS 1.3 as its security layer. The QUIC handshake mentioned above is a combination of cryptographic and transport handshake between two endpoints. The frames carrying the cryptographic information are called Crypto frames. During the cryptographic handshake, the authenticated key exchange happens i.e. server is authenticated, the client is optionally authenticated and keys are established.
Easy Connection Migration
In QUIC, connections are uniquely identified by a 64-bit connection ID. This helps the two endpoints to use the same connection even in a scenario of an IP address change, for example changing from cellular data to a WiFi connection. This is not possible in the current TCP based model. TCP identifies a connection uniquely by the source and destination IP addresses and source and destination port numbers. QUIC is also robust for port number changes which can occur in a scenario such as NAT rebinding. Another advantage gained by the connection ID is that it will not cause a packet to be sent to an incorrect destination if the packet was in transit when the IP address or the port number change took place.
References
- https://www.chromium.org/quic
- https://tools.ietf.org/html/draft-ietf-quic-transport-29
- https://docs.google.com/presentation/d/15e1bLKYeN56GL1oTJSF9OZiUsI-rcxisLo9dEyDkWQs/edit#slide=id.g99041b54d_0_0
- https://www.youtube.com/watch?v=idViw4anA6E
