Architect: We are more afraid of 200 than 404!

Young man, you are reading a short hardcore science article with an illegal mentality!

First ask the question: How to kill a Thread that is waiting for a TCP connection?

For well-known reasons, when using Maven in the country, it will take a long time to download the corresponding jar package.

If we are using IDEA, it is often easy to get stuck. When we click the progress bar, whether we wait or cancel, we need to wait for a long time to complete the current network request.

Unless we immediately close IDEA and then reopen it.

why?

Because you can't use code to kill a connection that is already connected. The operating system does not expose such an API!

But you can kill the process. When the process stops, all the connections associated with it will be released. But you can't kill the thread, because the thread is blocked on a connection. You need to close the connection first to let the thread release automatically.

General connection toolkits provide the soTimeout parameter to configure the timeout. For example, the MySQL client:

 jdbc : mysql : // xxx .xx .xxx .xxx : 3306 / database?connectTimeout = 60000 & socketTimeout = 60000

By setting a timeout, you can prevent the situation of waiting in the event of a network error, shorten the failure time, and prevent the generation of dead connections. But what if the connection does not have a timeout?

It will be blocked there forever!

On Linux, there are tools such as tcpkill and killcx that can kill a connection in the established state.

Taking tcpkill as an example, we need to install the corresponding tool package.

 yum install dsniff -y

Then, use the netstat or ss or lsof command to find the connection to be killed and then kill it.

 tcpkill - 9 - i eth0 host 10.0 .1 .197 and port 2222

After performing such an operation, Thread can be automatically closed normally.

So how is it achieved?

This is related to the old TCP four wave.

To close a connection, you need to wave four times through the FIN packet and the ACK packet. This process is very troublesome, but don't forget that we also have the RST packet, which can directly cause the connection to be closed.

Unfortunately, if you want to send a RST packet, you must first know the SEQ sequence number used during the interaction, because out-of-order data packets will be directly discarded by the operating system.

Therefore, the tool needs to first monitor the connection, then obtain the sequence number, and then use this sequence number to send a simulated RST packet. Your connection is disconnected.

The wall does the same thing.

​About the author: Sister Taste (xjjdog), a public account that does not allow programmers to take detours. Focusing on infrastructure and Linux. Ten years of architecture, hundreds of billions of daily traffic, discussing the high-concurrency world with you, giving you a different taste.