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 enters the `SYN_SENT` state after waiting $2\,\text{MSL}$ upon receiving the client's `SYN` segment. - **B.** The server enters the `SYN_RCVD` state after receiving the client's `ACK` segment. - **C.** When the client is already in the `ESTABLISHED` state, the server may still be in the `SYN_RCVD` state. - **D.** If the server does not receive the client's final `ACK` segment, it directly closes the connection after waiting $2\,\text{MSL}$. ```hint Where to start Walk the handshake one segment at a time and write down the state each endpoint is in *after* each segment is sent or received. The two endpoints do **not** change state simultaneously. ``` ```hint State ownership `SYN_SENT` belongs to the side that *initiates* (the client); `SYN_RCVD` belongs to the side that *responds* (the server). Watch for options that swap these. ``` ```hint Where 2MSL actually lives $2\,\text{MSL}$ and the `TIME_WAIT` timer appear during connection **teardown** by the active closer, not during establishment. Any setup-phase option that invokes $2\,\text{MSL}$ is a distractor. ``` ### Constraints & Assumptions - Standard TCP per RFC 793 / RFC 9293; no `TCP_DEFER_ACCEPT`, no TCP Fast Open, no simultaneous-open scenario. - Exactly one option is correct (single-answer multiple choice). - "Client" is the active opener; "server" is the passive opener listening on a port (`LISTEN` state). - `MSL` = Maximum Segment Lifetime; `2MSL` is twice that value. ### What a Strong Answer Covers - The correct option (**C**), with the precise state each endpoint occupies after each of the three segments. - The full state sequence: client `CLOSED` → `SYN_SENT` → `ESTABLISHED`; server `LISTEN` → `SYN_RCVD` → `ESTABLISHED`. - Why the client reaches `ESTABLISHED` *before* the server does (the asymmetry that makes C true). - A correct rebuttal of each wrong option: A swaps client/server state and misuses $2\,\text{MSL}$; B confuses the trigger for `SYN_RCVD`; D misattributes the $2\,\text{MSL}$/`TIME_WAIT` mechanism and ignores `SYN+ACK` retransmission. - Where $2\,\text{MSL}$ genuinely applies (the `TIME_WAIT` state of the active closer during teardown). ### Follow-up Questions 1. What actually happens on the server if the client's final `ACK` is lost? Describe the retransmission behaviour and the eventual outcome of the half-open connection. 2. Why does the active closer wait `2MSL` in `TIME_WAIT`, and what two problems does that wait prevent? 3. How does a SYN flood exploit the `SYN_RCVD` state, and how do SYN cookies defend against it without keeping per-connection state? 4. In a *simultaneous open* (both peers send `SYN` first), what state path do the endpoints follow, and which option's premise would change?