TCP四次挥手及常见问题_tcp 握手以后只能收数据 不能发

TCP四次挥手图解

四次挥手过程网上都很详细，简单描述一下：

1、一次挥手：

 客户端想要释放连接，向服务器端发送一段 TCP 报文，其中：

• FIN = 1；seq = u；
• 客户端进入 FIN-WAIT1（半关闭）阶段，只收不发（只是不发数据，但能发ACK确认报文）。
  

2、二次挥手：

 服务器收到客户端的请求，回应客户端，进入 CLOSE-WAIT 阶段，其中：

• ACK = 1；seq = v；ack = u+1。
• 客户端收到从服务器端的TCP报文后，进入 FIN-WAIT2 阶段。

3、三次挥手

 服务器端经过 CLOSED-WAIT 阶段处理好数据后，向客户端发出一段释放连接 TCP 报文，其中：

• FIN = 1，ACK = 1；seq = w；ack = u+1。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
• 确认号为 ack = u+1。表示是在收到客户端报文的基础上，将其序号seq值加1作为本段报文确认号ack的值。
  
  
   为什么不把第三次挥手不和第两次挥手合并，即建立连接时一起传输（三次握手），释放连接时却要分开传输（四次挥手）？
• 建立连接时，服务器端进入“握手”阶段不需要任何准备，可直接返回SYN和ACK报文，开始建立连接。
• 释放连接时，服务器收到客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段处理完数据之后，才能返回FIN释放连接报文。
• 简而言之，四次挥手多了一个数据处理时间，需要处理完后再释放。

4、四次挥手

 客户端收到服务器端释放连接请求，进入TIME-WAIT阶段，并向服务器端发送一段报文回应，其中：

• ACK = 1；seq=u+1；ack = w+1。
• 确认号为 ack = w+1；表示是在收到服务器端报文的基础上，将其序号seq值作为本段报文确认号ack的值。
• 客户端在TIME-WAIT阶段等待2MSL后CLOSED结束。

为什么要等2MSL?
 MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。


 为了保证客户端发送的最后一个ACK报文段能够到达服务器。
 因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
 所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

了解知识(了解即可)

 seq序号：用来标记数据段的顺序，TCP 把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生（seq = u），给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

 ack确认号：期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

 确认ACK标志位：仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。

 同步SYN标志位：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

 终止FIN标志位：用来释放一个连接。当FIN=1时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。

PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。
1

参考：
https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
https://blog.csdn.net/qq_38950316/article/details/81087809
https://blog.csdn.net/qq_43584847/article/details/106224209