I've been reading about the TCP protocol recently because I was a little curious about how and why certain flags were used.

In the information I found it talks about a normal close TCP FIN should be used to close a connection but then it also talks about TCP RST can be used for an abortive close on an active connection.

My question is, why would one use a RST to abort/close an active connection over using TCP FIN?

(Referring to an active connection as a connection where both endpoints sent and received data after the standard 3 way handshake. I know a RST can be used by the server when a client sends SYN for a server port that is not listening)


You wouldn't normally see a TCP RST. I suppose an application at layer 7 aborting might generate a RST, but I think you'll find that a RST is most often generated by a firewall between the two hosts. Here's a list of possible reasons from the TCP/IP guide:

Receipt of any TCP segment from any device with which the device receiving the segment does not currently have a connection (other than a SYN requesting a new connection).

Receipt of a message with an invalid or incorrect Sequence Number or Acknowledgment Number field, indicating the message may belong to a prior connection or is spurious in some other way.

Receipt of a SYN message on a port where there is no process listening for connections.

  • +1 for that. A common application-level RST is when the connecting IP is in hosts.deny. IME, though, it's fairly common for applications to RST when something 'bad' has happened and they want to say "I'm not talking to you any more. Go away." – SmallClanger Mar 2 '11 at 16:32
  • @SmallClanger, if an application were to receive a RST because of something "bad" should it handle that differently then say a FIN? As in, should it consider a FIN as just a regular disconnect and a RST as "Oh, maybe I'm doing something wrong"? – Phillip Mar 4 '11 at 5:17
  • I would assume that a RST would be considered a hostile disconnect vs. a FIN. Like firing someone at work vs. them leaving because the contracted project is complete. – Phillip Mar 4 '11 at 5:28
  • That's a good analogy for it. – joeqwerty Mar 4 '11 at 11:51

Some webservers use RST instead of FIN to close (persistent) connections. This is seen as an "optimisation", because it avoids the "half-closed" state and sidesteps some of the issues with missed FIN packets (any further transmission will just produce another RST), that would otherwise require state to be remembered (2xMaximum segment time IIRC) for longer on the server side.

See: this paper and wikipedia on connection termination. (I'll try and dig out some more interesting references too).

You might also see RST if application with the socket crashed (segfault?), host rebooted, or NAT table entries timed out before the connection itself did!

  • If I may ask, since you brought it up with host reboot, during a crash, how does one end (stable) find out the the other end (unstable) crashed? If the application doesn't send anything I would assume it can translate that as just "no data to receive" vs. translate a crash but how does it do that exactly? – Phillip Mar 4 '11 at 5:25
  • it won't notice (usually) until the remaining end tries to send something and it either a) times out after multiple retransmissions without a corresponding ACK or b) sends something to a host that wasn't expecting it and gets and RST back. – Flexo Mar 4 '11 at 9:48

This is an edge case but I find it interesting:

Some filtering software like web sense (ab)uses RST packets. What happens is that instead of websense sitting between all the traffic it sniffs traffic off the wire. If it sees a blocked site it spoofs an RST packet to the client (and I think maybe the server as well).

This is more of a clever trick then it is an intended use though.

  • Is that reliable? Doesn't it require sequence number prediction? – Flexo Mar 2 '11 at 16:41
  • @Alan: I never looked at any dumps, this was just explained to me by an engineer there. However since it would sit on the lan I imagine it it is pretty easy to win the race for something being accessed over the WAN. I don't think prediction would be a problem when you can see both sides of the conversation. – Kyle Brandt Mar 2 '11 at 16:46
  • Ah yes, I guess doing it en-route is much easier than the general case. – Flexo Mar 2 '11 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.