一、三次握手

三次握手——示意图

基本流程：
客户端发送SYN报文，发起握手请求，
服务端接受到请求，发送SYN，ACK 报文，告诉客户端自己收到了请求
客户端接受到服务端返回的信息，再发送报文，告诉服务端自己收到了

关于SYN、ACK

SYN：Synchronize Sequence Numbers 同步序列编号
ACK：Acknowledge character 确认字符

seq:sequence number 表示当前发送方的编号
ack:acknowledge number 表示当前发送方希望接收方下一次发送的seq是多少
具体可看参考的第二篇文章：TCP协议中的seq/ack序号是如何变化的？——geekartt

为何是三次，而不是两次、四次

为什么不是2次

在创建连接时，前两步时是确定有的，无法省略。
关于第三步，如果没有第三步的请求，那么当第一步的请求在第二步发送时就已经过期了，那么服务端就会一直在等待客户端的请求，从而造成浪费资源。

为什么不是4次

多了没必要，三次已经足够完成客户端和服务端各自的确认步骤

二、四次挥手

四次挥手——示意图

基本流程：
客户端向服务端发起挥手请求，进入wait1(不再主动发送请求，等待确认服务端信息)
服务端接受请求，响应，发送ACK报文，告知客户端知道了

中间有段等待时间（因为服务端接受到挥手请求时，存在其他数据需要处理发送，没法立即停止，需要都处理完了，才进行停止，再告诉客户端可以停止了）

服务端进入LAST-ACK状态，发送报文告知客户端要关闭了
客户端接受服务端报文，响应ACK报文，告知服务端自己接受到了
服务端关闭连接

客户端等待 2个MSL
（ps:MSL——Maximum Segment Lifetime，报文最大生产时间，即超过这个时间后，客户端没有接收到服务端的消息，那么服务端就收到了之前客户端发送的ACK报文）

客户端关闭连接

为什么需要4次

可能有人疑问为什么不是像握手一样是3次，而是变成了2次2次？
其中关键可以理解成为什么需要中间的那段等待时间，如果没有那个等待时间，那第2次和第3次似乎可以合并成一次

上面也说了，等待时间是为了给服务端有缓冲时间处理之前已经在发的消息的，但服务端又不能让客户端等太久，所以接收到客户端的挥手请求，先发个ACK报文告诉客户端我知道了，等会就处理。

为什么需要等待，为什么是2个MSL

1.如果不等待的话，客户端直接关闭，然后又重启了，但服务端之前并没有关闭成功，又发送了一些消息过来，客户端这时接收到数据，有点懵（明明没有发送过请求），可能会造成数据混乱
2.需要2个MSL是因为第一个MSL时间用于判断服务端接收到了之前发送的ACK报文；第二个MSL是用于判断客户端不会再接收到服务端的报文（即服务端是不是收到ACK后真的关闭了）

参考：
1.(建议收藏)TCP协议灵魂之问，巩固你的网路底层基础——神三元
 2.TCP协议中的seq/ack序号是如何变化的？——geekartt
3.TCP协议中Seq、Ack的变化规律