Analyze TCP three-way handshake states

During TCP connection establishment (the three-way handshake), exactly one of the following statements is correct. Identify which one, and be prepared to explain why each of the other three is wrong. Options:

• A. The server waits $2\,\text{MSL}$ after receiving the client's SYN segment, then enters SYN_SENT.
• B. The server transitions to SYN_RCVD when it receives the client's ACK segment.
• C. The client can be in ESTABLISHED while the server is still in SYN_RCVD.
• D. If the client's final ACK never reaches the server, the server waits $2\,\text{MSL}$ and then closes the connection directly.

Hint — Where to start: Go through the handshake segment by segment, noting each endpoint's state after every send or receive. The two sides never change state at the same moment. Hint — State ownership: SYN_SENT is the state of the initiating side (the client), while SYN_RCVD is the state of the responding side (the server). Be alert for options that reverse these roles. Hint — Where 2MSL actually lives: The $2\,\text{MSL}$ wait and TIME_WAIT timer belong to connection teardown, specifically for the side that actively closes, not to establishment. Any option that places $2\,\text{MSL}$ in the setup phase is a distractor.

Constraints & Assumptions

• Standard TCP as defined by RFC 793 / RFC 9293; no TCP_DEFER_ACCEPT, no TCP Fast Open, and no simultaneous open.
• Exactly one option is correct; this is a single-answer multiple-choice question.
• The client is the active opener, and the server is the passive listener waiting on a port in the LISTEN state.
• MSL stands for Maximum Segment Lifetime, and 2MSL is twice that duration.

What a Strong Answer Covers

• The correct choice (C), along with the exact state of each endpoint after each of the three segments.
• The complete state progression: client CLOSED → SYN_SENT → ESTABLISHED; server LISTEN → SYN_RCVD → ESTABLISHED.
• Why the client reaches ESTABLISHED before the server does—the asymmetry that makes C correct.
• A sound rebuttal for each incorrect option: A swaps the client and server states and misapplies $2\,\text{MSL}$; B mistakes what triggers SYN_RCVD; D wrongly assigns the $2\,\text{MSL}$/TIME_WAIT mechanism and overlooks SYN+ACK retransmission.
• Where $2\,\text{MSL}$ actually belongs: the TIME_WAIT state of the active closer during teardown.

Follow-up Questions

1. If the client's final ACK is lost, what actually happens on the server? Describe the retransmission behavior and how the half-open connection ultimately resolves.
2. Why does the active closer wait 2MSL in TIME_WAIT, and which two problems does that wait avoid?
3. How does a SYN flood take advantage of the SYN_RCVD state, and how do SYN cookies protect against it without storing per-connection state?
4. In a simultaneous open, where both peers send SYN first, what state path do the endpoints follow, and which option's premise would change? Overview: This question tests understanding of TCP connection establishment and the TCP state machine, checking whether you can recognize correct state transitions during the three-way handshake and related transport-layer behavior.