HTTP/3 is an IETF standard (Internet Engineering Task Force) that was formally adopted in June 2022 as the new version of HTTP. Over the next few years, more and more companies will use the new standard. With this change, doing things online will become faster and more efficient. HTTP/3 is the third major version of the Hypertext Transfer Protocol. Notably, HTTP/2 was only adopted in 2015 - so why did we need HTTP/3? What problems does HTTP/3 solve?
HTTP/3 solves a few issues with the implementation of HTTP/2. HTTP/3 was previously known as HTTP-over-QUIC. Google developed the QUIC transport protocol to replace the HTTP/2 internet protocol. Companies like Google and Facebook already use QUIC. Companies like these support HTTP improvements to speed up their user experience. Now that HTTP/3 is formally adopted as the new HTTP protocol specification, more web services can take advantage. All major browsers, including Google Chrome, Safari, and Firefox, support HTTP/3.
Web developers in the early days of the internet could use two standards: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).
UDP was preferred for scenarios where packets of data can be sent without regard to if there were adequately received or not. This fire-and-forget method is excellent for rapid updates like in online games. In these quick UDP internet connections, lost packets are just ‘lost,’ and neither end may be aware. This is not ideal when data delivery needs to be guaranteed.
TCP was preferred for scenarios where there needs to be a more formal connection. TCP guarantees data delivery and the correct order of data packets. This effectively eliminates data loss from packet loss and internet connection interference. This method is preferred for web pages, and that’s why a TCP connection was adopted for HTTP/2 and how all modern web browsers connect you to web pages.
HTTP/2 combines TCP protocol with TLS (Transport Layer Security) to provide the encryption needed for a more modern web.
Today people have better internet, and you’d think that HTTP/2 would have solved the issues of HTTP/1.1, and there would be no need for another new protocol. However, a new problem has come into play because how we access the internet has changed. Mobile devices, mobile data networks, and WiFi have changed how we access the web. With wireless connectivity, the odds of lost packets of data are much more significant. The signals reflect off objects, get lost in walls, and don’t always make it to the edge of a signal range.
TCP does not like this type of connection. TCP requires ridged steps for establishing and maintaining a connection. When the connection is broken, the connection needs to be reestablished before data can be transmitted again. When TCP packets are received out of order, it causes head-of-line blocking. Head-of-line blocking means data packets will be held up while waiting for previous data. This creates a performance bottleneck.
This means when using HTTP/2 on a wireless connection, the latency will increase, the round trip time for data will increase, and the load time for web pages will increase. A slow connection and poor user experience will result. This is the reason for developing the QUIC connection protocol and HTTP/3.
QUIC is built on UDP. The QUIC protocol provides native multiplexing so that lost packets only impact the streams where data has been dropped. This means that the benefits of UDP can be realized while allowing for guaranteed data delivery. QUIC and HTTP/3 are fast - look at this HTTP/3 speed test to learn more.
QUIC is always designed to be encrypted, and QUIC uses TLS 1.3 as the main component for its cryptographic handshake. There’s no option not to encrypt data. This means there are also some security improvements in this version of HTTP.
QUIC combines cryptographic and transport handshakes so a single round-trip can connect to web servers or APIs. This means that an interrupted connection can quickly be resumed, and the browser or client sends encrypted data on its first trip.
Check out the HTTP/3 RFC for more information on this history of implementing HTTP/3.
The best way to use HTTP/3 with an existing web application is to use a CDN (Content Delivery Network) provider like Cloudflare or Fastly. CDNs are optimized for improving web response speed (such as using congestion control and load balancers), and they’ve already taken steps to implement HTTP/3.
Some servers are built with QUIC (see Litespeed). However, many servers, such as Node.js, NGINX, and Apache, require a third-party library to enable QUIC. Adoption has been limited because when web servers are changed, it can impact how dependable that web server or endpoint is. This is why using a CDN may be the correct route for existing web servers. The risk to the user experience will be mitigated as HTTP/3 continues to be adopted.
