学习：TCP/UDP协议分析（TCP四次挥手）

前言：记录关于传输层TCP协议的四次挥手

参考文章：https://www.jianshu.com/p/ca64764e4a26

根据：https://www.cnblogs.com/zpchcbd/p/12291007.html，大家都可以大致了解了，那么直接可以讲了

有关TCP标志位Flags

SYN标志：建立连接的请求标志位 

ACK标志：针对请求确认的应答标志位

PSH(push传送) 

FIN标志：请求断开连接的标志位

RST(reset重置) 

URG(urgent紧急)

Sequence number(顺序号码) 

Acknowledge number(确认号码)

TCP四次挥手抓包分析

大家要先知道TCP连接是双向的，在四次挥手中，前两次挥手用于断开一方方向的连接，后两次挥手用于断开另一方的方向的连接。

注意的是：谁先断不一定，比如HTTP请求中，若connection 模式为CLOSE，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求。

第一次挥手： 客户端先发送一个带有FIN（结束标志位）以及随机Sequence number的数据包，然后客户端会进入FIN-WAIT-1状态

第二次挥手： 服务端收到后，返回一个带有ACK(确认标志位)的数据包，其中Acknowledge number为第一次挥手数据包的SEQ+1和再次随机的Sequence number，服务端会进入CLOSE-WAIT（关闭等待）状态，客户端收到该应答后，进入FIN-WAIT-2状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

注意：第二次挥手完成后，客户端到服务端方向的连接已经释放，但服务端到客户端方向的连接仍然存在，服务器若发送数据，客户端依然要接受

第三次挥手： 所以此时服务端继续发送一个数据包为ACK确认标志位、FIN结束标志位、Acknowledge number为第一次挥手数据包的SEQ+1，再次随机的Sequence number给客户端，服务端就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

第四次挥手： 客户端收到服务端的结束数据包之后，向服务器发送一个应答包ACK确认标志位、Sequence number为第三次挥手的Acknowledge number、当前的Acknowledge number为第三次握手的SEQ+ 1，客户端就进入了TIME-WAIT（时间等待）状态，这个期间TCP连接还未释放，若该时间段内没有服务端的重发请求的话，客户端就进入CLOSED状态，服务端只要收到了客户端发出的确认，立即进入CLOSED状态。

这里也可以看出服务端比客户端早结束通信过程，但并不是一定！

问题1：为什么握手是三次，而挥手时四次？

我这里举个场景，就比如打电话，A用户给B用户打电话，此时要开始进行结束通话了，A用户给B用户说我要挂电话了，然后B用户说我知道了，那么此时如果A用户接收到了就直接挂了电话，那么这种情况合适吗？

更好的情况下应该是这样子的，A用户给B用户说我要挂电话了，然后B用户说我知道了，那么此时B用户这个时候可能还会说些啥，然后B用户说你挂电话吧，然后A用户才挂电话，这样子的话就避免了可能B用户在临时突然还有什么话要说却被挂断的事情发生了

再举个例子就是，A下载B用户的数据，然后A告诉B用户说我要下了，然后B用户说我知道了，那么此时B用户应该是把该传输的数据传输完，然后再发个信号给用户A，此时A用户才真正的结束