TCP handshake simulator

The two vertical lines are the client and the server; time runs downwards. Each arrow is one TCP segment, labelled with its flags, its sequence number, its acknowledgement number and the number of data bytes it carries. The state each side enters is written beside its line, using the names from the TCP specification that tools such as ss and netstat also show.

Buttons like Connect, Send and Close are what the applications do: they make a side send segments. Next event moves time forward to the next thing that happens, usually a segment arriving or a timer running out; Play does that every second. Try these:

• Press Connect, then Next event until both sides are ESTABLISHED. Send some data from each side, close the client, then close the server. The client ends in TIME_WAIT for 60 seconds of simulated time.
• Press Connect and one Next event, then turn on Lose the next segment before the next step. Watch the retransmission timer resend what was lost, and how the timer doubles.
• Close the client and stop: the server sits in CLOSE_WAIT until you press its Close. That is what a program that forgets to close sockets looks like.
• Choose Not listening before connecting. The server's TCP answers the SYN with an RST, which an application sees as "connection refused".
• After the handshake, press Close on both sides before any FIN arrives. Both go through CLOSING, a state most connections never visit.

The model follows the state machine and segment-handling rules of RFC 9293 and the retransmission timer of RFC 6298. To keep the diagram readable it leaves out flow and congestion control, acknowledges every segment at once instead of delaying ACKs, drops segments that arrive out of order instead of queuing them, and exchanges no options. Initial sequence numbers are random but seeded, so a fresh page always gives the same numbers as the example below.

The TCP three-way handshake is the exchange of three segments that opens a TCP connection. The client sends a SYN, the server answers with a SYN-ACK, and the client replies with an ACK. Web pages, API calls, database queries and SSH sessions that run over TCP all start this way.

TCP gives applications a reliable, ordered stream of bytes on top of IP, which delivers individual packets with no promises: they can be lost, duplicated or arrive out of order. To make that work, TCP numbers every byte it sends, and the receiver acknowledges the numbers it has received. The handshake exists so that each side can tell the other where its numbering starts, and hear back that the other side got it.

A segment is TCP's name for one unit of data plus its TCP header. SYN, ACK, FIN and RST are single-bit flags in that header.

Before anything happens, the server's application has created a socket, bound it to a port and called listen(), so the server's TCP is in LISTEN. The client's application then calls connect().

1. SYN. The client picks a random 32-bit initial sequence number, call it x, and sends a segment with the SYN flag set and sequence number x. It enters SYN_SENT.
2. SYN-ACK. The server picks its own random initial sequence number y and replies with SYN and ACK both set: sequence number y, acknowledgement number x + 1. The acknowledgement number is always the next byte the sender expects to receive. The server enters SYN_RCVD, and the connection waits in the server's SYN queue.
3. ACK. The client acknowledges the server's SYN with acknowledgement number y + 1, and enters ESTABLISHED; connect() returns. When the ACK reaches the server, the server enters ESTABLISHED too, and the connection moves to the accept queue, where the application's accept() picks it up.

A SYN carries no data, yet it uses up one sequence number, which is why the acknowledgement is x + 1 and the first byte of data is numbered x + 1. A FIN also uses one. Pure ACKs use none, so they do not need to be acknowledged themselves.

The client may put data in the same segment as its ACK, or right after it. So the client can start sending after one round trip, and the first byte reaches the server one and a half round trips after connect() was called.

This is the simulator's own run on a fresh page with a 100 ms round trip: connect, send 1,000 bytes from the client, close the client, then close the server. The client's initial sequence number was 342874228 and the server's 1754884970. Relative numbers, in brackets, count from each side's initial sequence number, which is how Wireshark shows them by default.

Each side has a sequence number to announce, and each announcement needs an acknowledgement. That is four messages: the client's SYN, the server's ACK of it, the server's SYN, and the client's ACK. The server sends its ACK and its SYN in the same segment, so four becomes three.

Could the server skip waiting for the third segment? RFC 793 explains why not: "The principal reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion." A SYN from an earlier, abandoned attempt can be delayed in the network and arrive long after the client gave up. With two segments, the server would treat it as a new connection and start sending. With three, the server waits; the client, which knows it never sent that SYN for its current connection, answers the server's SYN-ACK with an RST, and the stray connection is torn down.

Two other cases are worth knowing. If both sides send a SYN to each other at the same time, a simultaneous open, they each acknowledge the other's SYN and the connection opens with four segments. And TCP Fast Open (RFC 7413) lets a client that has connected before put data in its SYN, saving a round trip, using a cookie the server handed out earlier.

Sequence numbers do not start at zero. Each side picks a new initial sequence number (ISN) for every connection, for two reasons.

The first is old segments. A connection between the same two addresses and ports can be closed and reopened quickly. If both started at zero, a delayed segment from the previous connection could fall inside the new one's range and be accepted as data. Starting somewhere different makes this very unlikely.

The second is forgery. If an attacker can guess the server's ISN, they can complete a handshake while pretending to be another IP address, without ever seeing the server's replies, and send commands that the server trusts because of the source address. Robert Morris described the attack in 1985, and Kevin Mitnick used it against Tsutomu Shimomura's computers in December 1994. RFC 6528 (2012) describes how ISNs are chosen today: a clock that ticks every 4 microseconds, plus a keyed hash of the connection's addresses and ports, so they are hard to predict from outside.

A new connection costs one round trip before the client can send its request. The round-trip time depends on distance: a few milliseconds within a city, around 60 to 70 ms between the east and west coasts of the United States, and well over 100 ms between continents. HTTPS adds a TLS handshake on top: one more round trip with TLS 1.3, two with TLS 1.2.

The SYN and SYN-ACK also carry TCP options. Some can only be sent in these two segments, so they are fixed for the life of the connection.

• Maximum segment size (MSS). The largest amount of data each side wants in one segment. On Ethernet with a 1,500-byte MTU it is usually 1,460 bytes for IPv4. If no MSS option is sent, the default is 536 bytes.
• Window scale (RFC 7323). Multiplies the 16-bit window field so that the receive window can exceed 64 KB, which fast, long-distance connections need.
• SACK permitted (RFC 2018). Allows selective acknowledgements, which tell the sender exactly which blocks arrived so it resends only the missing ones.
• Timestamps (RFC 7323). Used to measure round-trip time and to reject very old duplicates on fast connections where sequence numbers wrap around.

Each option is used only if both sides include it in the handshake. The simulator sends none of them.

TCP closes each direction separately. When an application calls close() (or shutdown() for writing), its TCP sends a FIN, meaning "I have no more data". The other side acknowledges it, and its application sees end of file: read() returns 0. That side can keep sending until its own application closes, which sends the second FIN. This is sometimes called the four-way handshake:

1. The side that closes first sends FIN and enters FIN_WAIT_1.
2. The other side acknowledges it and enters CLOSE_WAIT; the first side, on receiving that ACK, enters FIN_WAIT_2.
3. When the second application closes, its side sends FIN and enters LAST_ACK.
4. The first side acknowledges it and enters TIME_WAIT. When that ACK arrives, the second side is CLOSED.

If the second application closes immediately, the ACK of step 2 and the FIN of step 3 often travel in one segment, giving three segments in total. If both applications close at the same moment, both send FIN, both pass through CLOSING, and both end in TIME_WAIT.

An RST (reset) ends a connection abruptly, with no acknowledgement and no TIME_WAIT. A TCP sends one when it receives a segment for a connection that does not exist, such as a SYN to a port with nothing listening, or when an application aborts, for example by closing a socket with unread data in its receive buffer or with the SO_LINGER option set to zero. The other side's application sees "connection reset by peer".

TIME_WAIT

The side that closes first does not go straight to CLOSED. It waits in TIME_WAIT for twice the maximum segment lifetime (MSL), the longest time a segment is assumed to survive in the network. RFC 793 set the MSL at two minutes, which would make TIME_WAIT four; Linux uses a fixed 60 seconds. The wait does two jobs:

• If the final ACK is lost, the other side resends its FIN. A side still in TIME_WAIT can acknowledge it again; one that had already forgotten the connection would answer with an RST.
• Delayed segments from this connection die out before a new connection can reuse the same pair of addresses and ports.

TIME_WAIT is normal. It becomes a problem only on a machine that opens and closes many short connections to the same destination, such as a proxy or a service calling a database without a connection pool. Each connection holds one local port for 60 seconds, and with about 28,000 ports in Linux's default ephemeral range, a client making more than about 470 new connections a second to one destination address and port runs out. Reusing connections is the real fix. Linux's net.ipv4.tcp_tw_reuse lets new outgoing connections reuse ports in TIME_WAIT when TCP timestamps make it safe. The older tcp_tw_recycle setting broke clients behind NAT and was removed in Linux 4.12.

A common mix-up: net.ipv4.tcp_fin_timeout does not set the length of TIME_WAIT. It limits how long an orphaned connection, one whose application has already closed it, stays in FIN_WAIT_2.

CLOSE_WAIT

CLOSE_WAIT means the peer has closed and this side's application has not yet called close(). TCP will not leave it on its own. A server with thousands of connections in CLOSE_WAIT almost always has a bug: a code path that stops reading from a connection without closing it, often after an error. The connections hold file descriptors and memory until the process exits.

RFC 9293 defines eleven states for a connection. These are the ones you see in the simulator and in ss -tan:

TCP keeps a retransmission timer for anything that needs an acknowledgement: SYNs, FINs and data. If the acknowledgement does not arrive in time, it sends the segment again and doubles the timeout. Before any round trip has been measured, RFC 6298 sets the timeout at one second. After that it is computed from measured round-trip times; Linux never goes below 200 ms.

Here is the simulator with the third segment of the handshake lost. The client thinks it is connected; the server is still in SYN_RCVD, so after one second it resends its SYN-ACK, and the client acknowledges it again.

Between the SYN-ACK and the final ACK, the server has to remember the connection: the client's address and port, both sequence numbers and the options. Linux keeps these half-open connections in a SYN queue, and completed ones in an accept queue until the application calls accept(). The accept queue's size is the backlog argument to listen(), capped by net.core.somaxconn, whose default rose from 128 to 4,096 in Linux 5.4.

A SYN flood sends SYNs as fast as possible, usually from forged source addresses, and never completes the handshake. The SYN queue fills with connections that will never finish, and real clients are turned away. The attack became widely known in 1996.

SYN cookies, devised by Daniel J. Bernstein and Eric Schenk in 1996, remove the need to store anything. When the queue is full, the server encodes the connection's details, a timestamp and a secret into the initial sequence number of its SYN-ACK and forgets the connection. A real client's ACK carries that number plus one, so the server can check it and rebuild the connection from it. The cost is that only a few options fit in the cookie. Linux turns SYN cookies on automatically when the SYN queue overflows (net.ipv4.tcp_syncookies = 1). RFC 4987 surveys this and other defences.

The handshake explains the three connection errors programs report most often.

The handshake is a standard question in networking courses and backend interviews, usually followed by one of these:

• Draw it with sequence numbers. SYN seq = x; SYN-ACK seq = y, ack = x + 1; ACK ack = y + 1. Mention that SYN and FIN each use one sequence number.
• Why not two? Old duplicate SYNs, and the need for both sides to have their own starting number acknowledged.
• Why random ISNs? Old segments from earlier connections, and attackers forging connections.
• Who ends up in TIME_WAIT, and why? The side that closes first, so it can acknowledge a resent FIN and let old segments expire.
• What happens when you type a URL? DNS lookup, then this handshake, then TLS, then the HTTP request. Know roughly how many round trips each takes.
• How do you defend against a SYN flood? SYN cookies, larger queues, and filtering upstream.