I was recently reading about TCP connection termination on good ol' Wikipedia[1] and the article mentioned mentioned the possibility of a half-open state[2]. Basically, the machine that initiates the closing of a TCP connection "should" continue reading the data until the other side terminates as well. This is done on each side with a TCP segment/packet that has the FIN flag set.
I am concerned about this word "should". I have two sanity-check questions:
First, how common is this, REALLY? It seems to me that generally speaking, the client or requester of resources would be the one to initiate the termination of a TCP connection, and they would do it after receiving everything that they needed. Under normal circumstances, there shouldn't be any packets going over the wire when a TCP connection is terminated, right?
On a related note, is this statement that the connection terminator "should" continue to accept data a strong requirement or more of a guideline? As mentioned above, from my perspective, a connection would only close prematurely if something went wrong, in which case it probably wouldn't be feasible to continue reading data. In my opinion, it would actually be a security loophole to continue processing data. I could perform a layer 4 DDOS attack by opening up a bunch of TCP connections with rogue clients and send continuous spam data without ever sending a FIN packet.
[1]https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination [2]https://en.wikipedia.org/wiki/TCP_half-open
My assumption is that sending a FIN packet is synonymous with communicating that I want to terminate the connection as soon as possible
It is not. Sending a FIN just means that this side is done sending data and not that it is done receiving data. Such half-close can for example be used by the client to signal the end of the request but then still wait for the response of the server - which is then terminated with a FIN too which results in a fully closed connection. Still, while this such a protocol design is possible in theory it is uncommon in practice.
But you might run into client data after server FIN when using HTTP persistent connections: The server might close the idle connection at any time after the response to a request was send. But the client might send a new request on a connection which is still open. Since there is some delay between sending the FIN on the server and receiving and processing it in the client the shutdown of the idle connection on the server and the sending of a new request on the client might overlap. In this case one will get new data on the server socket even if the server socket was shut down for sending.