Why transitioning from HTTP/1 to HTTP/2 could put your backend under stress for the same traffic

The Spikier Request Flow due to the Multiplexing Effect

Imagine you’re a server at a busy restaurant, and customers come in to place their orders. In the old system (HTTP/1), each customer would come in one by one, giving you enough time to take their order, process it, and move on to the next customer. It was like a well-organized queue, and you could handle each customer efficiently.

Now, with the introduction of HTTP/2, things have changed. Customers no longer come in one at a time. Instead, a group of customers rushes in all at once. Suddenly, you have multiple customers talking to you simultaneously, trying to place their orders together. It’s like a chaotic situation where everyone wants your attention at the same time.

This sudden influx of requests without any staggered intervals puts a lot of stress on you as the server. You find it harder to process all the orders quickly because you’re constantly juggling between different customers. Some orders may take longer to process, causing delays for others. In the end, it becomes more likely that some orders will time out and not be fulfilled in a timely manner.

The introduction of multiplexing in HTTP/2 enables browsers to send multiple requests concurrently over a single TCP connection, eliminating the need to wait for responses before making additional requests. Although this benefits the web client, it substantially increases the strain on servers. First, the servers receive requests in larger batches rather than smaller, spread-out batches. Secondly, the requests are sent together without any staggered intervals, leading to closer start times and a higher likelihood of timeouts.

Another CPU-intensive aspect of HTTP/2 is the requirement for packet reordering. In HTTP/1, requests were processed in a strict sequential order on a single TCP connection. However, in HTTP/2, packets can arrive out of order due to multiplexing and stream parallelism. The server must reassemble and reorder these packets to ensure correct processing and maintain the integrity of the data.

Please note that the CPU needs to handle the reordering of the TCP segments in both cases. However, reordering packets of the same stream by the OS’ Kernel is the extra taxing thing in HTTP/2.