这是一个创建于 2078 天前的主题，其中的信息可能已经有所发展或是发生改变。
因为 TCP 握手第三步的 ACK 可以丢包，所以客户端无法知晓 TCP 连接是否真正建立。只知道如果服务端重发第二步的包，连接建立失败。然而，服务端的第二步包重发也是可以丢包的。所以 TCP 连接是否真正建立，对于客户端来说是薛定谔问题。
那么，真正让客户端知道 TCP 是否连接正常，客户端必须发一个正常的数据包，并且得到服务端的确认，即最关键的第四步确认，客户端才知道 TCP 连接建立是成功的。
在这种情况下，客户端省掉第三步 ACK，直接发一个或多个正常的数据包，并且服务端的连接成功确认机制修改为接收到客户端第一个数据包，那么 TCP 连接也是可以正常建立的。
那么，是不是说，第三步 ACK 真的可以省略呢？或者说，真正建立连接的过程其实是至少四步 ？
那么，真正让客户端知道 TCP 是否连接正常，客户端必须发一个正常的数据包，并且得到服务端的确认，即最关键的第四步确认，客户端才知道 TCP 连接建立是成功的。
在这种情况下，客户端省掉第三步 ACK，直接发一个或多个正常的数据包，并且服务端的连接成功确认机制修改为接收到客户端第一个数据包，那么 TCP 连接也是可以正常建立的。
那么，是不是说，第三步 ACK 真的可以省略呢？或者说，真正建立连接的过程其实是至少四步 ？
 |
1
huangzhe8263 2019-03-16 23:54:17 +08:00 via Android  1
第三步如果没记错是为了防止第二步的包在网络中滞留之后重发导致会开启多个连接吧
|
 |
2
kyuuseiryuu 2019-03-17 00:00:37 +08:00 1
客户端第三步发的 ACK 是让服务端知道能够连接
服务端第二步发的就是让客户端知道能够连接并且想让客户端告诉服务端能不能连接 原文的第二段，TCP 的第一步和第二步就已经做掉了。 最后，这个发在胡思乱想节点比较好。 |
 |
3
mondeo 2019-03-17 00:01:29 +08:00 via iPhone 1
第三部就是 ack+data 了啊
|
 |
4
mimzy 2019-03-17 00:04:20 +08:00 via Android 3
|
 |
5
lhx2008 OP @mondeo 虽然说语意上是需要 ACK，但是 ACK+DATA 这种设计更说明了我直接发 DATA，起到的效果可以是一样的
|
 |
6
lyog 2019-03-17 00:50:48 +08:00 via iPhone 1
回楼上疑问：tcp 是累加 ack，单纯的丢失一次纯 ask 不会影响通讯。回帖子疑问：第二步一直丢包的话，会触发超时，然后发送 RST 包强制关闭连接，并没有薛定谔
|
 |
7
vansl 2019-03-17 00:58:42 +08:00 via iPhone 1
感觉还是一楼说的那个最基本的滞留问题。第一个包是滞留包，导致第二个包不是有效的，那么何谈可以省略第三个包而直接发数据？
|
 |
8
lqs 2019-03-17 01:02:42 +08:00 via iPhone 1
有些协议（如 ftp ssh mysql 等）是服务端先发数据，服务端需要等到第三个包确认客户端有效后才能开始发数据。
|
Select Language