Question

建立连接时，有：

客户------ SYN -----＆gt;服务器

客户＆lt; --- ACK / SYN ----服务器----①

客户------确认-----＆gt;服务器

当终止时，有：

客户------ FIN -----＆gt;服务器

客户＆lt; ----- ACK ------服务器----②

客户＆lt; ----- FIN ------服务器----③

客户------确认-----＆gt;服务器

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

Answer 1

经过Google搜索后，我发现四方实际上是两对双向握手。

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

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

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

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

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

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

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

参考文献：

Answer 2

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

Answer 3

来自Wikipedia-“当主机A发送FIN且主机B用FIN＆ACK（仅将2个步骤合并为一个）答复并且主机A答复时，也可以通过3次握手来终止连接。 ACK。[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 msg，客户端可以通过深入研究过程中捕获的数据包内容来推断对等状态。但是，如果将这两个消息组合在一起，则客户端将很难知道为什么对等方不响应，因为不仅脱机状态可能导致数据包丢失，而且服务器端处理过程中的各种异常都可能做到这一点。更不用说客户端需要等待大量时间直到超时。使用附加的1条消息，这两个问题可能会变得更加容易从客户端处理。

之所以看起来像是编码，是因为消息中包含的信息就像代码日志一样。

Answer 5

我认为2和3当然可以合并，但是不够灵活，因为不是原子合并。
第一个FIN1 C到S的意思是并且仅意味着：我将以交流的方式结束。第一ACK1 S到C表示对FIN1的响应。好的，我知道您的频道已断开连接，但是对于我的S（服务器）方式连接，我不确定。也许我的接收缓冲区尚未完全处理。我需要的时间不确定。因此2和3不适合合并。只有服务器有权决定何时可以断开其连接方式。

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

5 个答案: