Why TCP Reset sent after receive [FIN,ACK] Packet?

TCP is a bi-directional protocol. This means that during a connection close sequence, both sides get to say "I'm done sending things now." The connection isn't "down" until both sides have done that, or one side sends a TCP RST packet.

It is quite possible — and indeed common — for the connection to be half-closed. For example, a simple HTTP 1.0 conversation is a request for information, followed by a response from the server. The client is free to close its sending half of the connection after the request; it won't affect whether the server sends the reply. HTTP 1.1 can be more complex than this, allowing multiple requests and responses on a single connection, but the old one request per connection style is still legal.

Looking at your capture, what I see is that the server sends its FIN and ACK bits, and the client responds with a RST. That means the client isn't coded to shut the connection down gracefully. There are many ways for this to happen:

• The client can just exit without closing the connection. The stack is free to complete the graceful shutdown for the dead program, but it's likely to just send RST immediately.

• The client can set the SO_LINGER option with setsockopt() to 0, then exit, leaving the stack no choice but send a RST because both TCP peers are gone and it has been told it isn't allowed to spend any time cleaning up the connection.

• The client can use non-blocking sockets, call close() on the socket, then exit, thinking it has closed its sending half correctly, not realizing that it is forcing the stack to abort sending in-flight packets, substituting a RST.

• If the client doesn't abortively exit like above, it may be doing something odd like shutdown(fd, SHUT_RDWR) or shutdown(SHUT_RD). The first is called "slamming the connection shut," and the second is basically the client telling the server "shut up, you!" Either way, a TCP RST goes out.

Bottom line, the client has a bug, and needs to be fixed.

RST in response to FIN is an old hack that's still common in http. The concept is basically that http sessions are short-lived, with a single Req/Resp pair (http 1.0). This special case therefore doesn't require TCP's ability to receive data after a FIN is sent, so after the server is done sending the requested content, the browser will send a RST. This bypasses the CLOSE-WAIT and LAST-ACK states on the browser, and triggers the server to bypass the FIN-WAIT-1/FIN-WAIT-2/CLOSING states.

Short answer: when dealing with web browsers, this is common behavior.