Questions: TCP Connection Termination and FIN/RST Handling

Question 1

A web server finishes sending an HTTP response and sends a FIN segment to the client. The client is still uploading a large file. What happens next?

• A. The connection is immediately fully terminated — the server initiated close, so both directions shut down
• B. The client can continue uploading; the FIN only closes the server-to-client direction, and the connection enters a half-closed state
• C. The client's upload is aborted and any undelivered data is discarded
• D. The client sends RST to signal that it is not ready to close

Answer: (B)

TCP is full-duplex: each direction of data flow closes independently. The server's FIN signals 'I have no more data to send to you,' but it says nothing about the client's ability to send. The client acknowledges the FIN and can continue transmitting data in the other direction. Only when the client also exhausts its data does it send its own FIN, completing the four-way handshake. Option A is the most common misconception — conflating 'I closed my write' with 'the whole connection is done.' This half-close capability is essential for protocols where one side finishes before the other.

Question 2

A developer notices that a busy web server accumulates thousands of sockets in TIME_WAIT state. They propose reducing the TIME_WAIT duration to 1 second to free ports faster. What are the two risks this creates?

• A. Slower connection establishment and increased memory usage per socket
• B. Lost final ACK cannot be retransmitted (the other side retransmits its FIN to a machine no longer waiting), and ghost segments from old connections can corrupt new connections reusing the same four-tuple
• C. Increased CPU overhead for connection teardown and reduced throughput on the same socket
• D. RST storms and cascading connection failures on downstream servers

Answer: (B)

TIME_WAIT serves two specific purposes, both undermined by shortening it. First: if the final ACK is lost, the remote side retransmits its FIN. TIME_WAIT ensures the local side is still present to re-acknowledge it — if TIME_WAIT expires first, the retransmitted FIN arrives to a closed socket and gets a RST, disrupting the remote side's orderly close. Second: 2*MSL guarantees that all packets from this connection have expired from the network before the same port and IP combination can be reused. Without this guarantee, a delayed packet from an old connection could arrive at a new connection sharing the same four-tuple, causing data corruption. These are correctness issues, not just performance concerns.

Question 3

A host that receives a FIN segment can still send data to the FIN-sending host before sending its own FIN, because TCP supports half-close.

• T. True
• F. False

Answer: True

This is the essence of TCP's half-close capability. A FIN only closes one direction of the full-duplex connection — the sender's write direction. The receiver of the FIN acknowledges it (confirming receipt) but is not required to close its own write direction simultaneously. It can continue sending data for as long as needed. This is not just a theoretical detail: many application protocols rely on it. A client sending a large upload while receiving the server's response close is a common real-world scenario. The connection only fully closes after both sides have sent and acknowledged each other's FINs.

Question 4

When a TCP RST is sent, most buffered data in transit is delivered to the receiving application before the connection is fully torn down.

• T. True
• F. False

Answer: False

RST is TCP's emergency abort mechanism, not a graceful teardown. When a RST is sent (or received), the connection is immediately invalidated — no further data is exchanged, and any data buffered in the TCP send or receive buffers is discarded without delivery. This distinguishes RST from FIN: FIN says 'I am done sending, but let us finish properly,' while RST says 'this connection is invalid — stop now, discard everything.' Applications using RST (or that experience an unexpected RST) should expect potential data loss. This is why RST is reserved for error conditions and abrupt termination, not normal connection close.

Question 5

Explain why the TIME_WAIT state lasts for 2*MSL and what would go wrong if it were eliminated entirely.

Model answer: MSL (Maximum Segment Lifetime) is the longest time a TCP segment can survive in the network before being discarded. TIME_WAIT lasts 2*MSL to cover two one-way trips: one for the final ACK to reach the remote side, and one for the remote side's retransmitted FIN to return if the ACK was lost. Without TIME_WAIT: (1) If the final ACK is lost, the remote side retransmits its FIN, but the local socket is gone and responds with RST — disrupting the remote side's orderly close. (2) If a new connection reuses the same four-tuple (source IP, source port, destination IP, destination port) before the 2*MSL window, any delayed packets from the old connection that are still in transit could arrive at the new connection and be accepted as valid data, silently corrupting it.

TIME_WAIT is one of TCP's most misunderstood features because it appears wasteful — holding a socket for up to 4 minutes on a busy server can exhaust ephemeral ports. But eliminating it trades correctness for performance. Most production TCP stacks expose tuning knobs (like SO_REUSEADDR, or reducing tcp_fin_timeout) that carefully relax TIME_WAIT constraints in controlled ways, without fully eliminating its protections.