HTTP in Node.js: request, response, keep-alive

Every Node framework (Express, Fastify, Nest, Hono) sits on node:http. The server receives an IncomingMessage (request) and a ServerResponse (response). Frameworks add routing, middleware, and helpers - they do not replace HTTP.

1. Response: res.writeHead() + res.write()/res.end()

• The native http module only provides low-level building blocks: http.createServer((req, res) => {...}), without built-in .json(), .status(), or automatic routing.
• Writing a response manually (without Express):

res.writeHead(200, { 'Content-Type': 'application/json' });
res.write(JSON.stringify({ users: ['alice', 'bob'] }));
res.end();

• Express's res.status(200).json(data) is essentially a cleaner wrapper around those exact 3 steps: setting the status code, setting the Content-Type header, running JSON.stringify(), and calling end().

2. Request: req is a Readable stream

• req in the native http module is actually a Readable stream; body data arrives in chunks via the data event and completes with the end event, rather than being available as a complete block from the start. (The general concept of Readable streams was covered in Phase 1 via fs.createReadStream, while recognizing that an HTTP server's req is also a Readable stream is the new connection learned here.)
• Writing manually to receive the full body before processing:

let body = '';
req.on('data', chunk => { body += chunk; });
req.on('end', () => {
  const data = JSON.parse(body);
  // only now is the full data available to use
});

• express.json() (middleware) essentially performs that exact process: listening for data/end, aggregating chunks, running JSON.parse(), and assigning the result to req.body.
• Because reading the entire body stream is an asynchronous operation, express.json() must run as middleware before the route handler (calling next() once finished), ensuring that by the time the handler runs, req.body is fully populated.
• Practical consequence: forgetting app.use(express.json()) causes req.body in route handlers to always be undefined, because no middleware consumed the stream.

3. Connection keep-alive

• Before sending an HTTP request, the client and server must perform a TCP three-way handshake, which adds latency (ranging from tens to hundreds of milliseconds depending on network distance).
• Connection: keep-alive instructs the client and server: "do not close the TCP connection after sending the response; keep it open for subsequent requests," preventing repeated handshakes when loading multiple resources from the same server (for example, 20 HTML/CSS/JS/image files for a webpage).
• Keep-Alive: timeout=5 (observable in actual response headers) is a balanced configuration: long enough to reuse connections for closely timed requests, but automatically closing after 5 seconds of inactivity to avoid holding connection resources indefinitely.
• Express (via the underlying http module) enables keep-alive automatically by default without requiring manual configuration.
• Trade-off: keeping connections open saves handshake overhead for subsequent requests, but it consumes system resources (file descriptors, RAM) while sitting idle waiting for the next request, which impacts the total number of concurrent connections the server can handle.

4. Keep-alive risks in production and protective timeouts

• Slow clients occupying sockets: A client on a weak network or sending a large body (slow upload) keeps the TCP connection open for a long time, occupying 1 slot in the server's concurrent connection capacity, even though the server is doing nothing during that time except waiting for data.
• Node's built-in protective mechanisms:
  • server.maxConnections: a hard limit on the number of concurrent connections, rejecting new connections once exceeded.
  • headersTimeout (Node 18+): the maximum time limit to receive complete HTTP headers, preventing clients from trickling headers (Slowloris-style attacks).
  • requestTimeout (Node 18+): the maximum time limit for the entire request, automatically terminating if the handler takes too long to process or the client sends the body too slowly.
• Load balancers have their own idle timeouts: A Node server typically sits behind a load balancer (Nginx, AWS ALB...). If Node keeps a connection open longer than the load balancer's timeout, the load balancer silently closes the connection on its end while Node assumes it is still active, causing subsequent requests on that connection to fail abruptly with ECONNRESET without an obvious cause (an "opaque disconnect"). Node's timeout must be configured to be shorter than that of the upstream load balancer.
• Interview takeaway: when a Node server is "slow" in production, the root cause is often not a blocked event loop, but rather a request handler that never calls res.end() (hanging indefinitely), the absence of protective timeouts, or awaiting an unbounded I/O operation (e.g. a hanging third-party API call). These "zombie" requests silently monopolize connections and exhaust the server's capacity to serve traffic, even while CPU and event loop usage remain idle.
• Practical takeaway: the missing next() error practiced in the Middleware section (which causes the response to hang indefinitely because it never reaches res.end()) is a concrete, easily visible example at the development level of the exact same "handler never ends" error class that production encounters at scale.