↓Skip to main content
  1. My Blog Posts and Stories/

More on HTTP/3

··1185 words·6 mins
Computer Networks
Table of Contents

After reading all the new articles about why HTTP/3 is better than HTTP/2 and how it is so much cooler and better, I decided to go on and read more about it.

HTTP3 VS HTTP2 #

There are a few differences between HTTP3 and HTTP2, the main ones include:

  1. Protocol Stack
  2. Handshake
  3. Speed

Network stack differences #

HTTP 2 VS HTTP3 Protocol Stack differences
Protocol Stack of HTTP2 and HTTP3

Similarities

  1. Both are built on top of IP
  2. Both makes use of TLS in some way

Differences

  1. HTTP3 is built on top of QUIC and UDP while HTTP2 is built on top of TCP + TLS
  2. QUIC acknowledges packets and TCP acknowledges bytes.

Handshake differences #

HTTP2 VS HTTP3 Handshake differences
Handshakes of HTTP2 and HTTP3

As QUIC removes the required for a TCP handshake and thus only needs to send the certificate over to the client in the Server hello before the first request can be sent.

In comparison, HTTP2 requires a TCP handshake and then a TLS handshake before the first request can be sent.

Speed differences #

HTTP Speed Comparison
Adapted from requestmetrics.com

The graph above shows the speed of HTTP2 and HTTP3. As you can see, HTTP3 is faster than HTTP2 and both of them are much faster than HTTP 1.1.

For a deeper dive, please visit requestmetrics.com.

What is QUIC #

QUIC stands for Quick UDP Internet Connections. It is a new transport protocol that is designed to be faster than TCP. It is based on UDP and uses TLS 1.3 for encryption. It is a multiplexed protocol, which means that it can send multiple streams of data over a single connection. It is also a lossy protocol, which means that it can recover from packet loss. It is also a connection-oriented protocol, which means that it can be used to establish a connection between two endpoints.

Origin of QUIC #

It was originally designed by Jim Roskind at Google and was first released in 2012. It was first announced publicly in 2013. The RFC was submitted in June 2015 to IETF (Internet Engineering Task Force) for standardization.

Goals of QUIC #

  1. Ability to deploy quickly.
  2. Setting up a low latency secure connection.
  3. Streams and multiplexing.
  4. Better loss recovery and flexible congestion control.
  5. Connection Migration.

Ability to deploy quickly #

To make the protocol deployable quickly, QUIC has chosen to be implemented on top of UDP as most devices already support UDP. This means that QUIC can be deployed on top of UDP without having to wait for the deployment of new protocols which will take time to roll out.

There was also the benefit of bypassing NAT boxes and firewalls, as all packets after the handshake are encrypted. This prevents the firewall from dropping the packet randomly.

Setting up a low latency secure connection #

QUIC removes the need for a TCP handshake to be performed before the connection. As a result, it reduces the round trip time required for the handshake.

There is also a 0-RTT mode where there is no handshake required if the client has sent a request beforehand. This will allow for 0 round trip time required before the data is sent.

It will just use the keys exchanged in the previous connection to encrypt the data instead.

Streams and multiplexing #

This is the same as TCP, where multiple streams of data can be sent over a single connection. This allows for the client to send multiple requests over a single connection.

Better loss recovery and flexible congestion control #

TCP has 1 sequence number for all packets which are sending the same data (Whether it is transmission of retransmission). This makes it harder for the client / server to know the exact reason that a packet was delayed or even the reason that it was delayed (IE: Slow network, Stretch Acknowledgement, etc).

QUIC has a different packet number separate from the sequence number for each packet. The packet number will always be incremented regardless of whether the packet was transmitted / retransmitted. This allows for the receiver to know if a packet received is sent on the first transmit of subsequent retransmit. It also carries timing information between ACKs and packet transmissions.

This allows for the client / server to have more information to work with for the loss recovery and congestion control.

Connection Migration #

In TCP, when the client’s IP’s changes, the connection will be dropped and the TCP handshake will have to happen again. This is because TCP identifies devices based on the client’s IP address and port.

However, in QUIC, every packet carries a connection identifier, which allows the server to identify the client even if the IP address changes. This allows for the connection to be migrated to a new IP address seamlessly without having to drop the connection (IE: Changing from WIFI to 4G or vice versa, NAT Port mapping refreshes).

QUIC packets #

QUIC Packet
QUIC Packet

The QUIC packet is made up of 4 parts:

  1. QUIC Header
  2. QUIC Frame
  3. HTTP/3 Frame header
  4. Payload

QUIC Header #

QUIC Header

The connection ID is the connection identifier to identify each connection. The client chooses the id for the server and the server chooses the id for the client.

Interesting points #

There are tradeoffs when transitioning to QUIC #

  1. Old TCP tools which are used to detect traffic congestions will not be available.

GREASEing #

GREASEing is something that QUIC does as part of the protocol where they send a random value for an extension that does nothing to the server.

The server is expected to ignore the packet successfully without crashing.

This is to make sure that all servers which are shipped ignore extensions which are not supported instead of crashing them and that Future extension implementations will not cause servers which do not support them to crash.

New tools for QUIC #

  1. Quic-trace: A Library and tool for transcribing QUIC connections.
  2. Qvis: A QUIC and HTTP/3 Visualization tool suite.
  3. QUIC Interop Runner: See how different QUIC implementations perform against each other.

HTTP/3 on Nginx #

Some requirements #

  1. As HTTP/3 requires a certificate, a certificate is required (Can be self signed or a CA signed certificate)
    • Note: Self Signed certificates will result in a browser error when visiting the site but it can be bypassed (Depending on browser / other configurations)
  2. A website that you want to deploy behind Nginx

Nginx With QUIC #

According to NGINX, its QUIC support is currently still in beta, although there are some who deployed it for production.

You can download it here by clicking the zip button at the side.

The zip contains the source code for nginx-quic. Compile it and install it and you can make nginx support QUIC too.

An example configuration for QUIC on NGINX #

Below is an example of a server configuration that can be used to run QUIC on NGINX.

server {
    listen 443 ssl;              # TCP listener for HTTP/1.1
    listen 443 http3 reuseport;  # UDP listener for QUIC+HTTP/3

    ssl_protocols       TLSv1.3; # QUIC requires TLS 1.3
    ssl_certificate     ssl/www.example.com.crt;
    ssl_certificate_key ssl/www.example.com.key;

    add_header Alt-Svc 'h3=":443"';   # Advertise that HTTP/3 is available
    add_header QUIC-Status $quic;     # Sent when QUIC was used
}

References #