linux强制断开tcp连接(linux如何手动释放tcp连接)

client/server端recv： ①对端close(fd)检测(超时检测)：recv 返回0，说明缓存区数据被读完，实测两种情况，对端没有再发数据，对端fd被关闭了。通过select超时来检测，当超时如2s，我们认为对端连接断开，应关闭本地的fd。②网线断开/断电关机检测(超时检测)：recv 返回-1，errno == EAGAIN，意为“没有可读写数据,缓冲区无数据”。所以此时需要select超时检测，若超时，要么对端没有再发数据，要么对端的网线断了或者直接断电了。 超过我们判定为对端不在线，关闭本地的fd。

先用ps命令找到哪些服务正在调用该阻塞的端口； 再用kill -s 19 #进程编号#暂停掉该项服务，也可以直接kill掉； 这样资源就释放出来了
用完后关闭套接字就可以吧 close(sockfd);

TCP通信的话，服务端断开时会自动通知客户端客户端处理该事件就可以了
数据传输结束后，通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态。A的应用程序先向TCP发出连接释放报文段，主动关闭TCP连接。A把连接释放报文段的首部FIN置为1，序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1状态，等待B的确认。 B收到连接释放报文段后即发出确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSE-WAIT状态。TCP服务器进程这时通知高层应用进程，因为从A到B这个方向的连接释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接受。也就是说，从B到A这个方向的连接并未关闭。这个状态可以会持续一些时间。A收到B的确认后，就进入FIN-WAIT-2状态，等待B发出的连接释放报文段。若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使用FIN=1。现假定B的序号为w(在半关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过的确认号ack=u+1。这是B就进入LAST-ACK状态，等待A的确认。在A收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置为1，确认号ack=w+1，而自己的序号是seq=u+1(前面的FIN报文消耗了1个序号)。然后进入TIME-WAIT状态。请注意，现在TCP连接还没释放掉。必须再经过2MSL后，A才进入到CLOSED状态。MSL叫最长报文段寿命，一般为2分钟。 当B收到A发出的确认，就进入CLOSED状态。由此可见B结束TCP连接的时间要比A早一些。等到2MSL结束后A也进入CLOSED状态，至此完成了TCP四次挥手断开连接全过程。

切断的方法找不到的话，变通一个可以不？ 你可在iptable里禁止来自ip192.168.2.50的所以tcp请求。
iptables -A INPUT -s 192.168.2.0/24-j REJECT

1 确认链路是否连通状态，最好加心跳机制， 如果一定时间没有收到心跳包，或者没有回复心跳 就应认为此链路已经坏掉了，需要关闭，重新连接！2 至于发送数据，应该检查对应的api的返回值，是否已经成功发送或者接受定长数据！没有完成应该重新发送或者接受3 网络数据问题，可以用抓包工具直接抓包看数据，可以看的比较透彻 工具 Linux下用tcpdump，windows用wirekshark