Use of TCP FIN and TCP RST

Question

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)

score 5 · Answer 1 · answered Mar 02 '11 at 16:18

5

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.

answered Mar 02 '11 at 16:18

joeqwerty

108,377
6
80
171

+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 02 '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 04 '11 at 05: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 04 '11 at 05:28
That's a good analogy for it. – joeqwerty Mar 04 '11 at 11:51

Flexo · Answer 2 · 2011-03-02T17:10:24.167

5

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!

edited Mar 02 '11 at 17:10

answered Mar 02 '11 at 16:44

Flexo

588
9
23

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 04 '11 at 05: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 04 '11 at 09:48
What if you want to forcibly close an active connection? – Aaron Franke Mar 21 '20 at 00:04

score 3 · Answer 3 · answered Mar 02 '11 at 16:35

3

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.

answered Mar 02 '11 at 16:35

Kyle Brandt

82,107
71
302
444

Is that reliable? Doesn't it require sequence number prediction? – Flexo Mar 02 '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 02 '11 at 16:46
Ah yes, I guess doing it en-route is much easier than the general case. – Flexo Mar 02 '11 at 16:52

score 1 · Answer 4 · edited Nov 13 '19 at 16:03

TCP is a reliable protocol. So in any case the message should not be lost in any direction, during the full life-cycle of a TCP connection. Connection termination is the last part. So TCP should make sure that all packets were delivered before closing the connection. FIN is used to close TCP connections gracefully in each direction, while TCP RST is used in a scenario where TCP connections cannot recover from errors and the connection needs to reset forcibly. As per this tcp connection termination article, RSET is used in abnormal conditions.

Use of TCP FIN and TCP RST

4 Answers4