Why does TCP send RST packets twice in a row?

Will the packets captured by Wireshark have two RSTs in one connection?

Two RST records appeared in 247,248. Was wireshark displaying inaccurately, or was it actually sent twice.

This question is very valuable for discussion. In the past packet capture experience, I have also seen many Reset messages when the TCP connection is disconnected. I didn't care too much at first, but when this happened repeatedly, I realized that this was not an accidental phenomenon, but an inevitable behavior implemented in TCP code.

Before discussing this issue, let's review under what circumstances and when will Reset packets occur in TCP?

In the official RFC document, it is generally described as follows: When TCP receives the other party's message and the code cannot be processed, it usually sends a Reset message to release the current TCP connection as soon as possible to allow the other party to re-establish a TCP connection.

Generally speaking, Reset message will be sent under the following conditions:

• TCP destination port is not listening

• The destination port is listening, but the destination port is not bound to the destination IP

• There is no problem in the above two cases, but the source IP cannot be accepted

• There is no problem in the above three cases, but the source port is not acceptable

• Except for the above four cases, the message cannot be processed any more, Reset is the best choice, etc.

What does the sender do after reset? Of course, it releases the memory resources occupied by the TCP connection!

What will the receiver do when it receives Reset? Of course, it also releases the memory resources occupied by the TCP connection!

This is of course the ideal situation. The reality is that the Internet, WAN, and LAN are homes, but there is always a big gap between reality and ideal. If the TCP Reset message is sent, but is lost on the way to the receiver, it will cause the TCP status of the two parties to be completely out of sync, the sender is completely released, and the other party still exists.

If the existing party sends a TCP message later, it will trigger the fully released party to send out the Reset message again. If the existing party receives the Reset message, it will also completely release the memory occupied by the TCP connection, which is very common. Scene.

However, if the party that exists does not send a message for a long time, it will continue to live bravely. Some students will say, isn't it just taking up a little memory resources?

This unreleased memory resource is a burden to the server, and the sooner it is released, the better.

Send Reset message twice in a row

To a certain extent, it can overcome the phenomenon of the loss of synchronization between the two parties due to the loss of a Reset message. After all, the probability of losing two messages is less than the probability of losing one message.

After talking about this topic, let us remind you of the importance of TCP.

It is no exaggeration to say that any Internet engineer who does not understand the state synchronization of a TCP connection does not understand what communication is. In the world of computer networks, there are many concepts of state synchronization, the synchronization of the routing protocol OSPF, the state synchronization of the routing protocol BGP, the state synchronization of the spanning tree, the state synchronization of the multicast tree, the synchronization of the label protocol LDP and so on.

The above is the news sharing from the PASSHOT. I hope it can be inspired you. If you think today' s content is not too bad, you are welcome to share it with other friends. There are more latest Linux dumps, CCNA 200-301 dumps and CCNP Written dumps waiting for you.