Step 1: Go through the TCP finite state machine defined in RFC 793 and check which of the four statements survives contact with it.
Step 2: The connection-establishment states are CLOSED to LISTEN/SYN_SENT to SYN_RCVD to ESTABLISHED, driven by exactly three segments, SYN, SYN+ACK, ACK, so any claim of a two-way handshake does not match this state machine, eliminating that option.
Step 3: For teardown, the state machine explicitly allows the transition ESTABLISHED to FIN_WAIT_1 to be triggered by either endpoint calling close() first, nothing in the specification restricts this to only the client or only the server, so a statement forbidding the server from closing first contradicts the state machine, eliminating that option.
Step 4: The state machine also has a dedicated CLOSING state, reached specifically when an endpoint in FIN_WAIT_1 receives a FIN from the other side instead of the expected ACK, meaning both sides sent their own FIN before seeing the peer's FIN, i.e. they initiated closing at essentially the same time. The existence of this dedicated state is direct proof that simultaneous closing by both client and server is a supported, real scenario.
Step 5: Full-duplex behavior is built into TCP's design, the protocol maintains two independent byte streams, one per direction, each with its own sequence numbers, so describing the connection as half-duplex misrepresents the protocol.
Step 6: The only statement consistent with the RFC 793 state machine and TCP's full-duplex design is that the client and server can initiate closing at the same time, which is exactly the CLOSING-state scenario, so that is the correct option.
\[ \boxed{\text{Option D}} \]