Road To QUIC

QUIC (Quick UDP Internet Connection) is a relatively new protocol that is becoming the default choice of the FAANGs when it comes transferring data over web. This blog describes the emergence of QUIC protocol overcoming the limitations of various HTTP versions.

Evolution of HTTP

The Hypertext Transfer Protocol (HTTP) is an application layer protocol which runs on top of TCP/IP and it becomes the foundation of any data exchange in the World Wide Web.

HTTP has 4 stable versions – HTTP/0.9, HTTP/1.0, HTTP/1.1 and HTTP/2. HTTP/3 was introduced in July, 2021 and already 2/3rd's of web browsers support it.

                               ![HTTP Protocol Versions][image1]


HTTP/0.9 was the initial version of HTTP which is used as the underlying communication protocol for W3C (World Wide Web Consortium).

It was a very simple client-server, request-response and telnet-friendly protocol which supports only GET as a request method and hypertext as response type. It contains no HTTP headers. Here the connection terminates immediately after sending the response.



As HTTP/0.9 is extremely simple and its usage is limited, the new version of HTTP i.e., HTTP/1.0 introduced many new features to make it more versatile.

Some of those features include



The main drawback of HTTP/1.0 is that it opens new TCP connection for each request/response i.e., a connection can’t be reused to overcome this the next version HTTP/1.1 comes.


Websites are becoming much more complex with the rising volume of content, such as streaming media. In order to accommodate this demand, HTTP/1.1 capabilities kept getting stretched near to the breaking point, first with support for multiple TCP connections to a website to request resources, followed by experimental support for pipelining requests. But eventually a new protocol needed to be introduced.

HTTP2 is the next version of HTTP after HTTP/1.1 with some major improvements.

                                                               ![HTTP Pipeline][image4]             


HTTP/2 solved the HTTP head-of-line blocking issue by introducing the multiplexing feature in a single TCP connection. But if a packet is lost in that TCP streams, all the streams will wait until the lost packet is re-transmitted and received depending on TCP’s congestion control mechanism. So, the TCP head-of-line blocking problem still exists in HTTP/2.

HTTP/3 solves this TCP head-of-line (HoL) issue by using a new transport layer protocol called QUIC (Quick UDP Internet Connection) which runs on top of UDP.

HTTP/3 is the latest and major version of HTTP after HTTP/2. It can be described as HTTP/2 over QUIC (since HTTP/3 is designed for QUIC). The aim of HTTP/3 is to provide fast, reliable secure web connection using the Google’s QUIC protocol.

Some of the major features of HTTP/3 –

HTTP/2 vs HTTP/3

The below image shows the comparison between HTTP/2 and HTTP/3 stacks -



HTTP/2 and HTTP/3 use same syntax and semantics structures. And the same request/response methods, status codes and message fields are applicable for both. Also, both use their header compression algorithm (HPACK and QPACK) which are similar in design.


Transport Layer Protocol
QUIC running over UDP
Header Compression Algorithm
Head-of-line blocking (HoL) issue
This solves HTTP HoL
This solves HTTP HoL as well as TCP HoL
Handshake Protocol
Handshake Negotiation
Can be negotiated by TLS (default version is 1.2, later versions are optional) with ALPN (Application-Layer Protocol Negotiation) protocol extension
As HTTP/3 is over QUIC, it uses Alt-svc. (with TLS 1.3 as the minimum version of TLS)
Handshake Time
Slower due to TCP and TLS handshakes
Faster due to QUIC transport protocols that handles streams by itself


Quick UDP Internet Connection (QUIC) is a new multiplex transport layer network protocol standard which is built on top of UDP. The main goal for implementing this protocol is to improve user experience by reducing the page load time and to improve the transport performance of HTTPS traffic. QUIC is essentially TCP+TLS+HTTP2.

The latest version of HTTP, HTTP/3 is designed to use the advantages of QUIC. QUIC excludes the TCP head-of-line blocking issue as it handles streams by itself.

Some of the key features of QUIC –

Packet Exchanges

There are 3 types of packets being exchanged between a client and a server for a typical QUIC connection. The messages flow diagram is shown below.

                                      ![QUIC 1 RTT Handshake][image6]

QUIC Handshake Traffic

1. Initial Protection Packets

First the Client sends an Initial packet which contains a TLS 1.3 Client Hello inside a CRYPTO type frame. This Client Hello contains different extensions like Server Name Indication (SNI) of the target Server, QUIC transport parameters, compression certificates etc., also the compression methods and different Cipher Suites supported by the Client.

If the QUIC and TLS 1.3 parameters are acceptable by the Server, then the Server also sends an Initial packet which contains an Acknowledgement (ACK) and a TLS 1.3 Server Hello inside a CRYPTO type frame. This Server Hello contains the Cipher Suite accepted by the Server and different extensions like key share, supported versions etc.

After this Server Hello, the Client sends an ACK (acknowledgement) to the Server.

Here all the 3 initial packets may contain a padding frame to increase the size of the size of the packet as necessary.

2. Handshake Packets

After the Initial packets are being exchanged between the Client and Server, the Server sends a Handshake packet which contains the rest of server-side messages like Certificates, Encrypted Extensions related to server authentication.

Then the Client verifies those certificates and the QUIC handshake ends with a Handshake message sent by the client.

3. Protected Payload Packets

Once a secure QUIC connection is established, the client and the server start transferring the data securely between them.


To reduce the time to establish a new connection, QUIC introduces the 0-RTT feature. Here, if a client has connected to a server previously using 1-RTT, the server must store a copy of flow control related transport parameters like initial_max_data, initial_max_stream_data_bidi_local etc.

Next time, in QUIC 0-RTT mode, the client immediately starts data transfer with the server without waiting for any handshake to complete.

However, the 0-RTT has some design flaws, it allows replay attack.

Why We Should Choose QUIC?

Our grand old transport layer protocol TCP is implemented in OS kernels and different middle-boxes where tampering the handshake packets is easy.

But as QUIC is implemented in user-level like browsers on top of UDP, it is more flexible, user-friendly and has the capability to support many more devices in short span of time.

And in QUIC, the transport related information is encrypted by providing different layers of protection, the handshake packets are not so easy to sniff. So, it provides more secure data transfer in the web.

QUIC In Keysight Technologies ATI

At Keysight Technologies ATI (Application and Threat Intelligence), we support several QUIC versions like GQUIC (Q043, Q046, Q050, T051), IETF QUIC (draft-22, 27, 29), QUIC Facebook mvfst (draft-22 and draft-27).

QUIC Versions in ATI

Here the QUIC traffic is customizable from changing the Connection ID, Packet Number, Server Name Indication (SNI), User Agent and Payload Size (volume of encrypted application traffic)


during BreakingPoint System (BPS) simulation. The user can also mix it with other traffic to create real world traffics.