Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "how many HTTP requests can be sent by a TCP connection". In the actual operation process of the case, many people will encounter such a dilemma. Next, let Xiaobian lead you to learn how to handle these situations! I hope you can read carefully and learn something!

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

Can HTTP requests be sent together in a TCP connection (e.g. three requests sent together and three responses received together)?

How many HTTP requests can a TCP connection correspond to?

Why do I sometimes refresh pages without re-establishing SSL connections?

Is there a browser limit on the number of TCP connections made to the same Host?

Do modern browsers, after establishing a TCP connection with a server, disconnect after an HTTP request completes? Under what circumstances will it disconnect?

the first question

Do modern browsers, after establishing a TCP connection with a server, disconnect after an HTTP request completes? Under what circumstances will it disconnect?

In HTTP/1.0, after a server sends an HTTP response, it disconnects the TCP link. However, this reestablishes and disconnects TCP connections with each request, which is too costly. So although not specified in the standard, some servers support Connection: keep-alive headers. This means that after completing the HTTP request, do not disconnect the TCP connection used by the HTTP request. The benefits of this are that the connection can be reused and no TCP connection needs to be re-established when sending HTTP requests, and if the connection is maintained, the SSL overhead can also be avoided. The two pictures are my statistics for visiting https://www.github.com twice in a short period of time:

First access, with initialization connection and SSL overhead

The initialization connection and SSL overhead disappear, indicating that the same TCP connection is used

Persistent connections: Since there are so many benefits to maintaining TCP connections, HTTP/1.1 writes the Connection header into the standard and opens persistent connections by default, unless the request states Connection: close, then the TCP connection between the browser and the server will be maintained for a period of time and will not be broken at the end of a request.

So the answer to the first question is: By default, TCP connections are established without breaking, and only by declaring Connection: close in the request header will the connection be closed after the request is complete.

the second question

How many HTTP requests can a TCP connection correspond to?

After understanding the first question, this question has already been answered. 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 (e.g. three requests sent together and three responses received together)?

HTTP/1.1 has a problem that a single TCP connection can only handle one request at a time, which means that the lifetimes of two requests cannot overlap, and the time from start to end of any two HTTP requests cannot 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 look at what Pipelining is, as defined in RFC 2616:

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. A client that supports persistent connections can send multiple requests in a single connection (without waiting for a response to any request). The server receiving the request must send the response in the order in which the request was received.

As for why the standard is set this way, we can probably guess one reason: since HTTP/1.1 is a text protocol, and the returned content does not distinguish which request corresponds to which one was sent, the order must be consistent. For example, you sent two GET/query requests to the server. Q=A and GET/query? q=B, the server returned two results, the browser is no way to determine which response corresponds to which request based on the response results.

Pipelining looks like a nice idea, but in practice there are many problems:

Some proxy servers do not handle HTTP Pipelining correctly.

The correct pipeline implementation is complex.

Head-of-line Blocking: After establishing a TCP connection, assume that the client sends several requests to the server in succession over this connection. By standard, the server should return results in the order in which the requests were received. Assuming the server takes a lot of time to process the first request, all subsequent requests will have to wait until the end of the first request.

Modern browsers do not enable HTTP Pipelining by default.

However, HTTP2 provides multiplexing, which allows multiple HTTP requests to be completed simultaneously over a TCP connection. How Multiplexing works is another question. We can see the effect of using HTTP2.

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

So there is an answer to this question: Pipelining technology exists in HTTP/1.1 to complete this multiple requests simultaneously, but since browsers are turned off by default, it can be considered impossible. In HTTP2, due to Multiplexing, multiple HTTP requests can be made in parallel on the same TCP connection.

So how do browsers improve page load efficiency in the HTTP/1.1 era? There are two main points:

Maintain TCP connections established with the server, processing multiple requests sequentially on the same connection.

Establish multiple TCP connections with the server.

the fourth question

Why do I sometimes refresh pages without re-establishing SSL connections?

The answer to the first question is already in the discussion. TCP connections are sometimes maintained by browsers and servers for a while. TCP does not need to be re-established, SSL will naturally use the previous.

the fifth question

Is there a browser limit on the number of TCP connections made to the same Host?

Suppose we were still in HTTP/1.1, when there was no multiplexing, what would a browser do when it got a page with dozens of images? You can't just open a TCP connection to download sequentially, so the user must wait very hard, but if every picture opens a TCP connection to send HTTP requests, then the computer or server may not be able to stand it, if there are 1000 pictures, then you can't open 1000 TCP connections. Your computer may not agree with NAT.

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

https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requestsdevelopers.google.com

So back to the initial question, if the HTML received contained dozens of image tags, in what way, in what order, how many connections were made, and using what protocol were these images downloaded?

If the images are all HTTPS connections and under the same domain name, then the browser will negotiate with the server after the SSL handshake whether it can use HTTP2, and if it can use Multiplexing to multiplex over this connection. However, it is unlikely that all resources attached to this domain will be obtained using a TCP connection, but it is certain that Multiplexing is likely to be used.

What if you don't use HTTP2? Or you can't use HTTPS (HTTP2 in reality is implemented over HTTPS, so you can only use HTTP/1.1). The browser will establish multiple TCP connections on a HOST, the maximum number of connections depends on the browser settings, these connections will be used by the browser to send new requests when idle, what if all the connections are sending requests? The rest of the requests will have to wait.

"How many HTTP requests can a TCP connection send" is introduced here. Thank you for reading it. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.