Before TCP sends application data, it has to establish state on both ends of the connection. That setup process is the TCP three-way handshake. It happens so quickly that most users never notice it, but when websites feel slow, ports appear closed, or firewalls break applications in odd ways, the handshake is often where the story starts.

The TCP Three-Way Handshake

The three packets are:

  1. SYN from the client
  2. SYN-ACK from the server
  3. ACK from the client

After that, the connection is established and normal data transfer begins.

Step-by-Step Explanation

1. Client sends SYN

The client says, in effect, "I want to start a connection, and here is my initial sequence number."

2. Server replies with SYN-ACK

The server acknowledges the client's sequence number and sends its own starting sequence number back.

3. Client sends ACK

The client acknowledges the server's sequence number. At this point both sides agree on the basic state needed to exchange data reliably.

Why TCP Needs a Handshake

The handshake is not just ceremony. It solves real protocol problems:

  • confirms both endpoints can send and receive
  • negotiates initial sequence tracking
  • prevents delayed packets from older sessions being mistaken for current traffic
  • establishes state needed for reliable delivery

Without this setup, TCP could not provide the ordered, reliable stream behavior applications expect.

Why TCP Uses Three Steps Instead of Two

A two-step exchange would not fully prove that both sides are ready to transmit and acknowledge each other's sequence numbers. The third packet confirms the server's reply was received and that the connection state is synchronized in both directions.

That is why the handshake is "three-way" and not simply a request-response pair.

What Happens When the Handshake Fails

Handshake failures usually fall into a few recognizable patterns.

SYN sent, no reply

Possible causes:

  • destination host is down
  • firewall is silently dropping packets
  • wrong IP or port
  • routing issue in the path

Common symptoms:

  • connection timeout
  • browser spins for a while, then fails
  • telnet or client app hangs before giving up

SYN sent, RST returned

Possible causes:

  • port is closed
  • service is not listening
  • firewall is configured to reject instead of drop

Common symptom:

  • immediate "connection refused"

SYN and SYN-ACK appear, then session dies

Possible causes:

  • asymmetric routing
  • stateful firewall problem
  • broken NAT device
  • load balancer misconfiguration
  • host-based security product interfering after initial accept

What the Handshake Looks Like in Wireshark

If you capture traffic in Wireshark, a healthy TCP start usually looks like:

  • SYN
  • SYN, ACK
  • ACK

If you only see SYN packets retransmitted repeatedly, the server reply never comes back. If you see an RST, the target actively rejected the connection. That visibility is why packet captures are so useful for network troubleshooting.

Why Handshakes Matter for Performance

Every TCP connection starts with at least one round trip before data flow begins.

If latency is 100 ms:

  • the handshake costs about one round trip
  • TLS adds more negotiation after that
  • short-lived connections feel noticeably slower

This is one reason modern performance tuning cares about connection reuse, HTTP keep-alive behavior, CDNs, and protocols like HTTP/2 and HTTP/3.

TCP Handshake and TLS Are Not the Same Thing

This is a common source of confusion.

  • TCP handshake establishes the transport connection.
  • TLS handshake negotiates encryption and certificate trust on top of that connection.

So when you open an HTTPS website, the system usually performs:

  1. TCP handshake
  2. TLS handshake
  3. HTTP request and response

If a site is slow to "start loading," the delay could be in either handshake layer.

Relationship to Port Scanning

Many scanners rely on handshake behavior:

  • SYN-ACK often means the port is open
  • RST usually means closed
  • no response often means filtered or dropped

That makes the handshake central not just to networking, but also to enumeration and security testing.

SYN Flood Attacks

A SYN flood abuses the handshake by sending large numbers of SYN packets without completing the final ACK. The server allocates resources for many half-open sessions and can become overwhelmed.

Common mitigations:

  • SYN cookies
  • rate limiting
  • upstream filtering
  • firewall protections
  • load balancer tuning

Connection Teardown Is Different

Starting a session uses the three-way handshake. Closing it usually uses a different process involving FIN and ACK packets in both directions.

That teardown matters when debugging sockets stuck in TIME_WAIT or CLOSE_WAIT, but it is separate from the initial connection handshake.

Bottom Line

The TCP handshake is the three-step startup for reliable TCP communication:

  • SYN
  • SYN-ACK
  • ACK

It matters because every web request, SSH session, database connection, or API call built on TCP depends on it. If a connection times out, gets refused, or feels slow before any data moves, the handshake is one of the first places to investigate.