CodeParkA persistent connection stays open after a response, so the client can send the next request on it. HTTP/1.1 made this the default.
In HTTP/1.0, the connection usually closed after each response. So every request paid for a new TCP handshake, and a new TLS handshake too. In HTTP/1.1, the client can send another request on the same connection after the previous response finishes. The connection stays open until one side sends Connection: close, or until an idle timeout ends it.
Why browsers still opened several connections: an HTTP/1.1 connection handles only one request at a time.
Pipelining means sending several requests without waiting for the responses. HTTP/1.1 defined it, but it had problems:
- Responses still had to come back in the same order as the requests.
- It was buggy when it passed through proxies.
- So browsers turned it off.
To load many files in parallel, browsers open a small pool of connections per origin, usually six. HTTP/2 removed this need. It uses multiplexing: it sends many streams at the same time over one connection.
- HTTP/1.1 keeps connections open by default, so it can reuse the handshakes.
- Each connection has only one request in progress at a time.
- Pipelining exists, but in practice nobody uses it.
- Browsers open a few parallel connections per origin, and HTTP/2 multiplexing fixes this.