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.
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?
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.
How to check what versions and if any the server you are connecting supports?
There are at least 3 ways…
- Use some site that will check it for you ie: https://gf.dev/http3-test
2. Open Chrome DevTools and take a look at the headers sent from server — look for alt-svc header:
3. Turn on Protocol column in Chrome DevTools Network Tab — right click at the column list:
And then the used protocol version will be displayed as follows:
You can connect with me on linkedin https://www.linkedin.com/in/damian-pieszczynski/
or drop some love or hate down in the comments ;)