HTTP 3 — Shiny, New, Transfer Protocol on Steroids

HTTP/3 is coming closer to being implemented in all modern browsers and enabled on most of popular hosting platforms.

4 min readNov 9, 2020

But what are the differences between it and the older HTTP/2 (HTTP/1)

Probably the biggest difference is in the transport layer protocol that is being used — in HTTP/1 and HTTP/2 it was TCP protocol but now one called QUIC will replace it.
It was developed originally by Google and published in 2013 and passed over to IETF in 2015.

This directly translates to savings in latency, time to interactivity, quicker buffering of videos etc. Google recently did some testing and they got pretty good results while still using draft version of the implementation:

search latency decreased by over 2%. YouTube rebuffer time decreased by over 9%, while client throughput increased by over 3% on desktop and over 7% on mobile.

Google be leveraging the usage of UDP got rid of some of the overhead TCP brought. One of the biggest problems with HTTP/1 was that it required each asset to be transferred via its own TCP connection and that meant all the overhead that comes with: handshakes, acks, headers. HTTP/2 tried to address this with multiplexing — basically reusing the same single TCP connection to transfer a bunch of requested files at once. This was done to save on the TCP overhead. But this still isn’t creme de la creme of possible solutions, because a simple disruption of the connection resulted in invalidating all of it and the transfer needed to be restarted from the scratch — it’s easy to see that it had big impact on the perceivable performance on mobile connections, especially in regions with slow and bad network coverage.
And here comes HTTP/3 with its UDP based transport layer where loss of connection doesn’t immediately mean loss of the whole streaming bundle it just impacts the data stream with the damaged packet.
Important to note is that TCP is considered more reliable because of it’s three-way handshake.

What does this all mean to Web Developers?

First and foremost it will be much more beneficial now to not bundle all javascript together. Because of how QUIC works it will be very desirable to leverage lazy loading of javascript assets during the usage of website not all upfront. The adoption will not be super fast probably, especially outside of ecosystem of large websites like youtube, facebook etc… Why? You can see for yourself how slow was the adoption (and still is of HTTP/2 — still not 50% websites support it as of Nov. 2020 — W3 Tech Stats)

What does this all mean to DevOps?

More configuration ;) and some problematic integrations to resolve as for example NGINX needs recompilation to turn on new module like HTTP/3, not like an Apache where you would only add some entries in configuration and it can run as a module.

What does this all mean to Startup Owners, CTOs etc.?

Like everything good this one also has two sides — the bad one is that it will ramp up the TCO of webservers — HTTP/3 needs more CPU power, admins will need to enable it, developers will need to rewrite websites to leverage lazy loading and chunking/code splitting. On the other side it will drive your clients/user experience to new level — faster loading times, in certain types of businesses less loading time can make a lot of difference.