http-networkingAnswer last reviewed July 2026

Say your service makes a ton of outbound HTTP calls to the same few downstreams. How does Node actually reuse those connections, and what goes wrong if you get that part wrong?

Strong candidates get concrete about connection reuse, agents, socket pools, keep-alive, and know exactly how undici differs from the old http.Agent.

What an AI-prepared candidate might say

So Node supports HTTP keep-alive, meaning it keeps the TCP connection open after a response so the next request to that server can reuse it instead of doing the whole TCP handshake and TLS negotiation again. On the client side there's an agent that manages this. The http.Agent and https.Agent hold a pool of sockets, and when you make a request the agent gives you an idle socket to that host if one's free, otherwise it opens a new one. Reusing the connection saves you the setup round trips, so lower latency, and less load on the downstream too. I think recent Node versions turn keep-alive on by default on the global agent. For heavy outbound traffic you basically want pooling on so you're not paying handshake cost on every single call, and you can tune how many sockets the agent keeps around.

Senior
Locked

What an agent really holds, those free and in-use socket lists keyed by host, and why undici's pipelined connection pool acts so differently under concurrency than http.Agent.

Unlock the depth
Staff
Locked

The failures that actually show up at scale, maxSockets queueing and head-of-line stalls on a pooled connection, and how to read the socket counters that give them away.

Unlock the depth
Follow-up chain
Say your service makes a ton of outbound HTTP calls to the same few downstreams. How does Node actually reuse those connections, and what goes wrong if you get that part wrong? | NodeBook