真正“搞”懂HTTP协议02之空间穿梭( 七 ) _生活百科

补充：四次挥手数据传输完了之后， TCP还需要做一点事情，就是通道建立了，但是当我不需要的时候，我想把通道关闭，不然一直监听着有没有消息给我实在是太累了。
当TCP关闭通道的时候，需要通过四次挥手来确认，它是这样挥手的：

文章插图
我们解释完这张图，本章就完事啦。
我们简单解释下这张图，当客户端发送一个“我不玩了”的消息后，就会进入到FIN_WAIT_1的状态，等待后续的服务器反馈，当服务器收到消息后，就会在之前的基础上给包序号加+1返回给客户端，那么此时服务器就进入到了CLOSED_WAIT的待关闭状态。

我们稍微跑题一下，在学习了三次握手，和上面四次挥手的图示后，你发现一个问题没有，就是所有的应答都是在请求的基础包序号上+1 。换种理解方式就是+1的序号都是作为应答出现的包。

我们继续上面的话题，当客户端收到了服务器的第一次响应应答后，会进入到FIN_WAIT_2的状态，为啥这里客户端要等服务器再发送一个包呢？假如服务器还有未处理完的数据要给你咋整？你不是还得接收，所以要等服务器的数据都处理完毕了，告诉客户端，我这边也可以不玩了才行。
于是，当服务器也结束了自己的任务的时候，就把包发给客户端，客户端进入TIME_WAIT的状态。当服务器收到第二次客户端的应答后，就直接关闭了。
最后， TCP还要求客户端还是要持续的监听一段时间，这个时间就是报文最大生存时间，等了一段时间后，就进入关闭的状态了。
我们看哈，其实整个四次挥手，一次是由客户端发起，一次服务器应答，一次是由服务器发起，客户端应答，最后，客户端再等待一段时间。才最终结束整个挥手过程。
那他为什么不可以像三次握手那样，请求，响应，响应响应，三个步骤就可以了呢。这里有一个核心就是，建立连接时，双方都处于空闲状态，没有正在运行的程序，而关闭时，需要确定双方的程序都结束才可以。所以再四次挥手的由服务器发起的请求的过程中，就是为了等待服务器的任务跑完。
小结我们稍微回顾下我们本章都学习了什么。