The interviewer asked: How many HTTP requests can a TCP connection send?

There used to be such a classic interview question: What happens in the process from the URL being entered in the browser to the page being displayed?

I believe that most students who have prepared can answer it, but if you continue to ask: If the received HTML contains dozens of image tags, in what way, in what order, are these images created? How many connections were downloaded and what protocols were used?

To understand this problem, we need to solve the following five problems first:

1. After a modern browser establishes a TCP connection with the server Will it disconnect after an HTTP request is completed? Under what circumstances will it be disconnected?

2. How many HTTP requests can one TCP connection correspond to?

3. Can HTTP requests be sent together in a TCP connection (for example, three requests are sent together and three responses are received together)?

4. Why sometimes refreshing the page does not require re-establishing the SSL connection?

5. Does the browser have any limit on the number of TCP connections that can be established to the same Host?

First question

Will modern browsers disconnect after an HTTP request is completed after establishing a TCP connection with the server? ? Under what circumstances will it be disconnected?

In HTTP/1.0, a server will disconnect the TCP connection after sending an HTTP response. However, each request will re-establish and disconnect the TCP connection, which is too costly. So although it is not set in the standard, some servers support the Connection: keep-alive header. This means that after completing this HTTP request, do not disconnect the TCP connection used by the HTTP request. The advantage of this is that the connection can be reused, and there is no need to re-establish the TCP connection when sending HTTP requests later. If the connection is maintained, the overhead of SSL can also be avoided. The two pictures are from my two visits to www.github in a short period of time. Time statistics of .com:

The first visit has initial connection and SSL overhead

Initialization connection and SSL The overhead disappears, indicating that the same TCP connection is used.

Persistent connection: Since there are so many benefits of maintaining a TCP connection, HTTP/1.1 writes the Connection header into the standard and enables persistent connections by default unless written in the request. If Connection: close is specified, the TCP connection between the browser and the server will be maintained for a period of time and will not be disconnected after a request is completed.

So the answer to the first question is: By default, establishing a TCP connection will not be disconnected. Only declaring Connection: close in the request header will close the connection after the request is completed.

Second question

How many HTTP requests can a TCP connection correspond to?

After understanding the first question, there is actually an answer to this question. If the connection is maintained, a TCP connection can send multiple HTTP requests.

The third question

Can HTTP requests be sent together in a TCP connection (for example, three requests are sent together and three responses are received together)?

HTTP/1.1 There is a problem. A single TCP connection can only process one request at the same time. This means: the life cycle of two requests cannot overlap. The time from the beginning to the end of any two HTTP requests is There cannot be overlap in the same TCP connection.

Although the HTTP/1.1 specification specifies Pipelining to try to solve this problem, this feature is turned off by default in browsers.

Let’s first take a look at what Pipelining is. RFC 2616 stipulates:

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. 一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。收到请求的服务器必须按照请求收到的顺序发送响应。

As for why the standard is set like this, we can roughly speculate on one reason: because HTTP/1.1 is a text protocol, and at the same time The returned content cannot distinguish which request it corresponds to, so the order must be maintained consistent. For example, if you send two requests to the server, GET/query?q=A and GET/query?q=B, and the server returns two results, the browser has no way to determine which request the response corresponds to based on the response results.

Pipelining This idea looks good, but in practice there are many problems:

• Some proxy servers cannot handle HTTP Pipelining correctly.

• Correct pipeline implementation is complex.

• Head-of-line Blocking Connection header blocking: After establishing a TCP connection, assume that the client sends several requests to the server continuously during this connection. According to the standard, the server should return results in the order in which the requests are received. Assuming that the server spends a lot of time processing the first request, then all subsequent requests will need to wait for the first request to complete before responding.

So modern browsers do not enable HTTP Pipelining by default.

However, HTTP2 provides the Multiplexing feature, which can complete multiple HTTP requests simultaneously in a TCP connection. How exactly multiplexing is implemented is another question. We can take a look at the effect of using HTTP2.

Green is the waiting time from initiating the request to request return, blue is the download time of the response, you can see that they are all completed in parallel in the same Connection

So this question also has an answer: There is Pipelining technology in HTTP/1.1 that can complete the sending of multiple requests at the same time, but since the browser is closed by default, it can be considered not feasible. In HTTP2, due to the multiplexing feature, multiple HTTP requests can be processed in parallel on the same TCP connection.

So in the HTTP/1.1 era, how does the browser improve page loading efficiency? There are two main points:

• Maintain the TCP connection that has been established with the server and process multiple requests sequentially on the same connection.

• Establish multiple TCP connections with the server.

The fourth question

Why sometimes refreshing the page does not require re-establishing the SSL connection?

The answer is already available in the discussion of the first question. TCP connections are sometimes maintained by the browser and server for a period of time. TCP does not need to be re-established, and SSL will naturally use the previous one.

Fifth question

Does the browser have any limit on the number of TCP connections that can be established to the same Host?

Suppose we are still in the HTTP/1.1 era, and there was no multiplexing at that time. What should the browser do when it gets a webpage with dozens of pictures? It is definitely not possible to just open a TCP connection for sequential downloading, otherwise the user will definitely have to wait. However, if a TCP connection is opened for each picture to send HTTP requests, the computer or server may not be able to bear it. If there are 1,000 pictures, it cannot be opened. 1000 TCP connections, even if your computer agrees to NAT, it may not agree.

So the answer is: yes. Chrome allows up to six TCP connections to the same Host. There are some differences between different browsers.

developers.google.com/web/tools/ch...

So back to the original question, if the received HTML contains dozens of images Tags, in what way, in what order, how many connections were established, and what protocol were used to download these pictures?

If the images are all HTTPS connections and under the same domain name, the browser will discuss with the server after the SSL handshake whether HTTP2 can be used. If so, use the Multiplexing function to perform multiplexing on this connection. . However, not all resources linked to this domain name may be obtained using a TCP connection, but it is certain that Multiplexing is likely to be used.

What if you find that HTTP2 cannot be used? Or HTTPS cannot be used (in reality, HTTP2 is implemented on HTTPS, so only HTTP/1.1 can be used). The browser will establish multiple TCP connections on a HOST. The maximum limit on the number of connections depends on the browser settings. These connections will be used by the browser to send new requests when idle. If all connections are sending requests Woolen cloth? Then other requests will have to wait.                                                           ## Recommended study: "

"                                              

The above is the detailed content of The interviewer asked: How many HTTP requests can a TCP connection send?. For more information, please follow other related articles on the PHP Chinese website!