简单理解TCP的三次握手与四次挥手

seq（消息序号）：第一次请求时，随机生成一个值,而后每次+1
ack（确认序号）：接收上一条信息的seq+1
SYN：发起一个新连接的请求时，为1
FIN：释放一个连接的请求时，为1
ACK:与ack不同，TCP协议规定，当连接建立后所有报文的ACK必须为1

三次握手：

1. A-> ACK=0,SYN=1,seq=x;（请求连接）
2. B-> ACK=1,SYN=1,ack=x+1,seq=y;（响应请求连接）
3. A-> ACK=1,ack=y+1,seq=x+1（确认接收响应，建立连接）
   

四次挥手：

1. A-> ACK=0,FIN=1,seq=u;（请求释放）
2. B-> ACK=1,seq=v,ack=u+1;（收到请求，响应等待）
3. B-> ACK=1,FIN=1,seq=w,ack=u+1 ;（完成，响应结束释放）
4. A-> ACK=1,seq=u+1,ack=w+1;（响应彻底释放）
   

• 为什么要采用三次握手，两次不行吗？
  第三次握手用于确保服务端接收到的连接请求是有效的。那么什么时候会出现“无效连接请求”呢？

  “已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据，造成server的资源被浪费。

• 为什么TCP释放连接时TIME_WAIT要等待2ms的时间

  第一，为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。
  第二，A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

  摘自–《计算机网络》第五版

https://zhuanlan.zhihu.com/p/21940234

推荐：
https://blog.csdn.net/oney139/article/details/8103223
https://blog.csdn.net/sssnmnmjmf/article/details/68486261