HTTP up to version 2 relies on the Transmission Control Protocol (TCP) as the transport protocol. TCP acknowledges receipt of each data packet. As a result, in the event of a packet loss, all other packets have to wait for the lost one to be retransmitted (head-of-line blocking).
Google has been working on an alternative since 2012 under the name QUIC, which was adopted by the IETF and standardized in 2021. QUIC is a transport protocol that builds on connectionless UDP and provides missing properties such as reliability and connection-oriented communication. Connections are encrypted, for which QUIC uses TLS version 1.3. QUIC supports multiplexing of multiple data streams, bypassing head-of-line blocking. If a packet is lost at QUIC, it only blocks the streams that were included in that packet. The connection negotiation of QUIC is optimized to reduce the latency required to transmit the actual payload. In November 2018, the IETF decided that HTTP over QUIC should be called HTTP/3. In June 2022, HTTP/3 was standardized as RFC 9114.
1 | https://datatracker.ietf.org/doc/html/rfc9114 |
Even with HTTP/3, data streams are processed separately. If a packet is lost along the way, it no longer affects all data streams, as is the case with HTTP/2. With HTTP/3, the affected stream will wait for the missing packet to arrive. HTTP/3 is generally encrypted and promises significant speed advantages over HTTP/2 with TLS. HTTP/3 is supported by 75% of web browsers and 26% of websites. Among the 26% of the websites, 12-13% are probably due to routing through Cloudflare.
---
Present Deployment Options of HTTP/3
At the time of writing, the Apache webserver project has no production line solution. Implementing HTTP/3 would be a lot of work. The troublesome part is that both HTTP/2 and HTTP/3 get ahead by being layer 4 to layer 7 protocols. HTTP/1 is working at layer 7. The Apache server was designed to be an OSI layer 7 component.
The acceptable method is to compile NGINX with quiche, but this is also not very reliable and suitable for testing purposes. We can run NGINX using HTTP/3 only on 443 with only QUIC. It will use UDP. In such case, we can use Apache on 443 which will use TCP. In that case, the NGINX configuration will be like this:
1 2 3 4 | listen 1.2.3.4:443 quic reuseport; location / { proxy_pass https://apache-httpd-server.tld:443; } |
Another option is to switch to LiteSpeed or Caddy:
1 2 | https://www.litespeedtech.com/products/litespeed-web-server https://caddyserver.com/ |
OpenLiteSpeed is the Open Source edition of paid LiteSpeed Web Server. OpenLiteSpeed contains all of the essential features found in paid LiteSpeed. CloudFlare and NGINX have already written their official opinion:
1 2 | https://blog.cloudflare.com/experiment-with-http-3-using-nginx-and-quiche/ https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/ |
H2O supports HTTP/1.x, HTTP/2 and HTTP/3, but usage of H2O for MySQL-PHP stack is less heard. HTTP/3 changes the internals of this prioritization system which was first found in HTTP/2. If we are not using a valid TLS certificate signed by a cert authority then we cannot use QUIC. Another hurdle is that it requires more CPU usage for both the server.
So, the present option is using LiteSpeed server and/or CloudFlare.
