关于三次握手以及四次挥手的详细解释

一、三次握手

如图:

握手开始之前客户端处于 Closed 的状态，服务端处于 Listen 状态，在时刻监听着。

1. 首先客户端向服务端发送了一条报文，SYN置为1表示有效要建立连接，然后seq序列号为随机数x。
2. 待服务端收到后，因为SYN为1，所以服务端明白了客户端这是要建立请求，所以就赶紧回给了客户端A一条报文，其中SYN与ACK都设置为1，然后此时服务器端的序列号为假设为y,然后ack设置为客户端的序列号加1，表示我正确的收到了你给我的请求。
3. 然后客户端收到了服务器端的响应包后，进行一一确认无误后，知道了服务端已经给到了自己正确的反馈，然后接着发送报文给服务端，进行最后确认，将ACK设置为1，把自己的seq序列号加1，然后ack设置为服务端的序列号加1，表示自己正确接收到了信息。
4. 此时，服务端也终于收到了这个报文，进行了一个最终确认，发现没有任何问题，这个时候双方都确认无误，建立起了连接，然后就开始了双方的一个数据传送。

然后这个时候就有人问了，为什么要三次握手，不要两次握手，两次之后不也能立刻建立连接，感觉第三步很多余？

为什么是三次不是两次，其实道理很简单，因为经过第二次握手之后，服务器端不能保证自己的发送能力是OK的，也不知道客户端的接收能力是OK的，只有经过了第三次握手，服务器端才真正的完全确认自己发送的客户端收到了，此时才能证明自己的发送能力以及客户端的接受能力都没有任何问题。

二、四次挥手

如图:

1. 第一次挥手，客户端这个时候想要断开连接，所以发送给了服务端一条结束报文FIN，指定序列号为u。
2. 第二次挥手，服务端收到了之后，立马回给客户端一条报文，表示我收到了，但是我还不能和你断开，因为我还有一些东西没交接完毕，你先等着，等我交接完毕之后再通知你。
3. 第三次挥手，这个时候服务端已经将所有的数据都交接完毕，可以正式和客户端说拜拜了，就立马发给了客户端一条FIN报文，其中seq指定为自己的随机序列号w，ack指定为客户端的序列号加1。
4. 第四次挥手，客户端收到了服务器发过来的报文，确认完毕之后，立马回了一条报文给服务器端，表示我收到了，你可以断开了。
5. 这个时候服务器端收到了，验证无误，立马close掉了，断开了与客户端的连接。
6. 但是客户端这个时候是不能立马断开的。而是进入到了time-wait状态，需要等待2*MSL（Maximum Segment Lifetime）时间，MSL表示为最长报文段寿命,等到时间到了才会close。

然后这个时候就有人问了，为什么不立马断开，还需要等待这么长时间呢？

因为服务端第三次挥手，发送完FIN报文后处于last-ack状态，还没有close掉。如果客户端发送完ACK报文后，立马close掉了，因为网络不可靠，所以这个时候客户端发送给服务端的第四次挥手响应报文可能会丢失，那么服务端就无法正常进行close。所以客户端需要第四次挥手后需要进入time-wait状态，这个时候如果ACK丢了，那么服务端超过一定时间后会重新发送一条FIN报文，进行再次尝试。