Run a few thousand concurrent browser sessions and you'll hit a wall that feels arbitrary: ports exhaust, connections pile up in limbo, and suddenly your infrastructure can't establish new sessions even though bandwidth looks fine. The operational puzzle isn't resource limits. It's TIME_WAIT states—closed connections lingering for minutes, consuming ephemeral ports until the system chokes.

TCP is doing exactly what it was designed to do.

The design traces to October 1986, when the Internet experienced its first catastrophic congestion collapse. Data throughput between Lawrence Berkeley Laboratory and UC Berkeley—sites 400 yards apart—dropped from 32 Kbps to 40 bps. A thousand-fold reduction. The Internet was drowning in its own traffic.

Van Jacobson and Michael Karels discovered TCP implementations were producing "exactly the wrong behavior in response to network congestion." Their 1988 solution introduced mechanisms that saved the Internet: slow start, exponential backoff, dynamic window sizing. When establishing a connection, start with a single packet. Wait for acknowledgment. Gradually ramp up, doubling the sending rate as confirmations return. This prevents overwhelming routers with sudden traffic bursts.

The mechanisms worked brilliantly for their intended use case: bulk data transfer over long-lived connections. Moving large files via FTP. Transferring email. Applications where connections lasted minutes or hours, where the initial slow start penalty vanished against sustained throughput.

The web had other ideas.

When Small Requests Met Big Assumptions

By the mid-1990s, the W3C documented a fundamental problem:

The protocol was incurring "heavy latency penalties" from the mismatch between web traffic and TCP's design assumptions. The web wasn't moving files. It was conducting billions of tiny request-response exchanges.

Consider what slow start means in practice. When a browser requests a small image, TCP starts by sending a single packet, waiting for acknowledgment, then doubling the rate. For a 10KB file, the connection might close before TCP reaches full speed. The protocol was designed to prevent overwhelming the network—but for web traffic, it was throttling connections that would never reach the sustained throughput slow start was protecting against.

Each HTTP request meant: establish connection, perform slow start in both directions, transfer a few kilobytes, close connection. As the W3C noted:

TCP assumed substantial data transfer in one connection. The web violated this constantly, opening and closing connections for every resource. The protocol's careful congestion control became a performance penalty for traffic patterns nobody anticipated in 1988.

What This Means at Production Scale

We encounter these constraints daily building enterprise web automation. Connection pooling isn't optional—it's mandatory because closed connections linger in TIME_WAIT state for 1-4 minutes, a TCP protection against data loss. One engineer documented the problem clearly:

This was from running just 100 concurrent requests with a connection pool limited to 2 sockets. In a loop, thousands of connections accumulate, consuming ports until new connections fail.

The operational complexity shows up in unexpected places:

• Connection pools need careful tuning
• TIME_WAIT states require monitoring
• At sufficient scale, even ephemeral port ranges become resources to manage
• Anti-bot systems fingerprint TCP behavior, analyzing connection patterns that reveal automation

What looks like application-layer challenges often traces to transport-layer constraints designed for different traffic.

The operational puzzle that web agent teams encounter—port exhaustion, connection lifecycle complexity, the careful architecture required to avoid bottlenecks—comes from 1988's solution for a 1986 crisis. Connection management isn't incidental complexity that better tooling will abstract away. It's fundamental infrastructure reality, shaped by protocol decisions made for bulk data transfer now carrying billions of ephemeral conversations. At scale, this means treating connection lifecycle as a first-class architectural concern, not an implementation detail. Understanding this history doesn't eliminate the constraints, but it clarifies why they exist and what they cost.