skip to content

In TCP, what does each segment of the three-way handshake (SYN, SYN-ACK, ACK) carry, and why are three segments needed?

level: juniorimportance: must knowfreq 82%

answer

  1. two directions, two starting numbers
  2. each side's ISN must be acknowledged
  3. a SYN occupies one sequence number
  4. delayed duplicate SYNs from the network

basics

~20 s

The SYN carries the client's initial sequence number, the SYN-ACK carries the server's and acknowledges the client's, and the final ACK acknowledges the server's. Three segments let each side confirm the other's starting number and reject stale duplicate SYNs.

solid answer

~50 s

TCP numbers every byte in each direction, so both ends must agree on two starting points before data flows. The client sends a `SYN` carrying its initial sequence number *x*. The server answers with one segment that has both `SYN` and `ACK` set: its own initial sequence number *y* and an acknowledgment number of *x+1*, because a SYN occupies one sequence number. The client replies with an `ACK` of *y+1*; a pure ACK occupies no sequence number, so the client's first data byte is also numbered *x+1*. Logically there are four steps (each side sends its number and has it acknowledged), and the server's two travel in one segment. RFC 9293 names the principal reason for the handshake: stopping old duplicate connection requests from causing confusion. Because the server waits for that third segment, the client can veto, with a `RST`, a SYN-ACK that answers a SYN it did not send in this attempt.

go deeper

for a junior

Recall the three segments by their flags and what each carries: the client's ISN, the server's ISN plus an acknowledgment, and the final acknowledgment. Mention that a SYN occupies one sequence number.

for a middle

Explain the four logical steps folded into three segments, the x+1 and y+1 arithmetic, and why a pure ACK occupies no sequence number while a SYN does.

for a senior

Tie the third segment to its purpose: letting the client reset a SYN-ACK that answers a delayed duplicate SYN, and confirming the server's ISN. Connect the extra round trip to why short connections are costly.

for a principal

Discuss the trade the base protocol makes, one extra round trip in exchange for safety against stale duplicates, and why shortcuts that put data in the SYN, such as Fast Open, remained Experimental.

## Why TCP needs a handshake at all TCP gives an application a reliable, ordered **byte stream** in each direction. It does that by giving every byte a **sequence number** and having the receiver acknowledge the next number it expects. Each direction has its own numbering, and neither starts at zero: each side chooses its own **initial sequence number (ISN)**. Before any data can be acknowledged, each side must learn the other's ISN and be sure the other has learned its own. RFC 9293, the current TCP specification (it obsoleted RFC 793 in 2022), calls this *synchronizing* the connection. The control bit that carries an ISN is `SYN` (synchronize), and segments with it set are called SYNs. ## Four logical steps, sent as three segments RFC 9293 section 3.4 states the requirement as four steps between peers A and B: 1. A to B: `SYN`, my sequence number is X. 2. B to A: `ACK`, your sequence number is X. 3. B to A: `SYN`, my sequence number is Y. 4. A to B: `ACK`, your sequence number is Y. Steps 2 and 3 can travel in one segment, which is why the procedure is called the **three-way handshake**. ## What each segment carries | Segment | Flags | Sequence number | Acknowledgment number | Purpose | |---|---|---|---|---| | 1, client to server | `SYN` | x (client ISN) | not used | offer the client's ISN | | 2, server to client | `SYN`, `ACK` | y (server ISN) | x+1 | offer the server's ISN, confirm the client's | | 3, client to server | `ACK` | x+1 | y+1 | confirm the server's ISN | Details worth being exact about: - **A SYN occupies one sequence number**, and so does a FIN. That is why the acknowledgment of a SYN numbered x is x+1: an acknowledgment number names the next sequence number the receiver expects. - **A pure ACK occupies none.** In RFC 9293's Figure 6 the client's ACK and its first data segment both carry sequence number 101 after an ISN of 100. If ACKs consumed sequence numbers, TCP would have to acknowledge acknowledgments. - Sequence numbers count **bytes**, not segments. - The SYN segments also carry the options each side offers for the connection, such as the maximum segment size; what those options negotiate is the segment-header topic, not the handshake's. ## Why two segments would not be enough Suppose the server treated the connection as open the moment it sent its SYN-ACK. Two problems follow. - **The server's ISN would never be confirmed.** The server would not know whether the client had received its starting number, so it could not know whether its own bytes would be numbered correctly at the other end. - **Delayed duplicate SYNs would open connections.** Networks can hold a segment and deliver it late. RFC 9293 says the *principal reason* for the three-way handshake is to prevent old duplicate connection initiations from causing confusion. With a third segment required, a stale SYN is harmless. RFC 9293 Figure 8 traces it: 1. An old duplicate SYN reaches the server, which moves from `LISTEN` to `SYN-RECEIVED` and sends a SYN-ACK acknowledging the old number. 2. The client, in `SYN-SENT`, sees an acknowledgment for something it did not send in this attempt and answers with a `RST`. 3. The server, having reached `SYN-RECEIVED` from `LISTEN`, returns to `LISTEN`. 4. The client's real SYN arrives and the handshake proceeds normally. Requiring the third segment is therefore not courtesy. It gives the client a veto over a SYN-ACK that does not match a request it really made, and gives the server proof that its ISN arrived. ## Data on the handshake RFC 9293 permits data in a SYN, but the receiver must hold that data and not deliver it to the application until the connection reaches `ESTABLISHED`. So in the base protocol the client gains nothing by it, and normally sends its first data with or just after the third segment. TCP Fast Open (RFC 7413) uses a cookie from an earlier connection so that a server can deliver SYN data before the handshake completes, saving up to one round trip; RFC 7413 is an **Experimental** RFC, not part of the base specification. ## Summary - Two ISNs, one per direction, each chosen by its sender. - A SYN says "here is my ISN"; an acknowledgment of ISN+1 says "I have yours". - Three segments, because the server's SYN and its acknowledgment of the client's SYN share one segment. - The final ACK confirms the server's ISN and lets delayed duplicate SYNs be rejected with a reset.

  • Why is the acknowledgment number in the SYN-ACK the client's ISN plus one rather than the ISN itself?
    Because the SYN flag occupies one sequence number, and an acknowledgment number names the next sequence number the receiver expects. After a SYN numbered x, the next expected number is x+1. FIN follows the same rule. A pure ACK occupies no sequence number, so the client's third segment and its first data byte both carry x+1.
  • What does a TCP client in SYN-SENT do when a SYN-ACK arrives that acknowledges a sequence number it never sent?
    RFC 9293 treats an acknowledgment of something not yet sent as unacceptable in SYN-SENT, so the client sends a RST whose sequence number is taken from that segment's acknowledgment field, and stays in SYN-SENT. A server that reached SYN-RECEIVED from LISTEN returns to LISTEN on that reset. This is how a delayed duplicate SYN is kept from opening a connection.
  • Can a TCP client put application data in its SYN?
    RFC 9293 allows it, but the receiver must buffer the data and not deliver it until the connection is ESTABLISHED, so on its own it saves nothing. TCP Fast Open (RFC 7413, Experimental) uses a cookie obtained on an earlier connection so the server can deliver SYN data immediately, saving up to one round trip.

Two radio operators on a noisy channel: one says "my count starts at 100", the other replies "got 100, mine starts at 300", and the first answers "got 300". Until each has heard its own starting count read back, neither can trust the other to follow its numbering.

saying these in an interview costs you the question

  • The SYN-ACK acknowledges the client's ISN itself, not the ISN plus one.
  • The final ACK consumes a sequence number, so data starts at the ISN plus two.
  • Both directions share one sequence number space chosen by the client.
  • The final ACK is optional and only speeds up the first data exchange.
  • Sequence numbers count segments, so each segment adds exactly one.