Sequence numbers and connection state

You know the three steps of the handshake. Now look at what those steps actually exchange: random 32-bit counters whose specific values are not arbitrary — they are a security mechanism, a timing mechanism, and a state machine checkpoint all at once.

The three-step dance in detail

Bea sends SYN seq=X. She moves to state SYN-SENT. Sven receives it, allocates a buffer for the incoming direction, moves to state SYN-RECV, and replies SYN-ACK seq=Y ack=X+1. The ack=X+1 means “I saw your sequence number X; the next byte I expect from you is X+1.” (The SYN flag itself consumes one sequence number even though no data byte is sent.) Bea then sends ACK seq=X+1 ack=Y+1 and moves to state ESTABLISHED. Sven receives it, moves to state ESTABLISHED, and the connection is live.

Initial Sequence Numbers (ISN) — why random?

RFC 6528 specifies that ISN is computed as:

ISN = M + F(saddr, sport, daddr, dport, secret_key)

where M increments once per ~4 µs (making it hard to guess from the outside), and F is a hash of the 4-tuple and a secret key. Older implementations used a simple counter, which attackers exploited: an attacker could guess the next ISN, forge a packet with the right sequence number, and inject commands into an established connection. Modern ISNs are cryptographically random per connection, making blind injection impossible without eavesdropping.

The 1-RTT cost

Bea sends SYN, waits for SYN-ACK (1 RTT), sends ACK, and only then can she send an HTTP request. If the RTT is 100 ms (across a continent), 100 ms of latency is baked into the connection before the first application byte lands. This RTT matters because it decides the cadence of the entire application.

Connection close: FIN and TIME-WAIT

Closing is the mirror of opening: each side independently sends FIN to signal “I have no more data,” and the peer ACKs. Connections sit in TIME-WAIT for 2×MSL (~120 s typical) so any straggler retransmission can land harmlessly instead of being mistaken for a new connection’s data. The side that initiates close pays the TIME-WAIT cost; on busy clients this is fine, on busy servers it can become a problem — see the lesson on SYN cookies and TFO for TIME-WAIT exhaustion at scale.

The state machine

The states you will see in ss -tan output:

An accumulation of CLOSE-WAIT on a server usually means the application is not calling close() on accepted sockets — a resource leak.