Say cherry wood began to find a job, I heard that programmers pay high wages, as long as the technology is good, and their own level of fairy way has smoothly changed, become a treasure of a programmer, cherry wood as a blood red hair, of course, want to and once the old rival bar wave….
Sakuragi: Aren’t you amazing? Let me ask you a few questions:
- Do modern browsers disconnect after an HTTP request is completed after establishing a TCP connection with the server? When will it be disconnected?
- How many HTTP requests can a TCP connection correspond to?
- Can HTTP requests sent in a TCP connection be sent together (e.g., three requests sent together and three responses received together)?
- Why do you sometimes refresh pages without re-establishing SSL connections?
- Does the browser limit the number of TCP connections to the same Host?
Fairy way: feed, all quick 30 of person, zha return resemble high school same! If it weren’t for your bones, I wouldn’t even bother you! Listen up:
First question
Do modern browsers disconnect after an HTTP request is completed after establishing a TCP connection with the server? When will it be disconnected?
In HTTP/1.0, a server breaks the TCP connection after sending an HTTP response. However, TCP connections are re-established and disconnected each time a request is made. So although it is not specified in the standard, some servers support Connection: keep-alive headers. After completing the HTTP request, do not disconnect the TCP connection used for the HTTP request. The advantage of this is that the connection can be reused, and the TCP connection does not need to be re-established when sending HTTP requests later, and the overhead of SSL can be avoided if the connection is maintained. The two pictures are the statistics of my two visits to www.github.com in a short period of time:
** Persistent connections: ** Since there are so many benefits to maintaining TCP connections, HTTP/1.1 writes the Connection header into the standard and enables persistent connections by default, unless the request says “Connection” : Close, the TCP connection between the browser and the server is maintained for a period of time and does not break at the end of the request.
Sendao: So the answer to the first question is: by default, establishing a TCP Connection does not break, only declaring Connection: close in the request header will close the Connection after the request completes.
Second question
How many HTTP requests can a TCP connection correspond to?
Sendao: With the first question in mind, this question is already answered. a TCP connection can send multiple HTTP requests if the connection is maintained.
Third question
Can HTTP requests sent in a TCP connection be sent together (e.g., three requests sent together and three responses received together)?
A problem with HTTP/1.1 is that a single TCP connection can only handle one request at a time. This means that the life cycles of two requests cannot overlap. Any two HTTP requests cannot overlap from start to end in the same TCP connection.
Pipelining is specified in the HTTP/1.1 specification to address this problem, but it is turned off by default in browsers. Take a look at what Pipelining is, as outlined 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 within a connection (without waiting for a response from any request). The server receiving the request must send the response in the order the request was received.
One possible reason for the standard is that ** HTTP/1.1 is a text protocol **, and the content returned does not distinguish which request to send, so the order must be consistent. What if you send two GET/query requests to the server? Q = A and GET/query? Q =B, the server returns two results, and there is no way for the browser to determine which one the response corresponds to.
Pipelining looks like a good idea, but there are many problems in practice:
- Some proxy servers cannot handle HTTP Pipelining correctly.
- Proper pipelining implementation is complex.
- Head of line Blocking: After establishing a TCP connection, suppose that the client sends several consecutive requests to the server on that connection. By standard, the server should return the results in the order it received the requests, assuming that the server took a lot of time to process the first request, then all subsequent requests would have to wait for the first request to end.
Sendo: So HTTP Pipelining is not enabled in modern browsers by default.
However, HTTP2 provides the Multiplexing feature, which allows multiple HTTP requests to be completed simultaneously over a TCP connection. How exactly the Multiplexing is implemented is another question. We can see the effect of using HTTP2.
The green is the waiting time from the initiation of the request to the return of the request, and the blue is the download time of the response. It can be seen that both are completed in parallel in the same Connection
Pipelining ** exists in **HTTP/1.1 to perform this multiple requests at the same time, but since the browser is turned off by default, it can be considered unfeasible. Multiplexing allows multiple HTTP requests to be processed in parallel in the same TCP connection due to the Multiplexing feature in HTTP2.
So how can browsers improve page loading efficiency in the AGE of HTTP/1.1? There are two main points:
- Maintains an established TCP connection with the server and processes multiple requests sequentially over the same connection.
- Multiple TCP connections are established with the server.
Fourth question
Why do you sometimes refresh pages without re-establishing SSL connections?
Sendao: the answer to the first question was given in the discussion, TCP connections are sometimes maintained by browsers and servers for a period of time. TCP does not need to be re-established, SSL will naturally use the previous.
Fifth question
Does the browser limit the number of TCP connections to the same Host?
Suppose we were in the HTTP/1.1 era, when there was no multiplexing. What would a browser do when it got a web page with dozens of images? You can’t just open a TCP connection for sequential downloading, which will make it very uncomfortable for users to wait. However, if each image has a TCP connection to send HTTP requests, the computer or server may not be able to bear it. If there are 1000 images, you can’t open 1000 TCP connections. Your computer may or may not agree with NAT.
Fairy way: so the answer is yes. Chrome allows up to six TCP connections to the same Host. There are some differences between browsers.
Developers.google.com/web/tools/c…
Sakuragi: If the RECEIVED HTML contains dozens of image tags, in what manner, in what order, how many connections are made, and what protocol is used to download the images
Fairy way: learned above those easier to answer!
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 HTTP2 can be used and if so use the Multiplexing function over the connection. But also would not necessarily all hang in the domain of resources will be to use a TCP connection to get, but what is certain is Multiplexing is likely to be used.
What if you can’t use HTTP2? Or you can’t use HTTPS (in real life HTTP2 is implemented over HTTPS, so you can only use HTTP/1.1).
The browser establishes multiple TCP connections on the same HOST. The maximum number of connections depends on the browser Settings. These connections are used by the browser to send new requests when idle. Then the other requests will have to wait
Hear here, Sakuragi also finally heartfelt admiration in front of the basketball talent
Sakuragi: Let’s play ball next time!