为什么tcp连接终止需要4路握手？

Question

建立连接时，有：

客户端------ SYN ----->服务器

客户端<--- ACK / SYN ----服务器----①

客户端------确认----->服务器

终止时，有：

客户端------ END ----->服务器

客户端<----- ACK ------服务器----②

客户端<----- END ------服务器----③

客户端------确认----->服务器

我的问题是为什么②和③不能设置在同一个包中，如①在一个包中设置的ACK和SYN ???

Answer 1

• 在三向握手（连接设置）中：服务器必须确认（ACK）客户端的SYN，服务器还必须发送自己的SYN，其中包含服务器将在连接上发送的数据的初始序列号。 这就是服务器在单个段中发送其SYN和客户端SYN的ACK的原因。
• 连接终止：由于每个方向都需要FIN和ACK，因此终止连接需要四个段。 （2）表示TCP收到的FIN（第一段）被确认（ACK） （3）意味着稍后收到文件结尾的应用程序将关闭其套接字。这导致其TCP发送FIN。 然后最后一段将意味着接收此最终FIN的系统上的TCP确认（ACK）FIN。

Answer 2

经过谷歌搜索后，我认识到四向实际上是两对双向握手。

如果终止是REAL四向动作，则2和3确实可以在同一个数据包中设置为1。

但这是一个两阶段的工作：第一阶段（即第一次双向握手）是：

Client ------FIN-----> Server

Client <-----ACK------ Server

此时客户端已处于FIN_WAIT_2状态，等待来自服务器的FIN。作为双向和全双工协议，目前一个方向已经崩溃，客户端必须等待另一个“半双工”终止。

当来自服务器的FIN被发送到客户端时，客户端响应ACK以终止连接。

结束语：2和3不能合并为一个包，因为它们属于不同的状态。

参考文献：

1. http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
2. http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm
3. http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm

Answer 3

来自维基百科 - “当主机A发送FIN并且主机B回复FIN和ACK（仅将2个步骤合并为一个）并且主机A回复ACK时，也可以通过3次握手终止连接。 [14]”

资源：

维基百科 - https://en.wikipedia.org/wiki/Transmission_Control_Protocol

[14] - Tanenbaum，Andrew S.（2003-03-17）。计算机网络（第四版）。普伦蒂斯霍尔。 ISBN 0-13-066102-3。

Answer 4

如果从编码的角度观察到这一点，那么采用4路比3路更合理，尽管两种都是可能的使用方式。

当一方要终止连接时，对等方可能有多种可能性或状态。至少有一个是正常的，一个是在发送或接收，一个是在这个启动之前突然处于断开状态。

终止的方式应至少考虑三个以上，因为它们都有很高的可能性发生在现实生活中。

因此，基于上述方法找出原因变得更加自然。如果对等体处于脱机状态，则客户端很容易通过深入研究在过程中捕获的分组内容来推断对等状态，因为无法从对等体接收到第一个ack消息。但是如果将两个消息组合在一起，则客户端很难知道对等体为什么不响应，因为不仅脱机状态可能导致数据包丢失，而且服务器端处理过程中的各种异常也可能让这件事成真。更不用说客户端需要等待很长时间才能超时。通过额外的1条消息，这两个问题可能会变得更容易从客户端处理。

它的原因看起来像编码，因为消息中包含的信息就像代码日志。