参考链接：
（1）从 TCP 三次握手说起 -- 浅析 TCP 协议中的疑难杂症 https://www.infoq.cn/article/sF6CgHVC20rH635NvjNW
（2）TCP的三次握手与四次挥手（详解+动图）https://blog.csdn.net/qzcsu/article/details/72861891
（3）TCP三次握手与四次挥手 https://www.cnblogs.com/welan/p/9925119.html
（4）让研发人员紧张的“故障神经线” https://time.geekbang.org/column/article/144908
一、相关的变量说明
seq（序列号）：占4个字节。用来标记数据段的顺序。TCP给发送的所有数据字节都编上序号，第一个字节的序号由本地随机生生。防止被人找到规律。是数据包本身的序列号。
ack（确认号）：占4个字节。期待收到对方下一个报文段的第一个数据字节的序号。因此ack=最后一个字节的seq+1
ACK（确认）：占1个比特位。仅当ACK=1时，确认号字段才有效。ACK=0表示无效
SYN（同步）：连接建立时用于同步序号。
当SYN=1，ACK=0时：表示这是一个连接请求报文。若同意连接，则在响应报文中使用SYN=1，ACK=1。
因此SYN=1表示这是一个连接请求，或者连接响应报文。只有在TCP建立连接的时候才会被置为1。当握手完成后SYN置为0.
FIN（终止）：用来释放一个连接。
二、三次握手图解
三次握手过程
（1）客户端主动发起连接请求，SYN=1，并且自生产生随机序列号x。
（2）服务端收到连接请求后，打开TCP连接，并同步告知客户端，SYN=1，ACK=1、
（3）客户端收到ACK后，异步告知服务端ACK，并且可以在此次ACK中携带数据。连接建立。
问题（1）：为什么还要第三次的ACK？
原因是因为两次握手不能保证安全问题。有可能服务端存在异常导致TCP连接并未建立成功，此时客户端直接传送数据过来的话，会浪费网络资源，无法保证传输的可靠性。
但是再增加一次握手就完全没有必要了，因为双方都已经确认成功了，再握手就画蛇添足了。
四次挥手图解
四次挥手过程
（1）主动关闭方发送FIN
（2）被动关闭方接收到FIN后发送该FIN的ACK。此时服务端不再接收客户端发来的数据。
（3）等被动关闭方的数据包被完全传输完毕，被动关闭方发送FIN。
（4）主动关闭方收到被动关闭方的/FIN后，发送该FIN的ACK。并且在等待2MSL之后完全关闭自己的连接。服务端在收到这个ACK后完全关闭自己的TCP连接。否则服务端将一直重复3的操作，一直询问客户端是否要关闭，直到收到4的ACK回复位置。
注意2，3步骤可能合为一步。当1过程的FIN请求过来的时候，服务端恰好没有数据需要传送给客户端，此时直接进行3步骤即可。
（1）问题A：为什么服务端需要等到客户端发送了ACK之后才能关闭连接？也就是为什么要有4步骤？
回答：因为如果3后直接关闭服务端，那么服务端回复的FIN包可能由于网络原因无法达到客户端，导致客户端的TCP连接一直被占用。浪费客户端的连接资源。
（2）问题B：为什么客户端要等待至少2MSL之后才能关闭TCP连接？不能立即关闭么？
回答“不能。
因为4步骤发送ACK包到服务端的过程中，可能由于网络原因，导致丢包，使得服务端没有接收到这个ACK消息，而此时客户端的TCP连接已经关闭，服务端就会一直请求服务端得不到响应，那么服务端上的TCP连接就会长时间得不到释放，浪费宝贵的连接资源。而2MSL（报文生存时间）是数据包请求与响应一个来回的时间，在这个时间段内刚好能够满足收到服务端的响应。
假如客户端发送ACK'后又重启了连接，并且使用相同的端口以及地址，那么就有可能收到服务端重发的FIN请求，对新连接造成影响（新连接的SYN请求过去之后，因为服务端在一直等待ACK，会认为这个SYN不合法，因此重置连接）