Server
Keep-alive timeout
Keep-alive timeout is how long a server holds an idle HTTP connection open waiting for the next request before closing it. Reusing a connection avoids another TCP and TLS handshake.
How it is measured
Find the setting for each layer: Nginx `keepalive_timeout` (75 seconds by default), Node's `server.keepAliveTimeout` (5 seconds), and your load balancer's idle timeout (60 seconds on many cloud balancers). Compare the values from client to origin.
A reused connection saves a round trip for TCP and one or two for TLS. At 80 ms round trip time, that is 160 to 240 ms saved on each new request that can reuse one.
Worked example
An AWS load balancer has a 60 second idle timeout. The Node origin behind it uses the default 5 second keep-alive. The balancer reuses a connection that Node closed 2 seconds ago, sends a request into it, and gets a reset. Visitors see sporadic 502 errors, about 0.3 percent of requests.
Setting Node's keepAliveTimeout to 65 seconds, longer than the balancer's, stops the resets. The errors had no relation to load, only to who closed first.
How it differs
Keep-alive timeout controls when an idle connection is closed. Connection reuse is the benefit of having it still open for the next request. The timeout excludes any promise of reuse, and reuse excludes a connection that already timed out. Setting it too short wastes handshakes. Too long, and idle sockets use up descriptors.
Common errors
Setting the origin timeout shorter than the balancer's. Using very long values on a server with many clients and exhausting file descriptors. Disabling keep-alive to fix a bug that was elsewhere. Forgetting HTTP/2 multiplexes on one connection. Ignoring the upstream keepalive between Nginx and the app.
In practice
List the idle timeout at each hop between visitor and app and make each one further in longer than the one before. Watch for sporadic 502 or connection reset errors with no traffic pattern, which usually signal a mismatch.