Questions: TCP Connection Establishment (Three-Way Handshake)

Question 1

Consider replacing TCP's three-way handshake with a two-way handshake: the client sends SYN, and the server responds with SYN-ACK — after which the connection is considered established. What critical problem would this create?

• A. The server would not receive the client's initial sequence number
• B. The client would have no way to send data without a third message
• C. The server's initial sequence number would be unacknowledged — the server has no confirmation that the client received the SYN-ACK and is ready to communicate
• D. Two-way handshakes require more retransmissions and are therefore slower

Answer: (C)

The handshake must be mutual: each side proposes a sequence number AND receives confirmation that the other side received it. In a two-way handshake, the server sends SYN-ACK (confirming the client's ISN and proposing its own) but never hears back. The server has no guarantee the client received the SYN-ACK, knows the server's ISN, or is still present. Three messages are the minimum required for both sides to know both ISNs have been acknowledged. Option A is wrong: the client's SYN carries the client's ISN, so the server does receive it — the problem is the server's ISN going unconfirmed.

Question 2

A server receives a SYN segment, sends SYN-ACK, and then receives RST from the client instead of ACK. What most likely happened?

• A. The client intentionally aborted a new connection request
• B. A stale SYN segment from a previous, long-closed connection arrived at the server after a network delay
• C. The server's SYN-ACK contained an incorrect sequence number
• D. The client ran out of ports before completing the connection

Answer: (B)

This is the stale duplicate SYN scenario the three-way handshake is designed to handle. A SYN from a previous connection may arrive late due to network delays. The server cannot know it is stale and responds with SYN-ACK. But the client has no matching connection state and sends RST to clean up the ghost connection. Without this third message, the server might maintain a half-open connection indefinitely. This protection against network ghosts is a key reason the handshake uses three steps rather than two.

Question 3

The third message in TCP's three-way handshake — the client's final ACK — can carry application data at the same time.

• T. True
• F. False

Answer: True

TCP allows the third message (client ACK) to be combined with the first data segment. Once both sides have agreed on sequence numbers and confirmed receipt, there is no protocol requirement to wait for a separate data-only segment. Many TCP implementations do send data in the third message, reducing latency by one round-trip time. This is valid because the connection is fully established at the moment the third message is sent.

Question 4

TCP uses a three-way handshake (rather than two) primarily because it is a full-duplex protocol and each direction of communication requires a separate setup phase.

• T. True
• F. False

Answer: False

The three-way handshake is not fundamentally about full-duplex operation — it is about mutual acknowledgment of initial sequence numbers. Each side must both propose an ISN and receive confirmation that the other side received it. This requires a minimum of three messages regardless of duplex operation. A two-way handshake would fail even for unidirectional communication because the initiating side would have no confirmation its SYN was received. Connection teardown (the four-way FIN exchange) is the mechanism that separately closes each direction of data flow.

Question 5

Why must TCP's connection setup use exactly three messages rather than two? What would go wrong with a two-way handshake?

Model answer: Both sides must synchronize initial sequence numbers, and each side must confirm receipt of the other's ISN. In two messages (SYN, SYN-ACK), the client's ISN is acknowledged but the server's is not — the server cannot know the client received its SYN-ACK and is ready to communicate. Three messages are the minimum for mutual confirmation of both ISNs.

Without the third message, the server also cannot distinguish an active new connection from a delayed stale SYN from a long-dead previous connection. The three steps are: (1) client proposes its ISN, (2) server acknowledges client's ISN and proposes its own, (3) client acknowledges server's ISN — only then is mutual synchronization confirmed. This ensures both sides are actively participating right now, not reacting to old network segments.