HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, complementing the widely-deployed HTTP/1.1 and HTTP/2. Unlike previous versions which relied on the well-established TCP (published in 1974), HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP. On 6 June 2022, IETF published HTTP/3 as a Proposed Standard in RFC 9114.




HTTP/2 vs HTTP/3

One of the main touted advantages of HTTP/3 is increased performance, specifically around fetching multiple objects simultaneously. With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). Because HTTP/3 is UDP-based, if a packet gets dropped that only interrupts that one stream, not all of them.

In addition, HTTP/3 offers 0-RTT support, which means that subsequent connections can start up much faster by eliminating the TLS acknowledgement from the server when setting up the connection. This means the client can start requesting data much faster than with a full TLS negotiation, meaning the website starts loading earlier.[3]





cURL with HTTP3

Install build tools


cd m4-*
make && sudo make install

./configure --with-internal-glib

Build curl


Build nghttp3:

git clone -b v1.1.0
cd nghttp3
autoreconf -fi
./configure --enable-lib-only
make && sudo make install

Build OpenSSL:

cd openssl
./config enable-tls1_3 
make && sudo make install

Build libpsl:

make && sudo make install

Build curl:

git clone
cd curl
autoreconf -fi
./configure --with-openssl=/usr/local --with-openssl-quic --with-nghttp3=/usr/local
make && sudo make install

Test HTTP3 pages

/usr/local/bin/curl --version
curl 8.6.0-DEV (aarch64-apple-darwin22.6.0) libcurl/8.6.0-DEV OpenSSL/3.2.0 zlib/1.2.11 libpsl/0.21.5 OpenSSL/3.2.0 nghttp3/1.1.0
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP3 HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

/usr/local/bin/curl --http3 -I
HTTP/3 200
date: Tue, 23 Jan 2024 07:55:42 GMT
content-type: text/html
content-length: 125959
server: cloudflare
cf-ray: 849e79d4bacf0468-HKG
alt-svc: h3=":443"; ma=86400

HTTP3 test sites

It's also possile to start a local server:


cd quiche
RUST_LOG=trace cargo run --bin quiche-server -- --cert apps/src/bin/cert.crt --key apps/src/bin/cert.key

/usr/local/bin/curl --http3  -I --insecure
HTTP/3 405
server: quiche
content-length: 0

Note: this could not be requested by browser.


Download caddy via

chmod +x caddy_darwin_arm64
sudo mv caddy_darwin_arm64 /usr/local/bin/caddy


	servers {
        protocols h1 h2 h3

localhost:8080 {
    file_server {
        root /Users/riguz/Downloads


caddy run
# if http3 somehow not working, try restart it
# see:

Browser support

Chrome/Firefox need to be configured.[6]

Firefox: set network.http.http3.enabled=true in about:config

Chrome(also need to disable cache):

/Applications/Google\ Chrome\\ Chrome\ Canary --enable-quic --origin-to-force-quic-on=localhost:443

If the scheme is not h3 for a h3-supported site, check it with curl first, might be a firewall problem.


Is HTTP/3 using UDP more reliable than HTTP/2 (etc.) using TCP?

It isn’t more reliable.

It has quite different performance properties in some ways, mostly lower latency for HTTP requests, and much lower latency for HTTPS session setup.

But the reliability is the same or lower. That’s not the point.[7]

Why is encryption significant in HTTP/3?

HTTP/3 encrypts connections by default at the transport layer, offering improved security. This differs from previous versions, where encryption occurred separately at the application layer. Encrypting by default helps protect user data, reduces latency, and ensures a safer browsing experience.

Is HTTP client side connection pooling still valid when QUIC, HTTP/3 is the major/all traffic expected?

It's still valid, because[8]:

  • a 0-RTT request is more computentionally expensive on both the client as well as the server side than just reusing the connection, since all private key crypto operations and certificate checks still apply
  • 0-RTT requests can introduce security issues due to providing a chance for replay attacks (see Without using the 0-RTT feature a QUIC handshake still requires 1-RTT.

However since QUIC already provides multiplexing multiple requests on a stream the client should not be required to keep a full pool of connections around. A single connection is typically sufficient, as long as the server advertises being able to support a high enough number of streams.