为什么是三次握手？
为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误。
建立很多无效的连接，浪费资源
客户端收到来自服务端的报文后，还需要再次发送确认报文来建立连接。
三次握手
第一次握手
Client将标志位SYN置1，随机产生一个值seq=J,并将数据包发给Server
Client进入SYN_SENT状态，等待Server确认
第二次握手
Server收到数据包后标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置1，随机产生一个值,并将数据包发给Client确认连接请求，Server进入SYN_RCVD状态
第三次握手
Client收到确认后若ACK为1，则将该数据包发送给Server，Server检查ACK为1则连接建立成功，Client与Server进入ESTABLISHED状态完成三次握手，可以传输数据
第一次握手：
Client什么都不能确认
Server确认了对方发送正常
第二次握手：
Client确认：自己发送/接收正常，对方发送/接收正常
Server确认：自己接收正常 ，对方发送正常
第三次握手：
Client确认：自己发送/接收正常， 对方发送/接收正常
Server确认：自己发送/接收正常，对方发送/接收正常
四次挥手
第一次挥手：
Clien发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手：
Server收到FIN后，发送一个ACK给Client,Server进入CLOSE_WAIT状态。
第三次挥手：
Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
第四次挥手：
Client收到FIN后，Client进入TIME_WAIT状态，发送ACK给Server，Server进入CLOSED状态，完成四次握手。
建立连接
因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
关闭连接
当收到对方的FIN报文时，仅表示对方不再发送数据但还能接收收据，我们也未必把全部数据都发给了对方，所以我们可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方表示同意关闭连接。因此我们的ACK和FIN一般会分开发送。
上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图
为什么需要TIME_WAIT状态
1、可靠的终止TCP连接
2、保证让迟来的TCP报文段有足够的时间被识别并丢弃
参考资料：
https://blog.csdn.net/yu876876/article/details/81560122?ivk_sa=1024320u