这是我参与8月更文挑战的第4天,活动详情查看,活动详情查看: 8月更文挑战服务器
OK,下面正经地来回答下这个问题,要搞清楚这个问题,首先得了解TCP到底是如何保证可靠传输的。markdown
PS:TCP协议中,主动发起请求的一端称为『客户端』,被动链接的一端称为『服务端』。无论是客户端仍是服务端,TCP链接创建完后都能发送和接收数据。网络
起初,服务器和客户端都为CLOSED状态。在通讯开始前,双方都得建立各自的传输控制块(TCB)。 服务器建立完TCB后遍进入LISTEN状态,此时准备接收客户端发来的链接请求。post
第一次握手spa
客户端向服务端发送链接请求报文段。该报文段的头部中SYN=1,ACK=0,seq=x。请求发送后,客户端便进入SYN-SENT状态。3d
第二次握手code
服务端收到链接请求报文段后,若是赞成链接,则会发送一个应答:SYN=1,ACK=1,seq=y,ack=x+1。 该应答发送完成后便进入SYN-RCVD状态。orm
第三次握手资源
当客户端收到链接赞成的应答后,还要向服务端发送一个确认报文段,表示:服务端发来的链接赞成应答已经成功收到。 该报文段的头部为:ACK=1,seq=x+1,ack=y+1。 客户端发完这个报文段后便进入ESTABLISHED状态,服务端收到这个应答后也进入ESTABLISHED状态,此时链接的创建完成!get
防止失效的链接请求报文段被服务端接收,从而产生错误。
PS:失效的链接请求:若客户端向服务端发送的链接请求丢失,客户端等待应答超时后就会再次发送链接请求,此时,上一个链接请求就是『失效的』。
若创建链接只需两次握手,客户端并无太大的变化,仍然须要得到服务端的应答后才进入ESTABLISHED状态,而服务端在收到链接请求后就进入ESTABLISHED状态。此时若是网络拥塞,客户端发送的链接请求迟迟到不了服务端,客户端便超时重发请求,若是服务端正确接收并确认应答,双方便开始通讯,通讯结束后释放链接。此时,若是那个失效的链接请求抵达了服务端,因为只有两次握手,服务端收到请求就会进入ESTABLISHED状态,等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态,服务端将会一直等待下去,这样浪费服务端链接资源。
TCP链接的释放一共须要四步,所以称为『四次挥手』。
咱们知道,TCP链接是双向的,所以在四次挥手中,前两次挥手用于断开一个方向的链接,后两次挥手用于断开另外一方向的链接。
若A认为数据发送完成,则它须要向B发送链接释放请求。该请求只有报文头,头中携带的主要参数为: FIN=1,seq=u。此时,A将进入FIN-WAIT-1状态。
B收到链接释放请求后,会通知相应的应用程序,告诉它A向B这个方向的链接已经释放。此时B进入CLOSE-WAIT状态,并向A发送链接释放的应答,其报文头包含: ACK=1,seq=v,ack=u+1。
A收到该应答,进入FIN-WAIT-2状态,等待B发送链接释放请求。
第二次挥手完成后,A到B方向的链接已经释放,B不会再接收数据,A也不会再发送数据。但B到A方向的链接仍然存在,B能够继续向A发送数据。
当B向A发完全部数据后,向A发送链接释放请求,请求头:FIN=1,ACK=1,seq=w,ack=u+1。B便进入LAST-ACK状态。
A收到释放请求后,向B发送确认应答,此时A进入TIME-WAIT状态。该状态会持续2MSL时间,若该时间段内没有B的重发请求的话,就进入CLOSED状态,撤销TCB。当B收到确认应答后,也便进入CLOSED状态,撤销TCB。
为了保证B能收到A的确认应答。 若A发完确认应答后直接进入CLOSED状态,那么若是该应答丢失,B等待超时后就会从新发送链接释放请求,但此时A已经关闭了,不会做出任何响应,所以B永远没法正常关闭。