tcp rst situation finishing

Original link: http://www.cnblogs.com/lulu/p/4149562.html


Under normal circumstances, the tcp four-layer handshake closes the connection, and the rst is basically abnormal, as follows:

1. GFW 

2. The other party's port is not open, it happens when the connection is established

   If the other party's sync_backlog is full, sync is simply discarded, showing a timeout instead of rst

3. When closing Socket, recv buffer is not empty

  For example, the client sends two requests, the server only reads the first request from the buffer and then closes the connection. The tcp layer thinks that the data has not been submitted to the application correctly, and uses rst to close the connection.

3. Mobile Link

      In the mobile network, in China, the signaling is recovered after 5 minutes, that is, the IM product. If the heartbeat is greater than 5 minutes, the server sends a message to the client, and the rst will be received. Also check IM keeps <5min heartbeat under mobile network.

4. Load and other equipment

      The load device needs to maintain the connection forwarding strategy. If there is no traffic for a long time, the connection will be cleared. And many of them do not tell the two-layer machines, and only advertise the rst when new packets come.

   Apple push service also has this problem, and it is unpredictable sporadic connection being rst; the first message write before rst is successful, and the second write will tell you that the connection is reset.

  I was tossed by it once, so I turned on tcp keepalive every 2 seconds, fixed the tcp connection recovery for 5 minutes, and found that the connection was wrong, and resent the message within 10s before.

5. SO_LINGER application forced to use rst to close

    This option will directly discard the unsent send buffer, which may cause business errors, so use it with caution; of course, the http client between intranet services will actively close when receiving the response. Using this option will save resources. 

  It seems that haproxy has been tested. Under a certain configuration, rst will be used to close the connection. There is no network interaction and no TIME_WAIT problem.

6. Exceeded the number of timeout retransmissions, the network is temporarily unreachable

7. TIME_WAIT state

  When tw_recycle = 1, the sync timestamps is smaller than the last time, it will be rst

7. Set connect_timeout

     The application has set a connection timeout. If the sync timeout is not completed, it will send rst to terminate the connection.

8. Abnormal package

  The connection is closed, seq is incorrect, etc.

9. Keepalive timeout

    Public network service tcp keepalive is best not to be turned on; mobile network will increase the network burden and easily disconnect; non-mobile network core ISP devices may not all support keepalive. I have also found that there is a core node in Guangzhou that does not support it. .

10. To be organized


Guess you like

Origin blog.csdn.net/gouguofei/article/details/49947565