Automatically closing FIN_WAIT_2 is a violation of the TCP specification
This is an interesting case, but I'm confused about some of the details.> A little known fact is that it's not possible to have any packet loss or congestion on the loopback interface.This seems a bit misleading, given the two counterexamples that the article describes after this.> If you think about it - why exactly the socket can automatically expire the FIN_WAIT state, but can't move off from CLOSE_WAIT after some grace time. This is very confusing... And it should be!On illumos, the FIN_WAIT_2 -> TIME_WAIT transition happens only after 60 seconds if the application has closed the socket file descriptor.  In that case, by definition the application has no handle with which to perform operations on the socket.  The resource belongs exclusively to the kernel.  If the other system disappeared forever, and there were no timeout, that socket would be held open forever.By comparison, in CLOSE_WAIT, the application still has a handle on the socket, and it's responsible for the resource.  The application can even keep sending more data in this case (as part of a graceful termination of a higher-level protocol).  Or it could enable keep-alive.  It's able to respond to the case where the other system has gone away, and it could break the application if the kernel closed the socket on its behalf.I think the behavior is non-obvious, but pretty reasonable.