TCP Handshake Sequence Diagram

Before a browser can send an HTTPS request, TCP must open a connection. This page draws one complete TCP conversation as a UML sequence diagram: the 3-way handshake, a request and response with real sequence and acknowledgement numbers, and the 4-way close. A second diagram shows the two most common failures.

1. The Diagram

Time flows downward. Each arrow is one TCP segment with its flags and sequence numbers; the labels at the sides are the TCP states (RFC 9293) each host is in after that segment.

1. SYN. The client picks a random initial sequence number (here 1000) and moves to SYN_SENT.
2. SYN-ACK. The server, in LISTEN, replies with its own sequence number (5000) and acknowledges 1001, meaning "I expect your byte 1001 next."
3. ACK. The client acknowledges 5001. Both sides are now ESTABLISHED. That is one round trip before any data moves.
4. Data. The client sends a 100-byte request; the server acknowledges 1101 and sends a 1400-byte response, which the client acknowledges with 6401.
5. FIN from the client. The client is done sending; it enters FIN_WAIT_1, then FIN_WAIT_2 once the ACK arrives. The server enters CLOSE_WAIT and may still send.
6. FIN from the server. The server closes its half (LAST_ACK). The client's final ACK puts it into TIME_WAIT for twice the maximum segment lifetime so stray segments die out.

2. How to Read It

Hosts are participants with a dashed lifeline. Solid arrows carry new data or control flags; dashed arrows are pure acknowledgements. Dashed boxes are combined fragments that group the three phases.

3. Variant: Failure Paths

Two alt fragments show what goes wrong. If nothing listens on the port, the server answers with RST and the client gets "connection refused" at once. If a firewall silently drops the SYN, the client retransmits with a doubling timeout (1 s, 2 s, 4 s ...), which is why a blocked port looks like a hang rather than an error.

4. Pros, Cons, and When to Use

Pros

• Shows ordering and round trips, which is what latency is made of.
• Sequence and ack numbers make the reliability mechanism visible.
• Maps one-to-one onto a Wireshark or tcpdump capture.
• Side state labels connect the picture to the TCP state machine.
• Fragments put normal and failure paths on one page.

Cons

• Hides everything below TCP: routing, MTU, switches.
• Real flows have many more segments (windows, delayed ACKs, SACK).
• Does not show timing to scale; a 1 s timeout looks like a 1 ms one.
• Two-party only; middleboxes such as NAT or load balancers disappear.

When to use

• Teaching the handshake and close, or explaining TIME_WAIT.
• Debugging connection resets, hangs and half-open sockets from a capture.
• Design reviews of anything that opens many short connections.

When not to use

• Throughput or congestion questions (use a time-series plot of cwnd).
• Physical or logical network layout (use a topology diagram).

5. As Diagrams-as-Code

Mermaid sequenceDiagram (renders in GitHub, GitLab and most docs tools):

sequenceDiagram
    participant C as Client 10.0.0.5:51514
    participant S as Server 203.0.113.10:443
    rect rgb(40, 40, 10)
    C->>S: SYN seq=1000
    S->>C: SYN-ACK seq=5000 ack=1001
    C->>S: ACK seq=1001 ack=5001
    end
    C->>S: PSH,ACK seq=1001 len=100
    S-->>C: ACK ack=1101
    S->>C: PSH,ACK seq=5001 len=1400
    C-->>S: ACK ack=6401
    C->>S: FIN,ACK seq=1101
    S-->>C: ACK ack=1102
    S->>C: FIN,ACK seq=6401
    C-->>S: ACK ack=6402
    Note over C: TIME_WAIT (2 x MSL)

6. Related

• UML Sequence Diagrams — the notation reference for lifelines, messages and fragments
• UML State Machine Diagrams — the TCP states drawn as a lifecycle
• VPC Security Groups and NACLs — why a dropped SYN looks like a hang
• Diagrams-as-Code — Mermaid and PlantUML tooling
• TLS 1.3 Handshake Sequence — sibling sample in this section
• OSI and TCP/IP Layers — sibling sample in this section
• DNS Resolution Sequence — sibling sample in this section