TCP三次握手四次挥手过程理解

SYN:同步请求
ACK:对同步请求的响应
seq:当前数据包序列号
ack:期望对方下一条数据包的序列号

第一次握手: 主机A向B发送连接请求
客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号x,保存在包头的序列号(Sequence Number)字段里。

第二次握手: 主机B对收到的主机A的报文段进行确认
服务器发回确认包(ACK)来应答。即SYN标志位和ACK标志位均为1，同时将确认序号(Acknowledgement Number)设置为客户的初始序号加1，即x+1,并加上自己的初始化序列号seq=y。

第三次握手: 主机A再次对主机B的确认进行确认
客户端再次发送确认包(ACK)应答。ACK标志位为1，并且把服务器发来seq=y序号字段+1,放在确定字段(ack)中发送给对方.并且把自己的序列号+1,即x+1。

1.第一次握手后 服务端知道自己能收到消息 知道客户端能发消息
2.第二次握手后 客户端知道自己能收消息 知道服务端能发消息 知道自己能发消息 知道服务端能到收消息
3.第三次握手后 服务端知道自己能发消息 知道客户端能到收消息

第一次挥手:
客户端向服务端请求断开连接时会向服务端发送一个带有FIN标记的报文段，这里的FIN是FINish的意思。

第二次挥手:
服务端收到客户端发送的FIN后，服务端现在可能现在还有数据没有传完，所以服务端并不会马上向客户端发送FIN，而是先发送一个确认序号ACK，意思是说“你发的断开连接请求我收到了，但是我现在还有数据没有发完，请稍等一下”。

第三次挥手:
当服务端的事情忙完了，那么此时服务端就可以断开连接了，此时B端向A端发送FIN序号，意思是这次可以断开连接了。

第四次挥手:
客户端收到服务端发送的FIN后，会向服务端发送确认ACK，然后经过两个MSL时长后断开连接。

第四次挥手后2MSL的延时：
MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。

假定网络不可靠，那么第四次发送的ACK可能丢失，即服务端无法收到这个ACK，如果服务端收不到这个确认ACK，服务端会一直定时向客户端重复发送FIN，直到服务端收到客户端的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的

为什么要三次握手？

采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：
主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，
顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B
主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，
主机B就一直在等待主机A发送数据，导致主机B的资源浪费。（这就是缺少第三次握手(A再给B确认））

为什么要四次挥手？

试想一下，假如现在你是客户端你想断开跟Server的所有连接该怎么做？第一步，你自己先停止向Server端发送数据，
并等待Server的回复。但事情还没有完，虽然你自身不往Server发送数据了，但是因为你们之前已经建立好平等的连接了，
所以此时他也有主动权向你发送数据；故Server端还得终止主动向你发送数据，并等待你的确认。其实，说白了就是保证
双方的一个合约的完整执行！