The TCP Three-Way Handshake Explained for GCSE Computer Science

Why does TCP need a handshake at all?

TCP (Transmission Control Protocol) guarantees reliable, ordered delivery of data. To achieve this, both the client and the server must:

• Confirm the other end is alive and reachable.
• Agree on the starting sequence numbers — counters that track which bytes have been sent and received, allowing lost packets to be detected and retransmitted.
• Allocate buffer space for incoming data.

Without this setup, a server might send data to a client that is no longer listening, or the client might receive packets out of order with no way to reassemble them correctly.

What happens in each of the three steps?

The handshake is initiated by the client (the device requesting the connection) and responded to by the server (the device accepting it).

After step 3, the connection is established and application data (an HTTP request, an email, a file transfer) can begin flowing.

What are SYN, ACK, and sequence numbers?

SYN stands for synchronise. It signals the desire to begin a connection and carries an Initial Sequence Number (ISN) — a randomly chosen starting value (not always 0, to prevent security attacks). The random start makes it harder for an attacker to forge packets by guessing sequence numbers.

ACK stands for acknowledge. Every packet after the first SYN includes an acknowledgement number equal to the other side's sequence number plus one, meaning "I have received everything up to byte n; please send byte n+1 next."

Think of it like starting a phone call. You say "Hello, can you hear me?" (SYN). The other person replies "Yes, I can hear you — can you hear me?" (SYN-ACK). You say "Yes!" (ACK). Only then does the actual conversation begin.

How does the handshake relate to TCP's reliable delivery?

The sequence and acknowledgement numbers established during the handshake are used throughout the connection:

1. The sender numbers every byte it transmits.
2. The receiver sends ACKs confirming receipt.
3. If an ACK does not arrive within a timeout period, the sender retransmits the unacknowledged data.

This process is called ARQ (Automatic Repeat reQuest). The handshake sets up the counters that make ARQ possible.

What is the difference between TCP and UDP in terms of connection setup?

UDP sends packets immediately without checking whether the recipient is ready. This makes it faster but unreliable. For a live video call, a dropped frame is acceptable; for a bank transfer, it is not — hence TCP.

What is a SYN flood attack?

A SYN flood is a denial-of-service attack that exploits the handshake. An attacker sends thousands of SYN packets with spoofed source addresses. The server sends SYN-ACK responses and allocates memory waiting for ACKs that never arrive. Eventually, the server's connection table fills up and it can no longer accept legitimate connections.

Modern defences include SYN cookies — a technique where the server does not allocate memory until the final ACK arrives, making a SYN flood much less effective.

Frequently asked questions

Do I need to remember the sequence numbers for my GCSE exam?

You do not need to recall specific sequence number values. You need to understand that sequence numbers exist, that they are exchanged during the handshake, and that they enable TCP's reliability guarantees. Being able to describe the three steps (SYN, SYN-ACK, ACK) and explain why each is necessary is the key exam skill.

Why is it called a "three-way" handshake rather than a two-way?

Two packets (SYN and SYN-ACK) would confirm the server can hear the client, but the client's ACK confirms the server can be heard too. Without step 3, the server does not know its SYN-ACK got through. Both sides need to prove their transmissions are reaching the other; that requires three messages.

What happens if one of the handshake packets is lost?

TCP uses retransmission timers. If the client sends a SYN and receives no SYN-ACK within a set time, it retransmits the SYN. Similarly, if the server never receives the final ACK, it eventually gives up and the connection attempt fails. The client will typically retry several times before reporting a connection error to the application.

Is the handshake encrypted in HTTPS?

In HTTPS, the TCP three-way handshake completes first (in plaintext). Immediately afterwards, a TLS handshake takes place to negotiate encryption keys. Once TLS is set up, all application data — including the HTTP request and response — travels inside an encrypted channel. The TCP handshake itself is never encrypted because it must be handled by networking hardware before the application layer is involved.

---

Want to trace through a TCP handshake diagram and test your understanding? Professor Turing at aitutors.me can quiz you on every packet and flag.