William Gibson, the man who coined the term cyberspace, once said.
The future is already here. It’s just not very evenly distributed.
Almost 4 years ago, I wrote on this blog about upgrading to SPDY. Back then, I claimed it was only 30-35% slower than https. This week, we walk the same path with the next protocol upgrade, aka http/2. It is as fast as http, and in specially crafted tests, faster. That’s quite an improvement on https 1.1 .
So here’s the thing. While text based protocols are great for a variety of reasons, binary is in vouge again. Maybe because as mobile eats web, latencies over 3g networks are important as ever before. After all, people have been writing their own wire protcols, or running protocol buffers/ thrift on top of http. Thanks to http/2, we don’t need to take that dreaded route, and we could still be kids who didn’t write their own.
All right, so what sort of magic bullet is http/2, you may ask. Well, so far, our rollout has only been partial, which means typically about 5-10% of requests have been moved to http/2. The CDNs we use are still slow to rise to http/2, which is either indicative of an inefficient market (switching costs), or uninformed decision makers. Overall , we aren’t seeing a very significant impact on our page load times, since bulk of our content is images served off cdn. What we do see however, is a very significant impact on certain metrics such as server connection time, and on certain workloads.
Technically, we would also be seeing an impact on bandwidth usage. Thats because http/2 comes with header compression, and our microservices APIs have a significant header overhead. Unfortunately, our ELB didn’t record the network usage, so I don’t have numbers to share with you on how much of a bandwidth drop we did see. Yet, we could do some calculations.
A typical API could have as much as 30% of the total response in HTTP headers. In a quick test I ran, it wasn’t atypical to find API calls were header size exceeded that of data. Some tests with nghttp -s revealed savings of around 30% on those requests. Even assuming as low as 80% compression ratio, we still save a significant amount. Heck, we have some servers that return 302 responses 99% of the time, and you can only imagine how great http/2 is for those servers. In other words, saving a paltry 100 bytes per request translates to 100 GB for every billion requests we serve. This bandwidth may not mean so much for us as we buy by the terrabytes, but it does mean a lot for our users who pay through their nose for the data packs.
Besides the saving in bandwidth, we do see a clear improvement in Server Connection time as recorded by Google Analytics, and this consistent across a set of properties. The Server Connection Time fell to 50% of its previous value.
We use nginx, running on ubuntu 16.04 (for ALPN, as previous ubuntu versions have older openssl) for http2 termination. We use a wildcard cert, and when possible, make multiple hosts share the same server IP, something that http/2 can detect and use, while still not impacting domain sharding benefits in http/1.1 . On AWS, in short, this means we have ditched some ELBs, and use consul for managing/health-checking our upstreams. Luameter works great for upstream stats. This is an interesting setup, worthy of its own blog post someday.
Today, 9% of websites use http/2. Almost 70% of browsers support it. Our tests show that 45% of traffic on our mobile site are from browsers that support http2, Android Browser and UCWEB being the major exceptions. This is quite close to the 39% reported for Indonesia, and much lower than the globally reported figure of 80%. When we roll this out on desktop, this percentage is expected to be higher, and on Android, where we already use the okhttp library, we can expect even better. And then, there is server push to experiment with. The future is surely here, and we are living it. If you want to experience it too, well, we are hiring devops and engineeers @ Tokopedia, get in touch with us.
Update: I talked about ditching the ELB, and seems it couldn’t have been more timely. Well, AWS listened, and they just launched (on 11th August) an update to LB (called ALB), which does support http/2. Makes it even easier.