个人微信公众号:程序猿的月光宝盒
1.1 说一说TCP的四次挥手
"挥手",即终止TCP连接,断开一个TCP连接池.
需要客户端和服务端总共发出四个包,以确认连接断开,流程如图:
(假设客户端主动关闭,也可以是被动的)
第一次:seq=u,u(是前面ESTAB状态下,数据最后一次发送的时候,已经传送过来的数据最后一个字节的序号,再加上1),TCP规定,即使第一次不携带数据,也要消耗掉一个序号(回执是u+1)
第二次:服务器发出确认报文(ACK=1),ack也携带自己的seq=v.CLOSE-WAIT(半关闭状态,即客户端已经没有数据要发送了,但是服务器要是发送数据,客户端还是可以接收)
第三次: 由于在半关闭的状态,服务器很可能又发送了数据,假设此时的序号(seq=w),服务器进入LAST-ACK状态(最后确认)
第四次:客户端在收到服务器的连接释放报文后,必须发出确认,即ACK=1,ack = 服务器发送的seq的w+1,回发回去,自己的序号(seq)假定为u,那就是u(第一次的seq)+1,客户端进TIME-WAIT,再经过2*MSL时间进入close,MSL即最长报文段生命(Linux中是30s)
总结:
TCP采用4次挥手释放连接,
第一次挥手:客户端发送一个FIN,用来关闭客户端到服务器的数据传送,客户端进入FIN_WAIT_1状态;
第二次挥手:服务器收到FIN后,发送一个ACK给客户端,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),服务器进入CLOSE_WAIT状态
第三次挥手:服务器发送一个FIN数据包,用来关闭服务器到客户端的数据传送,服务器进入LAST_ACK状态
第四次挥手:客户端收到FIN后,客户端进入TIME_WAIT_2状态,接着发送一个ACK给服务器,确认序号为收到序号+1,服务器进入SLOSED状态,客户端在等待2*MSL(超时设置)后进入SLOSED,完成4次挥手.
1.2 为什么会有TIME_WAIT状态
原因:
1.确保有足够的时间让对方收到ACK包,如果被动关闭的那方没有收到ACK就会触发重发FIN包一来一去刚好2MSL
2.有足够的时间让这个链接不会和后面的链接混在一起,避免有些路由器会缓存IP数据包,如果连接混淆,就会跟新连接混在一起
1.3 为什么需要四次挥手才能断开连接
因为TCP是全双工,(同时传送数据),所以发送方和接收方都需要FIN报文和ACK报文,也就是说发送和接受方各自需要2次挥手,只是有一方是被动的,所以看上去就成了四次挥手
1.4 服务器出现大量CLOSE_WAIT的原因
原因:
对方关闭连接后,我方忙于读写,没有及时关闭连接
解决方案:
1.检查代码,特别是释放资源的代码
2.检查配置,特别处理请求的线程配置