How Many HTTP Requests Can a Single TCP Connection Handle?

TCP and HTTP Origins

TCP operates at the transport layer while HTTP runs at the application layer; HTTP is built on top of TCP. Early browsers opened a new TCP connection for each resource, which was inefficient as web pages grew to include many JS, CSS, and image files.

To improve efficiency, the Keep‑Alive mechanism was introduced, allowing a single TCP connection to be reused for multiple HTTP requests.

Question 1: Does the browser close the TCP connection after a single HTTP request?

The Connection header determines whether a connection is persistent. In HTTP/1.0 the default is close, so each request creates and tears down a TCP connection, incurring high overhead. In HTTP/1.1 the default is keep-alive, allowing the same connection to be reused until it times out or the client explicitly sends Connection: close. Reusing connections reduces both TCP handshake and SSL negotiation costs.

Question 2: How many HTTP requests can a TCP connection correspond to?

If the Connection header is set to close, the TCP connection carries only one HTTP request. If it is set to keep-alive, the same TCP connection can serve one or many HTTP requests sequentially.

Question 3: Can multiple HTTP requests be sent simultaneously over one TCP connection?

In HTTP/1.1 a single TCP connection can process only one request at a time. RFC 2616 defines pipelining, which lets a client send multiple requests without waiting for each response, but browsers disable it by default due to issues such as proxy incompatibility and head‑of‑line blocking.

HTTP/2 introduces multiplexing, allowing a single TCP connection to carry many concurrent HTTP requests with theoretically unlimited parallelism, though browsers often impose their own limits.

Question 4: Does the browser limit the number of TCP connections per host?

Different browsers impose different limits; for example, Chrome allows up to six simultaneous TCP connections to the same host. When only HTTP/1.1 is supported, browsers open multiple connections to improve performance. With HTTPS, after the SSL handshake the browser may negotiate HTTP/2 multiplexing.

Question 5: Keep‑alive usage scenarios, advantages and disadvantages

Enabling keep‑alive increases memory usage, while disabling it raises CPU consumption. If both resources are ample, the performance impact is minimal. For static pages with many assets, keep‑alive is recommended; for dynamic pages, disabling may be preferable. Server‑side, keep‑alive requires keepalive_timeout in Nginx to be greater than zero.

Summary

The analysis clarifies the TCP‑HTTP relationship, shows how modern browsers optimize network performance across different HTTP versions, and highlights that HTTP/2 multiplexing underpins many high‑performance frameworks such as gRPC.