Concurrency limitation and queue-first blocking in HTTP protocol

Serial Connection

The http/0.9 and early http/1.0 protocols are serialized for HTTP request processing. If a page contains 3 style files, it belongs to a protocol, domain name, port. Then, the browser needs to initiate four requests, and only one TCP channel can be opened at a time, after a request resource completes the download, disconnect the connection immediately, and then open a new connection to process the next request in the queue. As the size of the page resources, the number of continuous amplification, network delay time will continue to accumulate, the user will face full screen blank, waiting for a long time and lose patience.

Parallel connections

To improve the throughput of the network, the improved HTTP protocol allows the client to open multiple TCP connections simultaneously, requesting multiple resources in parallel and making full use of the bandwidth. Typically, there is a delay between each connection, but the transfer time of the request is overlapping and the overall delay is much lower than the serial connection. Considering that each connection consumes system resources and the server needs to handle a huge amount of user concurrent requests, the browser limits the number of concurrent requests. Even if the RFC does not specify a specific limit number, browser vendors will have their own standards:

IE 7:2
IE 8/9:6
IE 10:8
IE 11:13
Firefox:6
Chrome:6
Safari:6
Opera:6
IOS Webview:6
Android Webview:6

Persistent connection (long connection)

The earlier HTTP protocol used a separate TCP connection for each request, which undoubtedly increased TCP's connection overhead, congestion control overhead, freeing connection overhead, and the improved http/1.0 and http/1.1 (default) support for persistent connections. If a request is completed, it is not immediately disconnected, but remains connected for a certain amount of time in order to quickly process the incoming HTTP request and reuse the same TCP channel until the client heartbeat fails or the server connection times out. This feature can be activated via HTTP header connection:keep-alive, and the client can also send connection:close to actively close the connection. So, we see that both parallel connections and persistent connections are mutually reinforcing, and that parallel connections make it possible for the first load page to open multiple TCP connections at the same time, while persistent connections guarantee the subsequent requests to reuse the open TCP connection, which is also a common mechanism for modern Web pages.

pipelined connections

A persistent connection allows us to reuse the connection to complete multiple requests, but it must satisfy the queue order of the FIFO, must ensure that the previous request successfully arrives at the server, processing succeeds, and receives the first byte returned by the server before the next request in the queue can be initiated. The HTTP pipeline allows the client to continuously initiate multiple requests within the same TCP channel without waiting for a response, eliminating the round-trip delay time difference. But the reality is that because of the limitations of the http/1.x protocol, data is not allowed to interleave on one link (IO multiplexing). Imagine a situation where the client server sends an HTML and multiple CSS requests simultaneously, the server handles all requests in parallel, and when all the CSS requests are processed and added to the buffer queue, the HTML request processing encounters a problem and is suspended indefinitely, causing the buffer overflow to be severe even. This is called the first block of the team. Therefore, the scheme was not adopted in the http/1.x agreement.

Team header blocking is not a unique concept in HTTP, but a common phenomenon in the exchange of cached communication networks.

Summarize

1, for the same protocol, domain name, port, the browser allows to open a TCP connection at the same time, a general limit of 6.
2, the same TCP connection allows multiple HTTP requests to be initiated, but must wait for the first byte response from the previous request to reach the client.
3, because of the team first blocking problem, the client is not allowed to send all requests in the queue at the same time, this problem is http/2.0 resolved.