What is TCP three-Way Handshake: Process, Steps & Examples

Introduction

Imagine clicking a button and waiting for a response, but nothing happens because the connection has not been established. Before application data can flow over a TCP connection, two devices must complete a process known as the TCP Three-way Handshake. It uses three messages; SYN, SYN-ACK and ACK to synchronise sequence numbers and establish communication between the endpoints.

Understanding the TCP Three-way Handshake is essential for knowing how network connections begin and why connection failures occur. From understanding each step to analysing packet captures in Wireshark, this process provides valuable insights into network troubleshooting. In this blog, we will explore how the handshake works, examine a practical example, and learn how to identify common connection problems.

What Is the TCP Three-Way Handshake?

The TCP three-way handshake is the process used to establish a TCP connection between two devices before they exchange application data. It involves three messages: SYN, SYN-ACK and ACK. During this exchange, both devices synchronise their initial sequence numbers and acknowledge each other’s messages to prepare for reliable communication.

The process begins when the client sends a SYN message to the server. The server responds with a SYN-ACK message, acknowledging the client’s request and sharing its own initial sequence number. Finally, the client sends an ACK message to confirm receipt of the server’s response, completing the connection setup and allowing data transfer to begin.

A Practical Example: A Warehouse Scanner Connects to an Inventory Server

Imagine a warehouse employee scanning the final item in a shipment. The scanner needs a new TCP connection to an inventory service before it can submit the barcode.

For this illustrative example:

1. Scanner: 192.168.20.45, using temporary source port 53014

1. Inventory Server: 192.168.20.10, listening on port 8080

1. Scanner’s Initial Sequence Number: 4200

1. Server’s Initial Sequence Number: 9100

The connection begins like this:

Step	Direction	Flags	Sequence number	Acknowledgment number
1	Scanner → Server	SYN	4200	Not meaningful because ACK is unset
2	Server → Scanner	SYN-ACK	9100	4201
3	Scanner → Server	ACK	4201	9101

These sequence numbers are illustrative. In a real TCP connection, each endpoint selects its own initial sequence number. The acknowledgment numbers increase by one because each SYN consumes one position in TCP’s sequence space, even though it carries no application data.

Once this exchange succeeds, the scanner can send the barcode request. If it keeps the connection open, later scans can use that same connection without repeating the handshake. This sequence-number relationship is consistent with standard TCP behaviour.

Want to strengthen your networking fundamentals? Explore our CCNA Training Course to learn networking protocols, routing, switching, and practical troubleshooting.

How Does the TCP Handshake Work?

Each message serves a different purpose. The second message combines two jobs, which is why the normal process needs three messages rather than four.

Step 1: The Client Sends SYN

The client initiates the connection by sending a segment with the SYN, or synchronize, flag set. It includes the client’s initial sequence number. In our example, the scanner announces 4200. The client then enters the SYN-SENT state while waiting for a response.

Step 2: The Server Returns SYN-ACK

A listening server responds with both SYN and ACK flags set.

This message:

1. Acknowledges the client’s SYN.

1. Announces the server’s own initial sequence number.

Our inventory server sends sequence number 9100 and acknowledgment number 4201. It enters SYN-RECEIVED, waiting for the client’s confirmation.

Step 3: The Client Sends ACK

The client acknowledges the server’s SYN by sending ACK 9101. After accepting the SYN-ACK, the client enters the ESTABLISHED state. The server enters the ESTABLISHED state when it receives the valid final ACK. The ordinary TCP connection setup is now complete.

Understanding Sequence and Acknowledgment Numbers

The flags describe the message’s purpose. The numbers tell TCP where each side is in the conversation.

Sequence Numbers Track Bytes

TCP sequence numbers track positions in a byte stream, rather than simply counting packets.

Continuing our scanner example, suppose its first application message contains 120 bytes, beginning at sequence number 4201. Those bytes occupy positions 4201 through 4320.

Acknowledgment Numbers Identify What Comes Next

If the server receives all 120 bytes in order, its acknowledgment is 4321: the next byte it expects from the scanner. This distinction makes packet captures easier to understand. An acknowledgment number does not mean that a particular packet number was received; it identifies the next sequence position expected by the receiver.

Why Does TCP Need Three Steps?

After the first SYN, the server knows the client’s starting number. After SYN-ACK, the client knows the server’s starting number.

The final ACK confirms that the client has received the server’s SYN-ACK and acknowledges the server’s initial sequence number. This allows the server to complete the normal TCP connection setup.

For troubleshooting, that third message is especially useful: it separates a server that replied from a connection whose setup actually completed.

How to Analyze a TCP Three-Way Handshake in Wireshark

Reading the exchange in a capture makes the process much more concrete. Start capturing on the relevant network interface before opening a new connection. For our warehouse example, use this display filter:

ip.addr == 192.168.20.10 && tcp.port == 8080

Find the SYN, select that connection and use its stream index to narrow the view. For example:

tcp.stream eq 4

Replace 4 with the stream number shown in your capture.

Useful display filters include:

What you want to find	Wireshark display filter
Initial SYN messages	tcp.flags.syn == 1 && tcp.flags.ack == 0
SYN-ACK responses	tcp.flags.syn == 1 && tcp.flags.ack == 1
Connection resets	tcp.flags.reset == 1

An ACK-only filter can also match acknowledgments sent during data transfer. To identify the final handshake ACK, examine its position and sequence and acknowledgment numbers within the selected TCP stream.

Why Does Wireshark Show Sequence Number Zero?

Wireshark normally displays relative sequence numbers to simplify reading. Instead of showing the scanner’s actual initial sequence number of 4200, Wireshark may display 0. The next sequence position is then displayed as 1.

This is a display convention, not evidence that the device selected zero as its actual initial sequence number.

What Happens When the TCP Handshake Fails?

A connection timeout indicates a problem, while a packet capture can help identify where the handshake stops progressing. The following patterns are diagnostic clues, not proof of a single cause:

Capture pattern	Possible explanation	What to check
Repeated SYN, no SYN-ACK	Dropped traffic, unreachable server or missing return traffic	Routing, firewall rules and captures at both endpoints
Server receives SYN but sends no SYN-ACK	Local filtering or a problem with the listening service	Service status, listening port and host firewall
Server sends SYN-ACK, but client never receives it	Return-path filtering or routing problem	Server egress and intermediate network devices
SYN receives RST	Connection was actively refused	Destination port, service listener and rejecting devices

Endpoint listeners, local firewalls and network infrastructure are important areas to investigate when SYN or SYN-ACK traffic fails to progress.

Lost setup messages can trigger retransmissions. Retry counts and timing depend on the operating system and configuration, so avoid assuming every device follows the same timeout schedule.

TCP Handshake vs. TLS Handshake

A successful TCP handshake establishes the transport connection. It does not encrypt the traffic or verify a website’s identity. For HTTPS over TCP, TLS performs a separate handshake to establish security, including authentication and encryption keys.

A connection can therefore complete TCP setup and still fail during TLS negotiation. Also, not every web connection uses TCP. HTTP/3 uses QUIC, a transport built on UDP, so its setup does not follow the TCP SYN, SYN-ACK, ACK exchange.

Conclusion

The TCP Three-way Handshake is an essential process for establishing reliable communication between two devices. By exchanging SYN, SYN-ACK and ACK messages, both endpoints synchronise sequence numbers and prepare for data transfer. Understanding each step helps networking professionals interpret packet captures, identify connection failures and troubleshoot communication issues more effectively. With tools like Wireshark, you can analyse handshake messages and pinpoint potential problems in the network.

Frequently Asked Questions

Q1. What is the Purpose of the TCP Three Way Handshake in Networking?

The TCP three-way handshake establishes a connection between two devices before data transfer begins. It uses SYN, SYN-ACK, and ACK messages to synchronise their initial sequence numbers and confirm that both endpoints are ready to communicate.

Q2. Why Does TCP Use Three Messages Instead of Two?

TCP uses three messages so that both endpoints can exchange their initial sequence numbers and acknowledge the other endpoint’s SYN. The final ACK confirms receipt of the server’s SYN-ACK and allows the server to complete the normal connection setup.

Q3. Does UDP Use a Three Way Handshake?

No. UDP does not use a built-in three-way handshake to establish connections. However, applications using UDP can implement their own connection setup, acknowledgments or reliability mechanisms when required.

Q4. What Happens If the Final ACK is Lost?

If the final ACK is lost, the server may retransmit its SYN-ACK while waiting for confirmation. If the client receives the retransmitted SYN-ACK, it can send another ACK. The outcome depends on whether the retransmitted messages arrive before the connection attempt times out.