The introduction

This article is divided into three parts to step by step into HTTP/1.x keep-alive and HTTP/2 multiplexing:

  • What is HTTP/1.x keep-alive
  • HTTP/2 multiplexing
  • X keep-alive differs from HTTP/2 multiplexing

Let’s get started

HTTP/1.x keep-alive

In the article into TCP and HTTP, we have introduced that HTTP protocol is an application layer protocol based on TCP. HTTP protocol is a very simple protocol at first, and the communication mode is also a simple request-reply mode, that is: A TCP connection needs to be created for each request between the client and the server. The server disconnects the TCP connection after the response, and then requests and disconnects again.

This was the default in HTTP/0.9 and earlier HTTP/1.0, but this constant creation and disconnection was a significant performance drain

The cost of establishing a TCP connection is high because the client and the server need to “three handshakes” to establish a connection, sending three packets, requiring one RTT; Closing connections is “four waves”, 4 packets require 2 RTTS and slow start, which becomes more and more of a problem as web pages load more and more external resources

HTTP/1.0 introduced keep-alive long connections, which were disabled by default in HTTP/1.0. HTTP/1.1 is enabled by default, whether Connection: keep-alive is added or not.

The so-called long connection refers to the process of establishing a TCP connection through AN HTTP request. The request ends and the TCP connection continues for a period of time (timeout). During this period, the same client sends requests to the server to reuse the TCP connection and reset the timeout time counter. TCP can be reused for the rest of the timeout period. This eliminates the cost of repeatedly creating and destroying TCP connections.

Does TCP disconnect immediately after the timeout?

If no data is received from the client within two hours, the server sends a probe segment, then every 75 seconds. If there is no response from the client after 10 probe segments are sent, the server assumes that the client is faulty and closes the connection.

— From Xie Xiren, Computer Networks

HTTP/2 multiplexing

Why does HTTP/2 introduce multiplexing?

This is because:

  • HTTP/1.x introduces keep-alive long connections, but each request must wait for the last response before it can be initiated.
  • Therefore, in HTTP/1.1, the pipeline mechanism (not enabled by default) is proposed. The next request does not need to wait for the previous response to be sent, but this requires that the server must return the response in the order in which the request was sent. When multiple files are requested sequentially and one of the requests is blocked for some reason, All requests queued at the back Of the queue are blocked as well. This is a Head Of Line Blocking.
  • People have taken many measures to solve the problem, such as using multiple domain names, introducing Sprite maps, inlining small maps, etc., but they have not fundamentally solved the problem

What does HTTP/2 do?

  • First of all, it introduces frames and streams, because HTTP/1.x is based on text, and because it is text, it must be a whole, which cannot be cut in transmission, but can only be transmitted as a whole
  • Since HTTP/2 is based on binary streams, it can break HTTP messages into separate frames, send them interleaved, and then reassemble them at the other end with identifiers in the frames, which is multiplexing
  • In this way, multiple requests and responses can be sent at the same time on the same TCP connection without corresponding to each other in sequence. Even if a request task takes a long time, the normal execution of other connections is not affected

X keep-alive differs from HTTP/2 multiplexing

To summarize, HTTP/1.x keep-alive differs from HTTP/2 multiplexing:

  • HTTP/1.x is text-based and can only be passed as a whole; HTTP/2 is binary stream-based and can be broken down into separate frames that are sent interleaved

  • HTTP/1.x keep-alive must return the response in the order in which the request was sent; HTTP/2 multiplexing does not respond sequentially

  • HTTP/1.x keep-alive To solve queue header blocking, resources on the same page are distributed to different domain names and multiple TCP connections are enabled. All communication between HTTP/2 and the domain name is done on a single connection

  • HTTP/1.x keep-alive a single TCP connection can process only one request at a time (the life cycles of two requests cannot overlap); HTTP/2 A single TCP can send multiple requests and responses at the same time

Three minutes a day