HTTP 1,2,3 — Let’s go
For quite some time GCLB has added QUIC support. HTTP/3 uses QUIC as underlying protocol. This means, many of our customers are using QUIC and HTTP/3 without evening knowing about it, since it’s the new default.
But what is QUIC all about?
What are the differences between HTTP 1,2,3
TCP is not optimal for multiplexing many resources over single connection due to it’s behavior with bad networks. Most TCP implementation interpret package loss or corrupted packages as a blocking problem. Stopping further transfers and re-requesting the corrupted or missing packages. In HTTP/2 a single connection is used to multiplex all resources. This means, that if a packet got missing, all other data transfers over this multiplexed connections are stopped as well.
QUIC solves this by not using TCP but UDP, and handling corrupted or missing packages in a higher OSI layer. This is of course simplified and there are many more things that should be mentioned around QUIC.
The test setup
I build a small test setup of GCP with a static Angular boilerplate application. That resided in a GCS bucket, and was served with CDN and GCLB.
The network setup for testing
I used the Network link conditioner application from Apple to simulate a 3G Network and to simulate package loss for the bad connection option. I also disabled HTTP/2 and HTTP/3 via chrome flags, to enforce HTTP/1. I tested HTTP/2 by disabling HTTP/3 on the load balancer. I collected the results below using Chrome Dev Tools.
The results were quite interesting. Clearly showing how HTTP 1 and 2 had problems handling the faulty 3G network, while HTTP3 was barely slowed down.
The cool thing for me, is that you basically get HTTP/3 for free using GCLB. No change needed on your application, but you can benefit from the improved fault handling right away.
