TCP Connection Setup and Teardown
TCP promises that bytes arrive reliably and in order, but it can only keep that promise if both hosts first agree that they are talking to each other and agree on where their byte counting begins. The network between them offers no such guarantee. Packets can be lost, duplicated, delayed, or reordered, and a packet from an old conversation can arrive long after that conversation ended. Two questions follow. How do two hosts create shared state across a medium where any message might vanish? And how do they end that state without cutting off data still in transit? The three-way handshake answers the first question, and the four-segment close answers the second.
Why Connections Need Agreed State
A TCP connection is not a physical circuit. It is a record kept in the memory of each host, holding the local and remote port numbers, the addresses, the sequence-number counters, and the buffers for data moving in each direction. The four values of a source address, source port, destination address, and destination port identify the record, and each host must maintain its own copy. Setup is the process of creating these two matching records.
Setup also synchronises sequence numbers. Each side picks an initial sequence number (ISN) and must tell the other, because every later byte and acknowledgment is counted relative to it. The mechanics of sequence numbers belong to a sibling article, but the key point here is that setup is where each side learns the other's starting point. Without that exchange, neither side could interpret the other's acknowledgments.
The diagram below shows the state of the two hosts before and after setup.
spec: static diagram, two panels side by side. Left panel titled "Before setup": two host boxes labelled Client (port 52817) and Server (port 443), each empty, with the text "No connection record". Right panel titled "After setup": the same two hosts, each holding a connection record with fields Local port, Remote port, Initial sequence number sent, Initial sequence number received, and Status ESTABLISHED. Client record shows Local 52817, Remote 443. Server record shows Local 443, Remote 52817. Arrows between the panels labelled "Three-way handshake".
The Three-Way Handshake
The handshake exchanges three segments, each carrying a flag in the TCP header. The client sends a SYN segment, which sets the SYN flag and carries the client's ISN, call it $x$. The server replies with a SYN-ACK segment, which sets both SYN and ACK, carries the server's own ISN $y$, and acknowledges the client's SYN with acknowledgment number $x+1$. The client finishes with an ACK segment carrying acknowledgment number $y+1$. The acknowledgment numbers are one greater than the ISNs because a SYN consumes one sequence number, even though it carries no data.
Three segments are needed rather than two because each side must have its own ISN acknowledged. After the server's SYN-ACK, the server knows the client received its ISN only when the client's ACK arrives. A two-message exchange would leave the server guessing whether its SYN was ever received. The third segment is also the first one the client may use to send data, so the handshake costs one round trip before data can flow.
The timeline below shows the three segments exchanged between the two hosts.
spec: static diagram, timeline with two vertical lifelines labelled Client (left) and Server (right), time flowing downward. Arrow 1 from Client to Server labelled "SYN, seq = x". Arrow 2 from Server to Client labelled "SYN-ACK, seq = y, ack = x + 1". Arrow 3 from Client to Server labelled "ACK, seq = x + 1, ack = y + 1". Beside arrow 3, a note reads "Data may follow". Below the timeline, a caption reads "Three segments; one round trip before data".
States on Each Side During Setup
Each host runs a state machine that records where it is in the protocol. The server begins in LISTEN, having called listen on its well-known port and waiting for incoming SYNs. This is called a passive open. The client begins in CLOSED and enters SYN-SENT when it sends its SYN, which is an active open. When the server receives the SYN, it moves to SYN-RECEIVED while it waits for the final ACK. Both sides enter ESTABLISHED once the handshake completes, and from that point data can move in both directions.
The SYN-RECEIVED state matters for reliability and resource use. The server holds a partly built connection record for each arriving SYN, even though the client may never finish. Such records are called half-open connections. A large number of half-open connections can exhaust a server's memory, which is the basis of the SYN flood attack. If a SYN or SYN-ACK is lost, the sender retransmits it on a timer, a mechanism covered in the sibling article on retransmission timers.
The diagram below lists the transitions for each host.
spec: static diagram, state transition diagram with two parallel columns. Left column titled "Client (active open)": CLOSED, then arrow labelled "send SYN" to SYN-SENT, then arrow labelled "receive SYN-ACK, send ACK" to ESTABLISHED. Right column titled "Server (passive open)": CLOSED, then arrow labelled "listen" to LISTEN, then arrow labelled "receive SYN, send SYN-ACK" to SYN-RECEIVED, then arrow labelled "receive ACK" to ESTABLISHED. Each state drawn as a rounded box. Mark SYN-RECEIVED with the note "half-open".
Closing a Connection with Four Segments
TCP connections are full duplex, meaning data flows independently in each direction, so each direction is closed separately with a FIN segment. Suppose the active closer, call it A, has no more data to send. It sends a FIN and moves to FIN-WAIT-1. The peer, B, acknowledges the FIN, and A moves to FIN-WAIT-2. At this point A's sending direction is closed, but B may still send data. This is a half-closed connection, and it is valid.
When B's application has also finished, B sends its own FIN, which it may hold in CLOSE-WAIT until the application calls close. B then enters LAST-ACK, and A acknowledges B's FIN. The sequence is therefore four segments: FIN from A, ACK from B, FIN from B, and ACK from A. The two middle segments cannot always be merged, because the ACK for A's FIN is sent immediately while B's FIN depends on when B's application decides to close.
The timeline below shows the four segments and the states each side passes through.
spec: static diagram, timeline with two vertical lifelines labelled Active closer A (left) and Passive closer B (right), time flowing downward. Arrow 1 from A to B labelled "FIN". Arrow 2 from B to A labelled "ACK". Arrow 3 from B to A labelled "FIN" after a gap labelled "B application closes". Arrow 4 from A to B labelled "ACK". Beside A's lifeline, state labels in order: ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT. Beside B's lifeline, state labels in order: ESTABLISHED, CLOSE-WAIT, LAST-ACK, CLOSED. Caption: "Four segments; each direction closed separately".
Why the Active Closer Waits in TIME-WAIT
After sending its final ACK, the active closer does not immediately release its connection record. It enters TIME-WAIT and stays there for twice the maximum segment lifetime (2MSL), a period long enough for packets from that connection to expire in the network. The reason is that the final ACK may be lost. If it is, B retransmits its FIN, and A must still be present to send the ACK again. Were A already closed, it would reply to B's FIN with a reset, and B would see an error instead of a clean close.
The wait also protects against old segments. If A reused the same four-tuple immediately, a delayed segment from the previous connection could be accepted as belonging to the new one. Waiting ensures any such stray segments have been discarded by the network before the same ports are used again. The passive closer does not need this wait, because it reaches CLOSED as soon as it receives the final ACK. The party that closes first is therefore the one that holds the record in TIME-WAIT, which is why busy servers that initiate closes accumulate many such records.
The diagram below shows the lost-ACK case that makes the wait necessary.
spec: static diagram, timeline with two vertical lifelines labelled A (active closer, left) and B (passive closer, right). Step 1 arrow A to B labelled "FIN". Step 2 arrow B to A labelled "ACK". Step 3 arrow B to A labelled "FIN". Step 4 arrow A to B labelled "ACK", drawn with a red cross through it and the label "lost". Step 5 arrow B to A labelled "FIN retransmitted" after a timeout gap. Step 6 arrow A to B labelled "ACK again", shown as successful. A's lifeline carries a bracket labelled "TIME-WAIT" spanning steps 4 to 6. B's lifeline shows state LAST-ACK until step 6 and then CLOSED.
AI-generated study article from SophistAI. Sign up free to study it with an AI tutor.