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
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.
HTTP/1.0
![][image2]
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
- New TCP connection for every HTTP request/response
- Added support for POST and HEAD methods
- Header fields with content type, status code and version number
- Response type – hypertext, scripts, media, stylesheets
- Support for keep-alive connection, but by default it is “off”
HTTP/1.1
**![][image3]**
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.
- Single TCP connection can carry multiple HTTP requests/responses, but each must still be sent serially.
- Added support for PUT, DELETE, TRACE, OPTIONS methods.
- Persistent connections by default
HTTP/2
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.
- Multiplexing – It is a feature in HTTP/2 where using one TCP connection, multiple request/responses (multistream) can be sent in parallel. Each HTTP request and response (called stream with a particular stream id) is divided into binary frames. Here both the client and the server send their messages(requests/responses) by dividing them into binary frames. Using the multiplexing feature, the client can send multiple requests to server without waiting for the previous request to complete. Thus HTTP/2 solves the HTTP head-of-line (HoL) issue. The image below shows how the multistream pipeline works.
![HTTP Pipeline][image4]
- Header Compression – HTTP2 uses HPACK type of header compression to reduce the header size
- Non-blocking downloads
- Server push
- Binary protocol rather than text.
- Solves HTTP head-of-line blocking (HoL) issue.
HTTP/3
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 –
- Uses QUIC as transport protocol which runs on top of UDP
- Solves TCP HoL issue
- Uses QPACK header compression mechanism
- Provides faster page load time
HTTP/2 vs HTTP/3
The below image shows the comparison between HTTP/2 and HTTP/3 stacks -
**![][image5]**
Similarities
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.
Differences
QUIC
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 –
- Runs on top of UDP
- Uses stream multiplexing without head-of-line (HoL) issue
- Reconstructed key mechanism of TCP (stream multiplexing, connection establishment, congession control, reliabilty) and becomes a reliable transport protocol
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]
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.
QUIC 0-RTT
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).
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.