TCP 3-Way Handshake (SYN, SYN-ACK,ACK)

By : Bryce Leo Bryce Leo
Hours Updated

⚡ Smart Summary

TCP 3-Way Handshake is the connection-setup ritual that every TCP session begins with. A client and server exchange SYN, SYN-ACK, and ACK packets to synchronise sequence numbers and confirm both sides are ready before a single byte of application data is sent.

  • 📨 Know the four message types: SYN initiates, ACK confirms, SYN-ACK combines both, and FIN terminates a TCP connection.
  • 🔁 Follow the three steps: client SYN → server SYN-ACK → client ACK; the session is established only after the third packet arrives.
  • 🔢 Sequence numbers matter: each side picks an initial sequence number; the other side acknowledges it by adding one, which keeps the byte stream ordered.
  • 🚪 Plan for teardown: after data transfer, TCP closes the connection with FIN/ACK pairs to release the socket on both ends.
  • 🤖 Use AI for packet analysis: AI assistants explain Wireshark captures, flag missing ACKs, and highlight SYN floods or half-open connections.
Read More

TCP 3-Way Handshake

What is the TCP Three-Way Handshake?

The TCP Three-Way Handshake is the procedure a client and a server use on a TCP/IP network to set up a reliable connection before any application data is exchanged. As the name implies, it consists of three steps in which both sides exchange synchronisation (SYN) and acknowledgment (ACK) packets and agree on the initial sequence numbers they will use.

The handshake is designed so that both endpoints can initiate, negotiate, and tear down TCP sockets symmetrically. Once the handshake completes, the connection is full-duplex — both sides can send and receive in parallel until either issues a FIN to close the session.

TCP Message Types

Four control flags appear repeatedly during the handshake and teardown.

Message Description
SYN Initiates a connection and synchronises sequence numbers between devices.
ACK Confirms to the other side that the previous segment was received.
SYN-ACK A combined message — a SYN from the local device plus an ACK of the peer’s earlier SYN.
FIN Used to terminate a connection gracefully.

TCP Three-Way Handshake Process

TCP traffic always begins with a three-way handshake. The client initiates the conversation by requesting a session with the server.

TCP 3-Way Handshake Diagram

3-way handshake diagram.

  • Step 1 — SYN: The client sends a segment with the SYN flag set. It tells the server “I want to start communicating” and proposes an initial sequence number.
  • Step 2 — SYN-ACK: The server responds with a segment in which both SYN and ACK flags are set. The ACK acknowledges the client’s SYN, and the SYN proposes the server’s own initial sequence number.
  • Step 3 — ACK: The client acknowledges the server’s SYN-ACK with a final ACK. The connection is now established, and both sides can start transmitting application data.

Real-World Example

TCP 3-Way Handshake Real-world Example

Here is a worked example with concrete sequence numbers.

  • Host X starts the connection by sending a TCP SYN packet to the server. The packet carries a random initial sequence number — for example, 4321 — that marks the beginning of the byte stream Host X will send.
  • The server receives the SYN and replies with a SYN-ACK. The ACK number is Host X’s sequence number incremented by 1 (4322), and the SYN proposes the server’s own initial sequence number.
  • Host X replies with a final ACK whose acknowledgment number is the server’s sequence number incremented by 1.

Once data exchange completes, TCP tears down the connection with a four-way FIN/ACK sequence so both endpoints can release the socket cleanly.

RELATED ARTICLES

Why TCP Needs a Three-Way Handshake

The handshake is not just a formality — it solves three concrete problems that come with reliable byte-stream transport:

  • Sequence-number synchronisation: both peers learn the initial sequence number of the other side, which is what TCP uses to detect lost or out-of-order segments.
  • Connection-state agreement: the third ACK confirms that the server’s SYN-ACK arrived, so neither side starts sending data until both are in the ESTABLISHED state.
  • Duplicate-packet protection: random initial sequence numbers and timed handshake states stop stale segments from a previous session being accepted by mistake.

Common Issues with the TCP Handshake

The handshake is robust but it does break down in identifiable ways. Network engineers usually see one of the following:

  • SYN flood attacks: a malicious client sends thousands of SYNs without replying to SYN-ACKs, exhausting the server’s connection table. SYN cookies are the standard defence.
  • Half-open connections: when the third ACK is lost the connection lingers half-open and is eventually cleaned up by a timeout.
  • Firewall or NAT mid-flight drops: stateful middleboxes that lose state can drop SYN-ACK packets and leave the client retrying.
  • RST resets: if the server is not listening on the requested port it answers a SYN with an RST, which closes the attempt immediately.

FAQs

Two messages cannot prove that both sides agreed on initial sequence numbers and are ready to send. The third ACK confirms the server’s SYN-ACK arrived, ensuring both endpoints reach the ESTABLISHED state before data flows.

SYN is a single flag that opens the conversation and proposes an initial sequence number. SYN-ACK combines a SYN with an acknowledgment of the peer’s earlier SYN, completing the synchronisation in one packet.

A SYN flood overwhelms a server by sending many SYN packets without completing the handshake. Half-open connections fill the backlog queue and block legitimate users. SYN cookies are the standard mitigation.

TCP closes a connection with a four-way handshake of FIN and ACK exchanges. Each direction is closed independently, which lets one side finish sending data even after the other side has closed its half.

The initial sequence number is a randomly chosen 32-bit value each endpoint picks for its own byte stream. It seeds the counter used to detect missing or duplicate segments and to defend against spoofed packets.

No. UDP is connectionless and sends datagrams without any handshake. That makes it faster and lighter than TCP, but applications must handle reliability, ordering, and congestion control themselves.

AI assistants annotate packet captures, classify retransmits and RSTs, and detect SYN floods. They translate Wireshark filters into plain English and recommend the next diagnostic step for connectivity issues.

Yes. AI coding assistants turn a plain-English request into a Python Scapy or netcat script that triggers and inspects the three-way handshake, then explain each line so engineers can review before running it.

Summarize this post with: