Skip to content

CONCEPT Cited by 1 source

TCP idle timeout

Definition

A TCP idle timeout is the duration a network device (load balancer, firewall, NAT gateway) holds an idle TCP flow in its connection-tracking table before silently dropping it. Once dropped, subsequent packets on the old flow are rejected or black-holed — the server may still consider the connection open while the intermediary has already discarded it.

Why it matters for persistent connections

For short-lived HTTP request-response flows, idle timeouts are rarely a concern. For persistent connections (WebSocket, gRPC streams, database connection pools), the idle timeout becomes a lifecycle constraint that the application must actively manage — typically via keepalive messages that reset the idle timer before it fires.

AWS NLB specifics

The AWS Network Load Balancer has a 350-second TCP idle timeout that is not configurable (as of 2026). Any persistent TCP connection routed through an NLB must send at least one packet within every 350-second window or the NLB will drop the flow. The NLB operates at Layer 4 — it cannot inspect HTTP headers or WebSocket frames; it only tracks TCP flow liveness by packet activity.

This is a load-bearing constraint for game servers, chat services, and real-time collaborative applications behind NLB.

(Source: sources/2026-06-29-aws-dual-token-authentication-for-nakama-game-servers)

Common mitigations

  1. Application-level ping/pong: server sends periodic keepalive frames (WebSocket ping, gRPC keepalive, custom heartbeat) well within the idle window.
  2. TCP keepalive at socket level: SO_KEEPALIVE with an interval below the idle timeout — less portable, not always configurable from application code.
  3. Shorter session lifetimes: force reconnection before the idle timeout window, accepting reconnection cost.

Seen in

Last updated · 562 distilled / 1,660 read