Trace handshakes, retries, listener backlog pressure, expiry, and SYN cookies
animation
tcp
protocols
transport
networking
Interactive TCP handshake and listener-backlog workbench showing sequence math, retries, bounded half-open state, expiry, SYN cookies, and legitimate-client outcomes.
Transport layerSequence mathIoT latency
TCP 3-Way Handshake Workbench
Build a TCP connection one segment at a time. The workbench keeps the packet movement, endpoint states, sequence and acknowledgment numbers, option negotiation, and retry diagnosis synchronized so the handshake can be understood without a lecturer beside the screen.
3 segmentsCore exchange
1 RTTClient ready
3 one-way tripsServer ready
Clean 3-way handshake
Client and server exchange SYN, SYN-ACK, and ACK. Both sequence spaces are independent, and the final ACK confirms the server ISN.
CLOSEDClient state
LISTENServer state
Clientopens socket
network pathRTT 180 ms
Serverlistening port
SYN opens the attemptThe first packet carries the client initial sequence number.
seq=x, ack not usedACK is meaningful only when the ACK flag is set.
No application bytes yetThis is transport setup. TLS or MQTT still has its own exchange later.
Workbench controls
Options shown in SYN packets
Connection attempt has started.Use Step to watch the endpoint states and acknowledgement numbers change together.
Client SYN: seq=27440, ACK flag clear.
What is being opened?
A TCP connection is a reliable byte stream between two endpoints, identified by IP addresses and ports. It is not yet HTTP, MQTT, TLS, or an application login.
Why three messages?
Each side proves that it can send and receive by exchanging sequence numbers and acknowledgments before ordinary data transfer.
Why add one?
SYN consumes one sequence number. If the client sends SYN with seq=x, the server acknowledges x+1 as the next byte it expects.
Why IoT teams care
Every retry and extra round trip costs time, radio energy, and gateway state. This is why constrained designs often compare TCP with UDP-based protocols.
Stage guide
These cards turn the state machine into a guided task flow. A normal path uses the first four stages; loss and refusal scenarios make the diagnostic stages visible.
1SYN
Client moves from CLOSED to SYN-SENT and offers its initial sequence number.
2SYN-ACK
Server moves to SYN-RECEIVED, acknowledges the client ISN, and sends its own ISN.
3ACK
Client acknowledges the server ISN. A pure ACK does not consume another byte number.
4Established
Both sides can exchange a reliable ordered byte stream after the setup completes.
5Retry path
Timeouts and retransmissions consume time and energy before the connection recovers.
6RST refusal
A closed or rejecting port can answer with RST-ACK instead of entering ESTABLISHED.
Diagnosis
The workbench keeps four views synchronized: connection state, sequence math, option negotiation, and design impact.
State is progressing
The client starts in SYN-SENT while the server is still LISTEN.
SYN consumes one number
A peer acknowledges the SYN by asking for ISN + 1 next.
Options are negotiated early
MSS, window scale, SACK permitted, and timestamps are advertised in SYN-bearing segments.
RTT drives perceived delay
Radio sleep, weak coverage, and retransmissions can make connection setup dominate short IoT exchanges.
Quick reference and deeper notes
Use the table for fast recall, then open the notes when you need exact boundaries and implementation caveats.
Handshake reference
Segment
Flags
Sequence field
Acknowledgment field
State effect
Client request
SYN
x, the client ISN
Not meaningful unless ACK flag is set
Client enters SYN-SENT
Server response
SYN, ACK
y, the server ISN
x + 1
Server enters SYN-RECEIVED
Client confirmation
ACK
x + 1 for a pure ACK
y + 1
Client is ESTABLISHED; server becomes ESTABLISHED when this arrives
Refused port
RST, ACK
Implementation dependent
Usually x + 1 when answering a SYN
Attempt fails; no TCP connection is established
Deeper material
TCP connection setup is not TLS or MQTT setup
TCP only creates a reliable ordered byte stream. TLS authentication and encryption, HTTP request semantics, and MQTT CONNECT/CONNACK are separate protocol work above that stream.
Why a pure ACK does not consume sequence space
TCP sequence numbers count bytes in the stream, with SYN and FIN consuming one sequence number each. An ACK-only segment without data does not advance the sender's next sequence number.
What simultaneous open would change
TCP also defines less common paths where both sides actively open and exchange SYNs. This workbench focuses on the common active-client and passive-server path used by most IoT clients.
What TCP Fast Open changes
TCP Fast Open can allow data in the opening exchange when a valid cookie is available, but it is an extension. The main animation keeps application data separate so the base handshake remains clear.
Guided practice
Try these checks after watching the animation. The controls above give immediate feedback when the answer depends on RTT, sequence numbers, or retry path.
Sequence check
Set client ISN to 1000 and server ISN to 9000. Step to SYN-ACK and predict the two numbers that should appear in the response.
Latency check
Raise RTT to 800 ms. Compare the clean path with lost SYN. Which event now dominates the time before data can flow?
Protocol boundary check
Select option negotiation and name which pieces belong to TCP. Then decide what TLS, HTTP, or MQTT would still need to do afterward.
Server listener: backlog under a SYN flood
Follow the server-side state that exists between SYN and final ACK. Use one-second Step actions to see expiry, capacity, retransmission, and SYN-cookie behavior in the contracted order.
tick t0
TryLoad Flood blocks legitimate, then Step through t3.ObserveAt t3, the final ACK frees 1 Backlog slot before new SYN arrivals compete for configured capacity.ExplainSYN-cookie mode defers 1 half-open state allocation until a valid ACK, but it does not remove unwanted packets or validation work.
Legitimate outcome: pending. Step the ordered fixture.
1 · Age and expire0 expired in total2 · Final ACKsProcessed by flow ID before arrivals.3 · SYN arrivals0 SYN packets still impose traffic work.
Technical boundaries. This is a bounded deterministic listener-state lesson, not a traffic generator or mitigation benchmark. It does not model kernel-specific queue split, syncache details, hash collisions, CPU saturation, bandwidth exhaustion, NAT, spoofing feasibility, adaptive timeouts, TCP Fast Open, TLS, application authentication, or vendor cookie algorithms. Cookie mode protects this teaching backlog; it does not remove network or compute load.
Primary sources
The calculations and labels in this workbench are based on current TCP specifications and option RFCs.