A TCP connection can send the number of HTTP requests?

Disclaimer: This article is a blogger original article, shall not be reproduced without the bloggers allowed. https://blog.csdn.net/wufaliang003/article/details/90664238

There was such a face questions: from the URL in the browser is input to the page to show what happened in the process?

I believe most of the students can answer ready for it, but if you continue to ask: HTML received if the label contains dozens of pictures, these pictures are what way, in what order, how many connections established, what protocols are downloaded it?

To get to know the problem, we need to solve the following five questions:

  1. Modern browser and server to establish whether the disconnection will be completed in a HTTP request after a TCP connection? Will be disconnected under what circumstances?

  2. A TCP connection can correspond to several HTTP requests?

  3. A TCP connection transmitting an HTTP request can be sent with it (such as a request made with three, then three responses received together)?

  4. Why sometimes refresh the page do not need to re-establish an SSL connection?

  5. Host of the same browser establishes a TCP connection there is no limit to the number?

first question

Modern browser and server to establish whether the disconnection will be completed in a HTTP request after a TCP connection? Will be disconnected under what circumstances?

In HTTP / 1.0 in a server After sending a HTTP response, disconnects the TCP connection. But this every request to re-establish a TCP connection and disconnection, the cost is too large. Therefore, although there is no set standard, some server Connection: keep-alive were the Header support. This means that, after the completion of the HTTP request, do not disconnect the HTTP request using TCP connections. The advantage is that the connection can be reused time after sending HTTP requests do not need to re-establish a TCP connection, and if we maintain the connection, also avoid the overhead of SSL, two pictures of my short two visits https: / /www.github.com time statistics:

The first time access, and SSL connection initialization overhead

SSL connection initialization and overhead goes away, using the same TCP connection

Persistent connections: Since so many benefits to maintain TCP connections, HTTP / 1.1 Connection head put written standards, and persistent connections enabled by default, unless stated in the request Connection: close, then between the browser and the server will continue for some time TCP connection, not a request to cut off the end.

So the answer to the first question is: to establish default TCP connection is not disconnected, only the request header declaration Connection: close will close the connection after the request is complete.

second question

A TCP connection can correspond to several HTTP requests?

Knowing the first question, in fact, this question has been answered, if we maintain the connection, a TCP connection can send multiple HTTP requests.

The third question

A TCP connection transmitting an HTTP request can be sent with it (such as a request made with three, then three responses received together)?

HTTP / 1.1 there is a problem, a single TCP connection at the same time can handle only one request, meaning that: the life cycle of the two requests can not overlap, any two HTTP requests to the end of time can not start from the same TCP connection in overlapping.

While HTTP / 1.1 specification defines Pipelining to try to solve this problem, but this feature is off by default in the browser.

Pipelining first look at what is specified in the RFC 2616:

A client that supports persistent connections MAY "pipeline" its requests (ie, 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 support persistent connections of customers end may send multiple requests on a connection (need not wait for a response to any request). Server receives a request must be sent in response to the request in the order received.

As for why such a standard is set, we can probably guess one reason: because the HTTP / 1.1 protocol is text, and returns the contents also can not distinguish corresponds to which to send the request, the order must remain the same. For example, you two requests to the server GET/query?q=A and GET/query?q=Bthe server returns the two results, the browser based on the response result is no way to determine which of a response corresponding to the request.

Pipelining this idea looks nice, but there will be many problems in practice:

  • Some proxy servers can not correctly handle HTTP Pipelining.

  • Correct pipeline implementation is complex.

  • Head-of-line Blocking blocking connector: after establishing a TCP connection, assuming continuous transmission of several client request to the server in this connection. As standard, the server should return the results in the order of receipt of the request, assuming that the server spend a lot of time when processing the first request, all subsequent requests need to wait for the end of the first request to respond.

So modern browser default is not open HTTP Pipelining is.

However, provided Multiplexing HTTP2 multiplex transmission characteristic, a plurality of HTTP requests can be completed simultaneously in a TCP connection. As for how to achieve specific Multiplexing is another question. We can look at the use of HTTP2 effect.

Green is a request to initiate a request for the return of the waiting time, download time response is blue, you can see all the same in a Connection, done in parallel

So the answer to this question has also been: the presence in HTTP / 1.1 Pipelining technology can simultaneously send multiple requests to complete this, but because the browser is off by default, so you can think that this is not feasible. In HTTP2 Multiplexing characteristics due to the presence, a plurality of HTTP requests may be performed in parallel on the same TCP connection.

So in HTTP / 1.1 era, the browser is how to improve page load efficiency of it? There are the following two points:

  1. And maintain the server TCP connection has been established, the same connection sequence processing a plurality of requests.

  2. And server to establish multiple TCP connections.

The fourth question

Why sometimes refresh the page do not need to re-establish an SSL connection?

在第一个问题的讨论中已经有答案了,TCP 连接有的时候会被浏览器和服务端维持一段时间。TCP 不需要重新建立,SSL 自然也会用之前的。

第五个问题

浏览器对同一 Host 建立 TCP 连接到数量有没有限制?

假设我们还处在 HTTP/1.1 时代,那个时候没有多路传输,当浏览器拿到一个有几十张图片的网页该怎么办呢?肯定不能只开一个 TCP 连接顺序下载,那样用户肯定等的很难受,但是如果每个图片都开一个 TCP 连接发 HTTP 请求,那电脑或者服务器都可能受不了,要是有 1000 张图片的话总不能开 1000 个TCP 连接吧,你的电脑同意 NAT 也不一定会同意。

所以答案是:有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。

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

那么回到最开始的问题,收到的 HTML 如果包含几十个图片标签,这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢?

如果图片都是 HTTPS 连接并且在同一个域名下,那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2,如果能的话就使用 Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取,但是可以确定的是 Multiplexing 很可能会被用到。

如果发现用不了 HTTP2 呢?或者用不了 HTTPS(现实中的 HTTP2 都是在 HTTPS 上实现的,所以也就是只能使用 HTTP/1.1)。那浏览器就会在一个 HOST 上建立多个 TCP 连接,连接数量的最大限制取决于浏览器设置,这些连接会在空闲的时候被浏览器用来发送新的请求,如果所有的连接都正在发送请求呢?那其他的请求就只能等等了。

关注微信公众号和今日头条,精彩文章持续更新中。。。。。

 

Guess you like

Origin blog.csdn.net/wufaliang003/article/details/90664238