简单理解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

推荐：
http://www.javashuo.com/article/p-nyzvsklm-gw.html
https://blog.csdn.net/sssnmnmjmf/article/details/68486261