How do http.Transport's MaxIdleConnsPerHost and MaxConnsPerHost decide how many sockets a client holds?

## The transport is the pool In Go, an `http.Client` is a thin policy wrapper; the connection pool lives in its `http.Transport`. A transport keeps finished keep-alive connections in an **idle connection pool**, keyed by scheme, host and proxy, and hands one back to the next request for the same key. That reuse is why an HTTP client in a hot loop does not pay a TCP handshake and a TLS handshake per request — and it is also why the number of sockets a Go service holds is a property of the transport's configuration, not of your request code. Four fields shape it. ### MaxConnsPerHost — the total ceiling `MaxConnsPerHost` limits **all** connections to one host: those being dialled, those actively carrying a request, and those sitting idle. **The zero value means no limit.** That default is the one that matters for descriptor exhaustion: with no ceiling, if 5,000 requests to one upstream are in flight at once, the transport opens 5,000 sockets. Set it, and a request that finds every connection busy blocks until one frees up instead of dialling a new one. That converts a descriptor problem into a latency problem, which is nearly always the trade you want — but note that blocked requests wait on the connection, so the request context or client deadline is what stops them waiting forever. ### MaxIdleConnsPerHost — the reuse ceiling `MaxIdleConnsPerHost` limits only how many *finished* connections to one host are retained for reuse. Its zero value falls back to the constant `http.DefaultMaxIdleConnsPerHost`, which is **2**. This surprises people: a service hammering a single upstream at 200 concurrent requests keeps only two connections and closes the other 198 as each response completes, then dials fresh ones for the next batch. The important nuance is what that costs. A connection closed because the idle pool is full does **release** its descriptor, so this alone is churn rather than accumulation: handshake CPU, latency, and a pile of sockets in the kernel's `TIME_WAIT` state, which can exhaust ephemeral ports before it exhausts descriptors. But churn and an unbounded `MaxConnsPerHost` compound: with no reuse, live connection count rides concurrency exactly, and a slow upstream stretches how long each one lives. That is when the descriptor count goes vertical. ### MaxIdleConns — the same cap across all hosts `MaxIdleConns` is the global idle budget, 100 in `http.DefaultTransport`. It matters for a service that talks to many hosts: per-host slots are useless if the global pool evicts them. ### IdleConnTimeout — how long idle ones live `IdleConnTimeout` (90 seconds in `http.DefaultTransport`) closes a pooled connection that has gone unused for that long. Lowering it returns descriptors sooner and reduces the chance of using a connection the peer has already dropped; raising it improves reuse for bursty traffic. Note this is the *idle-connection* lifetime and has nothing to do with how long a request may take. ## The anti-pattern that defeats all four ```go func fetch(url string) (*http.Response, error) { client := &http.Client{Transport: &http.Transport{}} // new pool every call return client.Get(url) } ``` Because the pool lives in the transport, building a new transport per request gives every request a private pool of one, which is discarded immediately afterwards. Nothing is ever reused, and both descriptor count and handshake cost scale with request rate. `http.Client` and `http.Transport` are safe for concurrent use by design: create one per upstream (or one for the process) at startup and share it. If you must discard a transport, call its `CloseIdleConnections` so its pooled sockets are released rather than waiting for the idle timeout. The same reasoning applies to `DisableKeepAlives: true`, which tells the transport to close every connection after a single request. It is occasionally right for a one-shot CLI, and it is the worst possible setting for a long-lived service. ## HTTP/2 changes the shape Over HTTP/2 a single connection multiplexes many concurrent streams, so one socket per host can serve hundreds of requests and the per-host connection caps mostly stop being the binding constraint. When `http.DefaultTransport` negotiates HTTP/2 to an upstream that supports it, descriptor pressure on that leg largely disappears; when the upstream is HTTP/1.1, you are back to one connection per in-flight request. That is why the same client code can be perfectly healthy against one upstream and exhaust descriptors against another. ## How to pick numbers Start from the concurrency you actually run per upstream. Set `MaxIdleConnsPerHost` at or slightly above the steady-state concurrency so ordinary traffic is served entirely from the pool; set `MaxIdleConns` to the sum across upstreams; set `MaxConnsPerHost` to the largest number of simultaneous connections that upstream should ever see from one instance, which is both a descriptor ceiling for you and a politeness bound for them. Then multiply by the number of upstreams and check the total against the descriptor limit the process actually has.