URLSession httpMaximumConnectionsPerHost: Latency Uncertainty in iOS 17

Short answer

Increasing httpMaximumConnectionsPerHost above the default of four does not guarantee lower latency for 100+ concurrent GETs in iOS 17. The runtime still prefers to reuse idle connections, and HTTP/2 multiplexing or system‑wide throttling usually dominate the latency profile.

Confirmed facts (from Apple docs + lab observations)

• The default httpMaximumConnectionsPerHost is 4.
• Setting the limit higher lets the system open more TCP sockets, but only when all existing sockets for the host are busy or have exceeded idle‑time thresholds.
• When the host speaks HTTP/2 (ALPN negotiated), many requests are served over a single connection via multiplexing; the connection‑count limit becomes less impactful.
• On HTTP/1.1‑only endpoints, increasing the limit can reduce per‑request latency, but the improvement is often modest and still subject to OS throttling.
• The system may throttle connection creation to preserve battery and memory, so even a high limit can be capped at runtime.

Why the limit rarely eliminates spikes

• HTTP/2 multiplexing lets dozens of streams share one TCP connection, so adding more sockets yields diminishing returns.
• Connection‑pool heuristics keep sockets alive for a configurable idle period; new sockets are only created when the pool is exhausted.
• System throttling can cap total sockets per app or per network interface, especially under cellular or heavy background load.

How the runtime decides to open a new connection

1. Check the current pool for the host. If a socket is idle and not over the idle‑time threshold, reuse it.
2. If all sockets are busy or idle too long, and the pool size is below httpMaximumConnectionsPerHost, open a new TCP socket.
3. When the pool has reached the configured limit, the runtime will queue the request until a socket becomes free.
4. Throughout, the OS may enforce a global cap that overrides the per‑host limit.

Practical diagnostic steps

1. Create a URLSessionConfiguration and set httpMaximumConnectionsPerHost to a test value (e.g., 8).
2. Instantiate a URLSession with that configuration.
3. Launch 150 concurrent GET requests to a known HTTP/2‑enabled endpoint and record each request’s start and end time using CFAbsoluteTimeGetCurrent() or a custom URLSessionTaskDelegate.
4. Repeat the test with the limit set to 4 (default) and compare latency distributions.
5. Run the same test against an HTTP/1.1‑only endpoint to see if the limit has a more pronounced effect.
6. os_signpost or NetworkInstrument to log connection‑creation events and confirm whether new sockets are being opened under load.

What to check before adjusting the limit

• Does your server advertise HTTP/2 via ALPN? If not, the limit will matter more.
• Are you on cellular or Wi‑Fi? Battery‑aware throttling is tighter on cellular.
• Is the app likely to be backgrounded? Background apps get stricter socket limits.

Bottom line

Raise httpMaximumConnectionsPerHost only if you’re certain the server is HTTP/1.1‑only and you need to squeeze out the last bit of throughput. For most modern APIs that support HTTP/2, focus on optimizing request size, keep‑alive headers, and server‑side stream limits rather than pushing the connection count higher.