我们都知道,TCP是个面向连接的、可靠的、基于字节流的传输层通信协议。
那这里面提到的"面向连接",意味着需要 建立连接,使用连接,释放连接。
建立连接是指我们熟知的TCP三次握手。
而使用连接,则是通过一发送、一确认的形式,进行数据传输。
还有就是释放连接,也就是我们常见的TCP四次挥手。
TCP四次挥手大家应该比较了解了,但大家见过三次挥手吗?还有两次挥手呢?
都见过?那四次握手呢?
今天这个话题,不想只是猎奇,也不想搞冷知识。
我们从四次挥手开始说起,搞点实用的知识点。
TCP四次挥手
简单回顾下TCP四次挥手。
正常情况下。只要数据传输完了,不管是客户端还是服务端,都可以主动发起四次挥手,释放连接。
就跟上图画的一样,假设,这次四次挥手是由客户端主动发起的,那它就是主动方。服务器是被动接收客户端的挥手请求的,叫被动方。
客户端和服务器,一开始,都是处于ESTABLISHED状态。
第一次挥手:一般情况下,主动方执行close()或 shutdown()方法,会发个FIN报文出来,表示"我不再发送数据了"。
第二次挥手:在收到主动方的FIN报文后,被动方立马回应一个ACK,意思是"我收到你的FIN了,也知道你不再发数据了"。
上面提到的是主动方不再发送数据了。但如果这时候,被动方还有数据要发,那就继续发。注意,虽然第二次和第三次挥手之间,被动方是能发数据到主动方的,但主动方能不能正常收就不一定了,这个待会说。
第三次挥手:在被动方在感知到第二次挥手之后,会做了一系列的收尾工作,最后也调用一个 close(), 这时候就会发出第三次挥手的 FIN-ACK。
第四次挥手:主动方回一个ACK,意思是收到了。
其中第一次挥手和第三次挥手,都是我们在应用程序中主动触发的(比如调用close()方法),也就是我们平时写代码需要关注的地方。
第二和第四次挥手,都是内核协议栈自动帮我们完成的,我们写代码的时候碰不到这地方,因此也不需要太关心。
另外不管是主动还是被动,每方发出了一个 FIN 和一个ACK 。也收到了一个 FIN 和一个ACK 。这一点大家关注下,待会还会提到。
FIN一定要程序执行close()或shutdown()才能发出吗?
不一定。一般情况下,通过对socket执行 close() 或 shutdown() 方法会发出FIN。但实际上,只要应用程序退出,不管是主动退出,还是被动退出(因为一些莫名其妙的原因被kill了), 都会发出 FIN。
FIN 是指"我不再发送数据",因此shutdown() 关闭读不会给对方发FIN, 关闭写才会发FIN。
如果机器上FIN-WAIT-2状态特别多,是为什么
根据上面的四次挥手图,可以看出,FIN-WAIT-2是主动方那边的状态。
处于这个状态的程序,一直在等第三次挥手的FIN。而第三次挥手需要由被动方在代码里执行close() 发出。
因此当机器上FIN-WAIT-2状态特别多,那一般来说,另外一台机器上会有大量的 CLOSE_WAIT。需要检查有大量的 CLOSE_WAIT的那台机器,为什么迟迟不愿调用close()关闭连接。
所以,如果机器上FIN-WAIT-2状态特别多,一般是因为对端一直不执行close()方法发出第三次挥手。
主动方在close之后收到的数据,会怎么处理
之前写的一篇文章《代码执行send成功后,数据就发出去了吗?》中,从源码的角度提到了,一般情况下,程序主动执行close()的时候;
-
如果当前连接对应的socket的接收缓冲区有数据,会发RST。
-
如果发送缓冲区有数据,那会等待发送完,再发第一次挥手的FIN。
大家知道,TCP是全双工通信,意思是发送数据的同时,还可以接收数据。
Close()的含义是,此时要同时关闭发送和接收消息的功能。
也就是说,虽然理论上,第二次和第三次挥手之间,被动方是可以传数据给主动方的。
但如果 主动方的四次挥手是通过 close() 触发的,那主动方是不会去收这个消息的。而且还会回一个 RST。直接结束掉这次连接。