The cost of new connections
Opening a connection is expensive. A new HTTPS request needs a TCP handshake and a TLS handshake before any data flows, costing several round trips. Doing this for every request wastes time and resources. A connection pool keeps a set of established connections alive and hands them out for reuse.
How a pool behaves
- After a request finishes, the connection is returned to the pool instead of being closed.
- A later request to the same host checks out an idle connection, skipping the handshakes.
- The pool caps how many connections it keeps, both total and per host, to bound resource use.
Pools need careful tuning. An idle timeout closes connections the server may have already dropped, avoiding errors from sending on a dead socket. The max per host limit prevents one slow backend from starving others. Setting the pool too small serializes requests and adds latency, while setting it too large can overwhelm a backend or exhaust local sockets.
Key idea
Connection pooling reuses established connections to skip repeated TCP and TLS handshakes, tuned with idle timeouts and per host limits to balance speed against resource use.