Helpful first: Networks in one request: DNS, TCP, TLS, and HTTP
Key points
- SYN, SYN-ACK, and ACK are the three handshake packets. The server waits for the third packet before ESTABLISHED. Only that packet proves that the client heard the initial sequence number of the server.
- Explain why a server stays in SYN_RCVD after sending SYN-ACK and how spoofed SYN floods exploit that waiting state
Why three packets are required to synchronize two directions
When a Meridian ground-station client opens a TCP socket to telemetry. on port 443, both endpoints need a reliable way to number every byte they send and acknowledge every byte they receive. Because TCP is full-duplex, the client and the server each choose their own random Initial Sequence Number (ISN).
Packet 1 (SYN, say seq=100) announces the client’s ISN, moving the client to SYN_. Packet 2 (SYN-, seq=500, ack=101) proves the server heard the client’s ISN and announces the server’s own ISN, placing the server in SYN_. However, at that moment the server still has no proof that the client is real or heard seq=500. Only when Packet 3 (ACK, seq=101, ack=501) arrives at the server are both sequence numbers confirmed, moving the server into ESTABLISHED.
WATCH THE HANDSHAKE
Three packets. Then connected.
Watch who sends each packet and why the server waits for the final ACK.
The client is CLOSED; the server is listening. No packet has crossed.
More about this step
Client is CLOSED and Server is LISTEN. No connection exists yet. Only the segment carries sequence and acknowledgment values in this picture.
Chapter 1 of 5
Successful handshake only: no loss, retries, or TCP options. Starting numbers are illustrative. TCP does not encrypt data or authenticate a person.
Read the whole path as a list
Nothing plays on its own. Watch all runs one overview. Replay this step stops on the selected chapter; Pause and Resume keep your place. Scrub or choose a chapter to inspect. Opening detail, leaving the picture, or hiding the tab pauses playback. Reduced motion shows still chapters with no travel.
- The client is CLOSED; the server is listening. No packet has crossed.Client is CLOSED and Server is LISTEN. No connection exists yet. Only the segment carries sequence and acknowledgment values in this picture.
- Client sends SYN with starting sequence 100. Server waits until it arrives.SYN seq=100 travels to Server. Client is SYN_SENT. On receipt, Server enters SYN_RCVD and expects 101; its starting number is shown in the next step.
- Server replies with SYN-ACK: seq=500, ack=101 means it expects 101 next.SYN-ACK seq=500 ack=101 acknowledges SYN 100. Client stays SYN_SENT in transit, then enters ESTABLISHED and prepares ACK seq=101 ack=501 on receipt.
- Client sends ACK, ack=501. Server becomes ESTABLISHED only after receipt.ACK seq=101 ack=501 acknowledges Server’s SYN 500. Client stays ESTABLISHED. Server stays SYN_RCVD in transit and becomes ESTABLISHED on receipt.
- Both ends are ESTABLISHED. Application data can now use the connection.The wire is empty. Both ends are ESTABLISHED. Their next-byte numbers match: Client sends 101 and expects 501; Server sends 501 and expects 101.
Show as a table
SYN carries the client’s starting number, 100. SYN-ACK carries 500 and asks for 101 next, acknowledging SYN 100. ACK asks for 501 next, acknowledging SYN 500. SYN occupies one sequence number; an empty ACK does not. Receivers change state after arrival. This establishes TCP without encryption or proof of a person’s identity.
| Step | Packet | Client state | Server state |
|---|---|---|---|
| 1. Closed | Nothing | CLOSED | LISTEN |
| 2. SYN | Client to Server: SYN seq=100 | SYN_SENT | LISTEN in transit; SYN_RCVD after receipt |
| 3. SYN-ACK | Server to Client: SYN-ACK seq=500 ack=101 | SYN_SENT in transit; ESTABLISHED after receipt | SYN_RCVD |
| 4. ACK | Client to Server: ACK seq=101 ack=501 | ESTABLISHED | SYN_RCVD in transit; ESTABLISHED after receipt |
| 5. Established | Nothing; data can flow | ESTABLISHED | ESTABLISHED |
Scene checked 2026-09-29.
Check the picture
A packet capture on Meridian’s gateway shows SYN seq=100, then SYN-ACK seq=500 ack=101, then ACK seq=101 ack=501. Why does the server wait for the third packet before marking the connection ESTABLISHED?
What ESTABLISHED proves and how SYN floods attack SYN_RCVD
Reaching ESTABLISHED proves two things: both IP endpoints can send and receive packets to each other right now, and both kernels agree on the starting byte counters for each direction. That prevents blind off-path spoofing, where an attacker forges a source IP address without being able to see the server’s SYN- sequence number.
Notice the asymmetry between Packet 2 and Packet 3: while the server is in SYN_, it is waiting for a reply that might never come. In a TCP SYN flood attack, a botnet sends millions of SYN packets with spoofed source IP addresses. If the server allocates a heavy memory structure in its backlog queue for every SYN_ socket, the queue fills up and legitimate clients are dropped. Modern kernels defend against this with SYN cookies, encoding the connection state cryptographically into the server’s SYN- sequence number (500) and allocating zero memory until the valid ack=501 returns.
| Handshake Step | Packet Flags & Counters | Endpoint State | Security / Operational Meaning |
|---|---|---|---|
| 1. Client -> Server | SYN (seq=x) | Client enters SYN_ | Unverified connection request; source IP could still be spoofed |
| 2. Server -> Client | SYN- (seq=y, ack=x+1) | Server enters SYN_ | Half-open state; vulnerable to backlog exhaustion unless SYN cookies are enabled |
| 3. Client -> Server | ACK (seq=x+1, ack=y+1) | Both enter ESTABLISHED | Two-way IP reachability proven; ready for TLS ClientHello |
A reliable road is not an encrypted or authorized road
Once TCP reaches ESTABLISHED, the operating system hands a clean byte stream to the next layer up. By itself, TCP does not encrypt a single bit and does not verify who owns the server or who sits at the keyboard. Anyone on the local network path who can observe seq=100 and seq=500 can read cleartext payloads or inject a forged RST packet to tear down the socket. Protecting the contents of that road is the job of TLS.
CHECK YOUR JUDGMENT