Prior to this release, since all the HTTP/2 requests from the clients to load balancer were converted to HTTP1.1 requests to backend. Though browser can send requests for each tile through HTTP/2 request to the Application Load Balancer, the load balancer still needs to convert the HTTP/2 requests into different HTTP/1.1 requests through different TCP connections. In additional, if the backend application already natively supports HTTP/2, we still have to make changes to the application to make it support HTTP/1.1 to work with the load balancer. With the release, there is no more HTTP/1.1 to HTTP/2 conversion!
In this demo, we are going to take a close look at the end-to-end HTTP/2 setup and the benefit we gain from it.
Let's say that we are hosting a web page that has an image, consisting of multiple different small images(tiles). We created two targets groups that serve the same image. One target group only serve HTTP/2 request on port 80 and the other one only serve HTTP/1.1 request on port 8080.
On the Application Load Balancer, we create two listeners -- the one listen on port 443 only serve HTTP/2 requests and the one listen on port 8443 only serve HTTP/1.1 requests.
The clients send both HTTP/1.1 and HTTP/2 requests to the two listeners of the Application Load Balancer. We are going to take a close look at the packet capture of the request from the load balancer and compare the size of the HTTP/1.1 and HTTP/2 packet. backend application server.
Because of the header compression feature of HTTP/2, as you can see from the packet capture, the packet size of the HTTP/2 request is 33% smaller than the HTTP/1.1 request. Therefore, comparing to HTTP/1.1, you can image how much data transfer cost we can save via end-to-end HTTP/2.