FIN vs RST in TCP connections

Question

The way I understand this, there are 2 ways to close TCP connection:

• send FIN flag
• send RST flag

RST causes immediate connection termination, while in FIN you get a confirmation.

Do I understand this right, and are there any other distinctions between the two? Can those 2 flags be used together?

Rossierossing

Answer 1

• FIN says: "I finished talking to you, but I'll still listen to everything you have to say until you say that you're done."

• RST says: "There is no conversation. I won't say anything and I won't listen to anything you say."

  RST is useful if you have long lasting TCP connection with little traffic. If one of the computers is restarted, it forgets about the connection, and the other computer gets RST, as soon as it sends another packet.

Energetic

Answer 2

FIN or RST would be sent in the following case

• your process close the socket

• OS is doing the resource cleanup when your process exit without closing socket.

  If your process call close(), FIN would be sent from the closing side by default (note: you can set socket option SO_LINGER to make it send RST instead of FIN)

  If your process exit without closing the socket, kernel would close the tcp connection and do the clean up for your process. FIN or RST can be sent. If there is data in your receive queue, RST would be sent. Otherwise, FIN would be sent.

  You can loop through tcp_close() in tcp.c for more details.(I am using kernel-2.6.32-573.7.1 from redhat branch)

Whited

Answer 3

From RFC 1122, which everybody keeps citing, but not actually quoting, against me:

A TCP connection may terminate in two ways: (1) the normal TCP close sequence using a FIN handshake, and (2) an "abort" in which one or more RST segments are sent and the connection state is immediately discarded.

It is not possible to use both at the same time. The concept doesn't even begin to make sense.

It is possible by means of trickery which I will not describe here to close a TCP connection with an RST instead of a FIN, but it's a stupid idea, which is why I am not documenting it. For one thing, all pending data in flight is lost.

Alien

"It is not possible to use both at the same time." It technically is possible. It's just that, as you say, "the concept doesn't even begin to make sense". (I wasn't the one who downvoted though). – Extrusive

RST does not necessarily indicate an error condition. It may simply mean the sender of the RST doesn't want to hear from you any more and will not necessarily process any data still buffered for the connection. Setting the two flags together is redundant for one half of the connection but not forbidden. It is certainly not that unusual for RST to come soon after FIN in certain circumstances. – Preadamite

@Dave RST throws away all data buffered for the connection, which itself ceases to exist. The sender doesn't have the option of processing or not processing it. 'At the same time' is not the same thing as 'soon after'. – Alien

@EJP - RST serves multiple purposes in RFCs 793 and 1122. One of them is as you have described - to indicate that "no such connection" exists yet or any more. – Preadamite

But another in RFC1122 is to report that the TCP client at one end has closed its input stream while the buffer still contained data. This is not necessarily an error condition. The RST simply informs the remote party that not all data was reliably delivered. Because FIN and RST refer to alternate half-duplex parts of the connection it is possible, although rarely useful, to say FIN "I have no more data to send" and RST "I didn't read all your data". It is not prohibited by the most recent RFC. It might be considered antisocial. – Preadamite

My responses were specifically to "is an error condition" (not always) and "is not possible" (yes it is - and i have seen it quite a lot) and not to the assertion that it is unclean. Incidentally it is also common for many firewall and load-balancer implementations to abuse RST to close connections which are established or even during SYN handshake for reasons other than outlined in RFC 793 and 1122. This prompted RFC 3360. – Preadamite

@Dave Throwing away unsent or unread data makes it unclean. If it is possible to use them at the same time what exactly are the semantics? A FIN should be ACK'd, but as the RST says there is no longer such a connection it can't be. It doesn't make sense. – Alien

As I said in the comment immediately above your last reply - I have not disputed that it is "unclean". Regarding the rest, the RFCs I listed explain this in all the detail necessary. There is really not much point in me regurgitating their contents here. – Preadamite

@Dave RFC 1122 which you keep citing but not quoting makes it perfectly clear that RST is an abort. If there is a difference between 'error condition' and 'abort' I am yet to discover it, or be informed here. – Alien