The three-way handshake and connection teardown

Before Aisha's browser sends a single byte of her request, three messages have already gone back and forth. That round trip is a real part of why the first load of a site feels slower than the rest.

Why & what

Why a handshake is needed. TCP promises ordered, reliable delivery. To keep that promise, both sides must agree on things before data starts flowing.

• Is the other side actually there and listening?
• What number will each side start counting from?
• Both sides need to confirm they can send and receive.

What the pieces are.

• SYN a flag in the TCP header meaning "synchronise". It means: I want to start, and here is my starting number.
• ACK — a flag meaning "acknowledge". It means: I received up to here.
• Sequence number (seq) — where this side's counting begins.
• Acknowledgement number (ack) the next byte number this side expects to receive.

The starting sequence number is deliberately random, not zero, to make it hard for an attacker to guess and inject fake segments.

Why closing takes four steps. A TCP connection is full duplex — two independent streams, one in each direction. Each direction must be shut separately, because Aisha finishing her upload does not mean the server has finished sending the page.

How it works

Opening three messages.

1. Aisha sends SYN, seq=100. Meaning: I want to talk, my numbering starts at 100.
2. The server replies SYN + ACK, seq=500, ack=101. Meaning: I agree, my numbering starts at 500, and I am ready for your byte 101.
3. Aisha sends ACK, ack=501. Meaning: got yours, ready for your byte 501.

The connection is now open, and the HTTP request goes out.

Closing — four messages.

4. Aisha sends FIN, the server replies ACK. Her direction is now closed, but the server can still send.
5. The server sends its own FIN, Aisha replies ACK. Both directions closed.

Common confusion

Students think the three-way handshake carries the request itself. Actually, the handshake carries no application data at all. It is pure setup.

Aisha's GET /results goes out as a fourth message, after the handshake completes. That is why the handshake costs a full round trip before anything useful is sent, and why protocols like QUIC were designed to cut it down.

A related mix-up: the middle step is one message, not two. SYN and ACK are two flags set in the same segment, which is why it is three-way and not four-way.

Interview angle

Asked as: "Explain the three-way handshake" and the follow-up "why does closing take four steps?" Being able to answer the second one separates you immediately.

Model answer:

To open a connection, the client sends a SYN with its initial sequence number. The server replies with SYN plus ACK in a single segment — its own initial sequence number, and an acknowledgement of the client's. The client sends a final ACK. Three messages, and now both sides know the other can send and receive, and both know the starting sequence numbers.

Closing takes four because a TCP connection is full duplex, so each direction closes independently. One side sends FIN and gets an ACK, which closes that direction only. The other side keeps sending until it is finished, then sends its own FIN and gets an ACK. No application data travels in the handshake. It costs one full round trip before the first request goes out.