【TCP】握手、挥手过程详解

前言：

        众所周知，在客户端与服务器建立TCP连接时，需要经过三次握手才能真正的建立连接；而客户端与服务器断开连接时，则需要经过四次挥手才能真正的断开连接。

三次握手(图解)：

客户端在握手过程中的状态切换：

        （1）closed：客户端socket连接建立后，发送SYN数据包给服务器前的状态

        （2）SYN_SENT：客户端发送SYN数据包给服务器后的状态

        （3）Established：客户端在收到服务器SYN+ACK数据包后的状态

服务器在握手过程中的状态切换：

        （1）Listen：服务器有一个专门监听连接的socket，该socket状态就是Listen

        （2）SYN_RCVD：服务器在收到客户端请求建立连接的SYN数据包后，分配新的资源(新的socket)与客户端建立连接，这个资源的状态就是SYN_SEND

        （3）Established：服务器在收到客户端ACK数据包后的状态

看完了握手过程及该过程中的客户端与服务器的状态切换，让我们思考一个问题：三次握手改成两次握手行不行，不行是为什么？

        首先答案是不行！！！

        （1）TCP协议的一个特点就是可靠，可靠的要素是什么？要素是确保客户端、服务器收发数据都没有问题，两次握手不能确保客户端接收数据没有问题(因为客户端没有对服务器的SYN+ACK做出响应)，而三次握手能保证客户端、服务器收发数据都没有问题

        （2）在数据传输过程中，由于网络抖动，丢包是很平常的事。假设有一种场景：客户端在发送SYN请求后，由于迟迟没有收到服务器SYN+ACK的回包，又发送了一次SYN请求，两次SYN请求都到达了服务器，服务器无法判断SYN请求是否重复，所以回了两个SYN+ACK的数据包给客户端，客户端能通过数据包中的SEQ序列号和ACK序列号判断请求是否重复，所以会只处理其中一个SYN+ACK请求。此时关键的来了：如果是两次握手，那么服务器就会为两个重复的SYN请求分配两个资源，导致资源浪费，甚至导致系统崩溃；而三次握手以及服务器连接SYN_RCVD的中间态就可以避免服务器重复分配资源

四次挥手(图解)：

客户端在挥手过程中的状态切换：

        （1）FIN_WAIT1：客户端在发送FIN数据包到服务器后的状态

        （2）FIN_WAIT2：客户端在收到服务器发送的ACK数据包后的状态

        （3）TIME_WAIT：客户端收到服务器发送的FIN数据包后的状态(会开启一个计时器，并返回一个ACK数据包给服务器)

        （4）CLOSED：当客户端的计时器超时后的状态

服务器在挥手过程中的状态切换：

        （1）CLOSE_WAIT：服务器在收到客户端发送的FIN数据包后的状态

        （2）LAST_ACK：服务器在收到程序发出的关闭连接指令后，会向客户端发出FIN数据包，状态变更为LAST_ACK

        （3）CLOSED：服务器收到客户端发送的ACK数据包后的状态

看完了挥手过程及该过程中的客户端与服务器的状态切换，让我们思考一个问题：客户端在收到服务器的FIN数据包后，为什么状态不直接变成CLOSED而是TIME_WAIT并开启一个计时器呢？

        首先客户端在TIME_WAIT状态时，可以继续处理服务器发来的指令。现在有一个场景：客户端在发送完ACK指令后进入CLOSED状态，ACK由于网络问题没有被服务器接收到，服务器重发FIN指令，但由于客户端已经是CLOSED状态了无法处理这条FIN指令，那么服务器就会不断重发FIN指令。而TIME_WALT状态的存在就可以避免这种情况发生。

三次握手过程中，服务器直接将ACK和SYN指令合并发给客户端，那么在四次挥手过程中，能不能将ACK和FIN指令合并，变成三次挥手呢？

        答案是不行！！！

        因为TCP层（即运输层）并不知道应用程序是否已经完成了数据的处理及发送，无法直接决定是否与客户端断开连接，只能对客户端发来的FIN指令做出ACK(表示收到)响应，只有当上层应用下达关闭连接的指令后，TCP层才能发送FIN指令来关闭连接。