Interactive TCP 3-way handshake workbench showing connection state transitions, sequence and acknowledgment number math, option negotiation, retry behavior, reset refusal, and IoT latency trade-offs.
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.
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.
Primary sources
The calculations and labels in this workbench are based on current TCP specifications and option RFCs.