Fast Track

The Quick UDP Internet Connections (QUIC) protocol [1] originated in 2012 as a Google project led by Jim Roskind to improve security and performance over TCP. The protocol made the leap to four Requests for Comments (RFCs) [2]-[5] under numbers 8999 to 9002 in 2021 after a good five years of development at the Internet Engineering Task Force (IETF). In addition to Google, developers from Fastly, Mozilla, and others participated in the development of the transport protocol at the IETF.

However, QUIC is not just of academic value, as is shown by the first application protocols on which it is already based. For example, the third version of the Hypertext Transport Protocol (HTTP/3) uses QUIC. The first drafts of the Session Initiation Protocol (SIP) successor Real-Time Internet Peering for Telephony (RIPT) for voice over IP (VoIP) networks are also based on QUIC, and both are expected to increase penetration rapidly in the near future.

Specifics and Areas of Use

QUIC is considered a potential TCP successor, but netizens in particular are finding it difficult to appreciate because it merges OSI Layer 4 (transport layer) and Layer 5 (session layer), which breaks with old paradigms. QUIC is basically based on the connectionless User Datagram Protocol (UDP) and uses UDP port 443. However, QUIC itself has a connection-oriented architecture.

In version 1, the protocol is said to enable a change of the communication path during an ongoing session, which could be interesting in mobile scenarios. Mandatory TLS 1.3 encryption is intended to ensure confidentiality, integrity, and availability, which is equivalent to the security-by-default approach. Additionally, it is intended to avoid interference by active network components on the network path on the basis of TCP headers or content information.

In contrast to the multilayer session setup for classic communication in the form of a TCP and TLS handshake, TLS was integrated directly into the QUIC handshake with the intention to ensure lower latency in the connection setup and consequently an improved user experience. Cloud services and websites that rely on a large number of content sources, especially, lead to multiple, sequential processing of the handshake processes, which results in increased latency of the connection setup. This operation is what QUIC wants to do better, and the challenge is growing, especially for WAN connections, which have higher latency per se.

The protocol in its current version can detect packet loss and congestion in the flow within the communication relationship. Additionally, it prevents head-of-line blocking (i.e., situations in which the transmission of one packet slows down others). TCP sockets are built on source IP-port and target IP-port combinations. However, an IP change occurs in many cases, especially in mobile use (e.g., when switching from the enterprise network to a public mobile network when employees leave the company building).

What is of particular interest for mobile devices is that, in contrast to TCP, it is now possible to change the IP address and port connection parameters. The need to open a new session when switching from wired to wireless networks can be removed. If network address translation (NAT) is used, timeouts and, consequently, port adjustment can occur if active transmission is absent for a long period of time. To increase the efficiency of the communication relationship, QUIC also supports multiplexing multiple flows. The developers aimed to enable all these improvements without needing to adapt existing networks.

Protocol Structure

Connectionless UDP provides the basis of the QUIC protocol. Data is exchanged between applications through a QUIC connection in the form of streams; the streams themselves can be unidirectional or bidirectional. A connection like this supports multiple streams. A communication relationship is abstracted by connection identifiers from IP addresses and ports to enable the decoupling of this volatile information. However, the change can currently only be made on the client side. Despite changes to the IP or port information, the identifier ensures that the data arrives at the correct endpoint and that unique mapping is possible.

The connection identifier is defined on the client and server. The partner in the communication relationship needs to send the data to be transmitted to the connection identifier specified by the other end. If you have no need to differentiate between different connections on an endpoint, you have another option: zero-length connection IDs. Of course, these must not be used in combination with connection multiplexing on the same IP address-port combination.

How does the sender of data learn the respective initial connection ID that the potential recipient has assigned? The handshake has a source connection ID field in the long packet header for this purpose. If the receiver has communicated this information to the sender in the handshake, address mapping can take place in the reverse direction given the correct destination connection ID. If additional connection IDs are required in addition to the IDs initially transmitted in the handshake, they can be announced with NEW_CONNECTION_ ID frames.

The previously mentioned handshake phase is also the starting point of a QUIC connection. In addition to the connection IDs, the client and server also negotiate a TLS 1.3-based shared secret and the QUIC-based application protocol. In addition to the classic connection setup by handshakes, QUIC allows clients to send data to a server before receiving data from it (i.e., a resumption of the communication relationship) if connection information from an old connection is available. This feature is known as zero round-trip time (0-RTT); it is optional and not mandatory. The problem is the lack of protection against replay attacks.

The Header Structure

QUIC comes with short and long headers. Until the one round-trip time (1-RTT) keys have been exchanged, the slightly less efficient long headers are used; short headers are only used afterward. As you can see from the Wireshark screenshot in Figure 1, the QUIC header has a header length field in the connection information.

Figure 1: The Wireshark output of a call to cloudflare.com in Google Chrome without any special settings. Wireshark also offers a display filter for QUIC.

A value of 0 means a short header, and a 1 means a long header. Additionally, the connection information contains a fixed bit and a packet type; the fixed bit indicates whether it is for the version negotiation or a regular packet. The packet type is self-explanatory and has a total of four types in the long form: Initial, Handshake, Retry, and 0-RTT protected packets. To enable a correct interpretation of the header, a version field is set to 1, or 0x000001 in the current version. Additionally, you can see the previously mentioned source and target connection IDs and associated length information, followed by the QUIC payload.

To explain how version negotiation takes place, you need to refer to RFC 8999. In contrast to other processes, confidentiality and integrity cannot yet be ensured in the versioning process. When receiving a long header with an unknown or unsupported version number, the receiver returns 0x000000 in the version field. Additionally, it inserts a list of supported versions in the Supported Version field.

After the key and version have been negotiated, short headers are used in the 1-RTT phase; hence, the unique package type name 1-RTT . Because the connection IDs and versions were already announced or negotiated in the long headers during the handshake phase, the short header does not contain any source connection ID information, length information for the target connection ID, or version field. This arrangement makes the handshake more efficient, but it also comes with a spin bit header field, which supports passive latency monitoring in the communication path. The server only reflects the received spin value, whereas the client flips it from 1 to 0 or vice versa. Therefore, the end-to-end round trip time can be approximated on the basis of this flip.