通俗理解 三次握手四次挥手（老友依恋式）

首先我们来看一张图

该图描述的意思：

1. A：你好老哥，我要从你和你建立连接，向B服务端发送请求连接的请求，然后等待对面老哥的回答（其中包含自己要与他确认连接的同步序列字段：可以理解为，咱们两人的手机号码（syn）；进入syn等待状态）
2. B：我收到了你的请求（利用ACK =1 这个标志来告知），但是我要确认这个请求到底是不是你的，所以呢我把你给我的 电话号码在给你发回去同时把我的连接方式（同步序列syn）也发过去（总称为:syn+ack ack用于确认 syn用于发送自身的状态）
3. A:收到服务端的包，告知他我收到你的了，你说的信息都对，咱们两手握手吧（进入了established状态）

理论方面：

在三次握手中，服务器维护这一个未连接队列，专门为了步骤2、3，也就是一个由客户端的syn包（连接信息）组成的队列；第一步的syn包被丢入该队列，然后向客户端发送确认包，该条目会被标志处于syn—recv状态，当客户端响应确认之后，就会将该条目从这个队列中删去

参考：https://blog.csdn.net/qq_18425655/article/details/52163228
字段解释：

两个序号和三个标志位：

（1）序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
（A）URG：紧急指针（urgent pointer）有效。
（B）ACK：确认序号有效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）SYN：发起一个新连接。
（F）FIN：释放一个连接。

为什么要3次握手

我们假定第一次发送的请求因为网络延迟很慢才到达服务端，然后客户端以为这服务器居然不叼我，然后默默的关闭的等待连接的请求，走开了（好比追女神）；但事实呢？女神（服务器）是因为各种各样的原因，很晚才看到，然后说我接受你了，统一你的要求咱们两结婚吧！但是，A早已经远走高飞，这个请求A完全不会收到（在第二次握手，服务端打开连接，等待客户端的响应），那么女生呢，以为对方收到了，就会一直等待，这样B的资源就会被浪费的（创建连接的时候，空间浪费以及端口消耗）；
但是如果说是三次连接，等待客户端的确认在建立连接，就不会发生，女神（服务端）同意了，但是A缺一直没有下一步的动作，导致资源浪费；

四次挥手

这和有礼貌的好友道别一样：（a：客户端 b:服务端）
1、一开始A想要回家离开，但是呢？怕B还有事情要交代，那么呢？只好先想B打招呼，我要走了，请求停止交谈（此时，a到B的连接没有断开，依旧可以进行通信）；
2、同意A的请求，说好的，但是我这里可能还有一些话（数据）没说完。等我说完你再走。
3、B说完最后的话语（数据），告知好了，你我可以散伙了（B此时等待回应就关闭该连接 （被告知方））
4、A说好的，知道了，88；（B得知后走开了，关闭了自己的连接）

最后一个阶段4会发生A依依不舍的状态（time_wait）：
为啥呢？他怕B万一突然回头还有话呢（网络延迟高，最后还有一些数据过一段时间才收到）。为什么是要等待2MSL呢？
由于存在最后一次确认关闭的请求丢失，所以设置最大报文段生存时间，用来重发可能丢失的ack报文。PS:超时也消失了，无所谓发不发

当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次挥手”。

第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

为何要四次挥手

那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FINWAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
CLOSED: 表示连接中断。