Anyway, I still have to understand why servers stop to respond after a while they are bombarded with a FIN packet
The way it's supposed to work is:
Client sends data to the server
Server responds with data to the client
Server, when done shuts down its
write side
The client reads remaining data and when its read side is fully drained it gets an EOF (because the server sent a FIN on shutdown)
The client shuts down its write side and closes the socket
The server gets an EOF when the client has shut down its write side, and this confirms the client has seen everything sent
The server closes the socket
When a TCP connection is closed its goes into a TIME_WAIT state. This is to prevent the same address,port pairs to be used again since they uniquely identify a connection. If they're used too soon there is a risk of confusing TCP segments in the current connection with segments from a past connection that may have sat delayed in router queue, or got misrouted and took a while to find their way to their destination. The TIME_WAIT state is configurable, and by default fairly long (forget off hand, several minutes). When a connection is closed in an orderly fashion (using the shutdown semantics above), the TIME_WAIT period is dramatically shortened (to a few seconds). If it's shutdown due to an error, the full period applies as one of the endpoints may still be trying to use it. When you shutdown the read side, if there is any data in the socket buffer a TCP RST is issued - this signals an erroneous disconnect. The reason is so the other part can detect that you didn't see some of the data sent. The full TIME_WAIT applies. When you have two hosts, or localhost, the addresses are static, plus the server port number is static, and the address, port pairs of the endpoints uniquely identify a connection, you soon have the full 65536-1024 possible anonymous ports stuck in TIME_WAIT on either the client or server or both. No more ports are available and no more connections can be made.
The classic textbook is TCP/IP Illustrated by Richard Stevens. Vol 1, Chapter 18.
http://www.pcvr.nl/tcpip/ (
http://www.pcvr.nl/tcpip/tcp_conn.htm#18_0)
There are tons of tweaks, options and adjustments to TCP since then, but this describes very much how it still works...