三次握手流程

1. 首先是客户端（也就是我们的浏览器）发送一个SYN标志位为1的请求报文，表示请求建立连接，此时客户端进入SYN-SENT状态；
2. 然后服务器接收到之后会返回一个SYN和ACK标志位为1的报文，表示响应客户端的连接请求，并请求客户端建立连接，此时服务端进入SYN-RCVD状态；
3. 最后客户端返回一个ACK标志位为1的报文，于是双方进入ESTABLISHED状态，表示连接建立成功。

为什么是三次握手，而不是两次或四次

1、三次握手可以防止历史连接建立请求导致的错误连接初始化。

比如我们有一个客户端向服务器发起握手请求，握手请求报文的seq num是90但是此时网络阻塞，导致握手请求的报文迟迟没有到达服务器。

然后我们重启了客户端，此时重新发送连接建立请求的报文，这次报文的seq num是100，此时网络通畅了，seq等于90的握手请求比seq等于100的握手请求先到达。

此时服务器会先响应一个ack等于91的响应报文，然后客户端接收到之后，会返回一个RST标志位为1的报文。RST标志位为1，表示这个连接要终止。

这样，服务器没有为这个错误的握手请求建立连接并初始化相应的资源。而是等到seq等于100的握手请求到达，走完三次握手，才会真正建立连接，并开始数据的传输。

如果现在两次握手就建立连接了，就会变成这样：

两次握手就建立了连接，服务端就会为这个连接初始化一系列资源，然后后面收到RST包后又终止连接，这就纯属资源浪费了。

2、三次握手才能确定双方的seq序列号。

首先客户端与服务器的一来回，可以确定客户端的序列号。

然后服务器到客户端的一来回，可以确定服务端的序列号。

第二次和第三次可以合为一次握手请求，于是三次握手请求就可以确定双方的序列号。

至于为什么不是四次、五次握手，那是因为三次就足够，三次握手已经可以处理历史连接建立的请求和确认双方的序列号，再多次数的握手就是多余的。

四次挥手流程

1. 客户端发起断开连接请求（也可以是服务端断开连接请求），发送一个FIN标志位为1的报文，代表客户端请求断开连接，此时客户端的状态变成FIN_WAIT_1。
2. 服务器接收到断开连接的请求报文后，返回一个ACK标志位位1的报文，此时服务端的状态变为CLOSE_WAIT。
3. 客户端接收到响应报文之后，状态变成FIN_WAIT_2，然后等待服务端传输完剩下的数据后，发送FIN标志位为1的报文。
4. 服务端等传输完数据后，就会发送一个FIN标志位为1的报文。
5. 客户端接收到这个FIN标志位为1的报文后，会返回一个ACK标志位为1的报文，然后进入TIME_WAIT状态，等待两个MSL（报文最大生存时间），然后进入CLOSE状态，连接真正关闭。
6. 服务端接收到客户端返回的这个FIN标志位为1的报文，就会进入CLOSE状态，连接关闭。

TIME_WAIT 为什么要等待 2MSL

当主动断开连接一方（也就是上面的client）最后一个ACK数据包发送的时候丢失了，被动断开连接一方（也就是上面的server）就会重新发送FIN报文。

等待2MSL目的就在于出现这种情况的时候，主动断开连接一方保证可以接收到被动断开连接一方重发的FIN报文。

如果等待的时长不足2MSL，那么就无法保证能够接收到被动断开连接一方重发的FIN报文；不等待更长的时间，那是因为如果此时网络不可靠，在2MSL时长内也无法让主动断开连接一方接收到被动断开连接一方重发的FIN报文，那么等待再长的时间也是没有意义的，比如现在是丢包率百分之一百的网络，等再长的时间也是白等。

为什么握手是三次，挥手是四次？

因为主动断开连接的一方发送断开连接的请求时，可以确定主动方已经没有数据需要传输了，但是无法确定被动断开连接一方是否已经没有数据需要发送。因此如果当被动方接收到主动方发送的FIN报文之后，返回一个ACK报文给主动方之后，还需要把剩下的数据发送完。

此时主动方虽然不能再发送数据，但是还可以响应ACK报文，所有还是可以接收被动方发送的数据。