TCP 三次握手第三步的 ACK 是否可以省略？

[lhx2008]

因为 TCP 握手第三步的 ACK 可以丢包，所以客户端无法知晓 TCP 连接是否真正建立。只知道如果服务端重发第二步的包，连接建立失败。然而，服务端的第二步包重发也是可以丢包的。所以 TCP 连接是否真正建立，对于客户端来说是薛定谔问题。

那么，真正让客户端知道 TCP 是否连接正常，客户端必须发一个正常的数据包，并且得到服务端的确认，即最关键的第四步确认，客户端才知道 TCP 连接建立是成功的。

在这种情况下，客户端省掉第三步 ACK，直接发一个或多个正常的数据包，并且服务端的连接成功确认机制修改为接收到客户端第一个数据包，那么 TCP 连接也是可以正常建立的。

那么，是不是说，第三步 ACK 真的可以省略呢？或者说，真正建立连接的过程其实是至少四步 ？

[huangzhe8263]

第三步如果没记错是为了防止第二步的包在网络中滞留之后重发导致会开启多个连接吧

[kyuuseiryuu]

客户端第三步发的 ACK 是让服务端知道能够连接

服务端第二步发的就是让客户端知道能够连接并且想让客户端告诉服务端能不能连接

原文的第二段，TCP 的第一步和第二步就已经做掉了。

最后，这个发在胡思乱想节点比较好。

[mondeo]

第三部就是 ack+data 了啊

[mimzy]

https://mp.weixin.qq.com/s/NIjxgx4NPn7FC4PfkHBAAQ

[lhx2008]

@mondeo 虽然说语意上是需要 ACK，但是 ACK+DATA 这种设计更说明了我直接发 DATA，起到的效果可以是一样的

[lyog]

回楼上疑问：tcp 是累加 ack，单纯的丢失一次纯 ask 不会影响通讯。回帖子疑问：第二步一直丢包的话，会触发超时，然后发送 RST 包强制关闭连接，并没有薛定谔

[vansl]

感觉还是一楼说的那个最基本的滞留问题。第一个包是滞留包，导致第二个包不是有效的，那么何谈可以省略第三个包而直接发数据？

[lqs]

有些协议（如 ftp ssh mysql 等）是服务端先发数据，服务端需要等到第三个包确认客户端有效后才能开始发数据。

[vansl]

@vansl 收回发言同意八楼。

[lhx2008]

@lyog 第三步 ACK 发出去之后，如果不再进行发包，那么这个时候拔网线，客户端是认为 TCP 连接已经建立了还是没建立？

[julyclyde]

@lhx2008 你不要自己添加干扰项。四层是否建立，和二层通不通一点关系都没有