We have come a long way in many areas of technology. However, when it comes to the web. We still haven’t fixed the problems with the protocols we use, and when we do, we are slow at utilizing them. For example, although HTTP/2 was officially introduced in 2015 and was based on the SPDY experimental protocol available from 2012, only 33.8% (at time of writing) of all Internet traffic is served over HTTP/2.
There’s a lot of reasons why traffic isn’t running on HTTP/2. One of the main contributing factors I assume is for HTTP/2 to be supported by any browser it needs to be served over HTTPS. Without encryption, it will be served over HTTP/1.1 even if the server and the client can use HTTP/2. The other reasons would be:
- Out of date browser – does not support HTTP/2
- Server not updated or does not support HTTP/2
- CDN provider does not support HTTP/2
HTTP/2 – Brief
What problems did HTTP/2 solve?
HTTP1.x had a problem referred to as “Head of line blocking” basically only one request could be outstanding a connection at a time. The later revised HTTP/1.1 solved this by introducing pipelining. The problems caused by pipelining meant that as the web grew bigger and pages needed to load more assets, these pipelines got blocked. The protocol remained untouched for 15 years. It was clearly time for a change.
HTTP/2 introduced multiplexing which resolved this issue, which means you could use one connection to load a page. It was a significant advancement to HTTP/1.1. The introduction of header compression, server push and other features were also more to keeping with modern usage.
I will write another article on the advantages of HTTP/2 but for now I’ll keep it brief.
Performance difference between HTTP/1.1 and HTTP/2
HTTP/2 with all its features is significantly faster than HTTP/1.1 and encourages best practice. Most browsers do not support HTTP/2 unless it’s encrypted. Due to fewer TCP requests, it could improve a webpages load time by 15%.
Congestion Controls
TCP was a protocol invented in the 1970s, and the likelihood is you have probably visited this page using that protocol. And we use this protocol every day. However, when TCP occurs packet-loss being a reliable protocol, it will affect performance to recover data loss. It’s very reliable, but its reliability is also its biggest downside.
Every time packet loss occurs performance is affected, so this can become problematic on large networks, but finally, after many years, we can start to see real improvement in TCP thanks to BBR Congestion Control by Google.
BBR is often used in large networks where congestion control is needed. Other congestion controls perform better than BBR on less busy networks. I have added a short 2-minute video from Google below showing it in action.
BBR can be used for any transport protocol that supports packet-delivery acknowledgement. Two open-source versions are currently available TCP BBR and BBR for Quic.
Where we are now
Once HTTP/2 shipped, everyone noticed that now that HTTP/2 has fixed the line blocking problem in HTTP, there is also a line blocking problem in the TCP protocol. This is why congestion controls aimed at fixing bottlenecks in TCP are important. But better yet we can eliminate the need for TCP.
Google developed its own experimental protocol called gQuic in 2012 that used UDP instead of TCP for transferring HTTP.
UDP would be classified as an unreliable protocol; it doesn’t check for packet loss like TCP.
When you make a TCP request, you initiate a 3-way handshake if you can imagine how much longer this takes than with UDP you can throw everything at it, and it doesn’t have this back and forth.
This is how UDP treats packet loss
The Future: Quic – HTTP/3
gQuick the experimental protocol that started at Google with hope to build a faster web. My next article will discuss how Quic will make the internet a lot faster than what we are using today.
Thanks for reading the first part in my series of posts about “A faster more secure web”.
I will be writing tutorials on how to utilize the quic protocol. If you are using Google Chrome, you may have served this website in Quic.
Pingback: Hello HTTP/3 ,The QUIC protocol explained - Marc Hughes