Skip to content



TCP is the main protocol that provides crucial services such as reliability and in-order delivery to other protocols higher up on the OSI model such as HTTP.

A HTTP Request uses a stack of protocols: HTTP on TLS on TCP on IP.

  • HTTP deals with URLs and data interpretation
  • TLS secures the connection with encryption
  • TCP enables reliable in order delivery
  • IP routes packets between machines

A new protocol was introduced called QUIC. HTTP/2 requires changes to work on QUIC.

TCP (Transmission Control Protocol) focuses on reliability over efficiency - requiring a full handshake and a round trip for requests. TCP is large and complex and has many implementations and extensions.

HTTP/3 is essential HTTP/2 over QUIC

Main features coming from QUIC:

  • Faster connection set-up
  • Less HoL blocking
  • Connection migration

Importantly - many other protocols can run over QUIC: DNS, SSH, SMB, RTP etc.

The reason QUIC runs on UDP (User Datagram Protocol) - is due to the difficulty in updating all the hardware and software of the internet. A full independent transport layer - would require all devices on the internet to be upgraded.

UDP is bare bones. ONly supports port numbers. Good for live traffic, low-up front delay requirements (like DNS) and for single round trip requirements.

So reasons UDP is used is for easy deployment.

QUIC implements most TCP features:

  • reliable (with acknowledgements and retransmissions)
  • connection setup with a handshake
  • flow-control and congestion-control

Re-implemented in a more performant way

Newer versions of TLS (1.3 and up) only require a single round trip.

There is no clear text version of QUIC. Encryption is ingrained into QUIC. Most packet headers are also encrypted.

Cons of QUIC:

  • Network providers hesitate to allow QUIC: as the headers encrypt metrics they use to block
  • QUIC encrypts each individual packet - TLS-over-TCP can encrypt several at a time
  • Centralisation - Originally introduced by Google - the IETF QUIC proposal was created by many big companies: facebook, cloudflare, google and big CDNs - most likely leading to more centralisation.

For HTTP/1.1, the resource-loading process is quite simple, because each file is given its own TCP connection and downloaded in full.

TCP was never designed to transport multiple, independent files over a single connection. Because that is exactly what web browsing requires, this has led to many inefficiencies over the years. QUIC solves this by making multiple byte streams a core concept at the transport layer and handling packet loss on a per-stream basis.

Connection Migrations#

For TCP, In practice every network change means that existing TCP connections can no longer be used.

Quick introduces the connection identifier (CID) - a common list of (randomly generated) CIDs mapping to a single connection.

It does not change when chainging networks - unlike TCP that uses the 4 tuple (client IP address + client port + server IP address + server port)

QUIC changes the CID every time a new network is used - to prevent privacy issues? But its encrypted right?

QUIC Implementations are currently done in user-space not kernel-space yet.

QUIC can evolve: QUIC uses individual frames to send meta data, instead of a large fixed packet header.

Performance Improvements#

HTTP/3: Performance Improvements