Node.js interview questions: HTTP and networking

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.

There are a few timeouts on the server object. server.timeout is how long a socket can sit idle before Node destroys it. Then there's keepAliveTimeout, which is how long an idle keep-alive connection stays open waiting for the next request, I think that one defaults to 5 seconds. And newer Node versions added headersTimeout and requestTimeout to guard against clients that send data really slowly. That slow trickle thing is basically what a slowloris attack is, the attacker opens a ton of connections and dribbles bytes to exhaust the server's capacity. The general idea with all of these is capping how long any single client can tie up a connection, so a slow or malicious client can't hold resources open forever. You set them on the server object and tune them against how long your legitimate requests and uploads actually take.

The main improvement in HTTP/2 is multiplexing. With HTTP/1.1 a connection carries one request and response at a time, which is why browsers open several connections in parallel, and a slow response can hold up whatever's waiting behind it on the same connection. HTTP/2 lets a bunch of requests and responses share one connection as independent streams that interleave, so one slow response doesn't block the rest anymore. It also compresses headers with HPACK, and there's server push. If you're serving lots of small resources that cuts latency and connection overhead. Node has a built-in http2 module for this. I'd say the move usually helps when you've got many concurrent requests going to the same origin, because you get the concurrency without paying for several TCP and TLS handshakes.

So TLS termination is just the point where the encrypted traffic gets decrypted. You can do that at a load balancer or reverse proxy sitting in front of Node, or Node can terminate it itself with the https module. Putting it on the proxy is the common choice, it moves the crypto work off your app and keeps certificate management in one place. The handshake is the expensive part because it uses asymmetric cryptography to exchange keys and verify the server certificate, and the symmetric encryption protecting the actual data afterward is much cheaper. To cut the cost you use keep-alive so connections get reused across requests, and session resumption so returning clients can skip part of the handshake. TLS 1.3 needs fewer round trips than 1.2, so it's faster. Usually you just terminate at the edge and reuse connections so you're not paying full handshake cost over and over.

So in Node the request object is a readable stream, the body comes in as data events unless you've got a body parser in front. With Express you add express.json() or express.urlencoded() and then you just read req.body. With raw http you listen for the data chunks, concatenate them, and handle the full body on end. The client says how big the body is with the Content-Length header, or it uses chunked transfer encoding when it doesn't know the size ahead of time. For big uploads you're supposed to stream instead of buffering everything in memory, so pipe the request to a file or a storage service rather than building one giant Buffer. And you want a size limit so a client can't send an unbounded body and exhaust memory. Most parsers let you configure a max body size, Express defaults to a 100KB limit for JSON I believe.

Behind a proxy the TCP connection Node sees is coming from the proxy, so req.socket.remoteAddress is going to hold the proxy's address, not the client's. The real client IP shows up in the X-Forwarded-For header, which proxies add to record the original client address. In Express you set trust proxy and then req.ip reads from that header. For WebSockets, they start out as a normal HTTP request that carries an Upgrade: websocket header, and the server answers with a 101 status to switch protocols. After that the same TCP connection just carries WebSocket frames. Libraries like ws do the handshake for you by listening on the server's upgrade event. Your proxy has to pass those upgrade headers through or the WebSocket connection fails. And you should only trust the forwarded headers when they come from your own proxy, I think that's the main gotcha.

Node does hostname resolution through the dns module. The common path is dns.lookup, that's what runs under the hood when you make an HTTP request to a hostname, it turns the name into an IP address. There's also dns.resolve, plus dns.resolve4 and dns.resolve6, which query DNS servers directly. The difference as I understand it is that dns.lookup uses the operating system's resolver, so it respects /etc/hosts and system configuration, while dns.resolve talks to DNS servers over the network instead. Node doesn't cache DNS results by default, so every new connection can trigger a fresh lookup, and under high outbound volume that adds latency and load. To cut that down you can add a DNS cache, either in the application or by running a local caching resolver. Which method you pick kind of depends on whether you want system behavior or raw DNS records.

ECONNRESET means the connection got reset by the other side, so the peer sent a TCP RST instead of closing cleanly. You see it a lot when a client disconnects before the server finishes responding, or when a timeout closes a connection, or a proxy drops an idle one. The way you handle it is attaching an error listener to the socket or the request, so an unhandled error doesn't crash the process. A half-open connection is when one side has closed its end but the other hasn't, so data can still flow one way. And the listen backlog is the queue of pending connections waiting to be accepted, if that fills up new connections can get refused. In practice you log these errors, figure out whether they point at a real client problem, and try not to treat every reset as fatal, since some of them are basically just clients going away.

Raw Node http is the fastest since nothing sits on top of it, but then you're writing routing and parsing yourself. Express is the most popular framework, it gives you routing and middleware and a lot of convenience at some performance cost, because every request passes through its middleware stack. Fastify is the one built for performance, it benchmarks faster than Express, mostly down to a more efficient router and fast JSON serialization. In benchmarks it handles more requests per second than Express on simple routes. Whether you'd actually notice depends on the workload though. If each request does a database query or calls another service, that I/O usually dominates and the framework overhead is a small fraction of the total. So basically you pick a framework for its libraries and developer experience, and you only worry about raw overhead when you're serving very high volumes of lightweight requests.