我有一个有多个客户端的服务器。模拟网络拥塞严重。我发现服务器在收到三次握手的 ACK 段后重置了一些 TCP 连接。但是当网络状况良好时不会发生这种情况。
我发现三次握手的ACK比SYN-ACK要晚3.5s左右收到。 是不是因为三次握手SYN-ACK超时？如果SYN-ACK超时，为什么不重新发送SYN-ACK。
感谢您的任何建议。
最佳答案
这看起来与 SYN cookies 有关.
同步 cookie
当 Linux 主机接收到过多的 SYN 流量时，它会激活 SYN cookies 机制。
当启用 SYN cookie 时，服务器通过发出一个 SYN-ACK 段来响应 SYN，其中包含在 TCP sequence 字段中编码的特定数据。在该字段中，它对时间戳、MSS 和两个端点(本地和远程 IP 和端口)的加密哈希以及时间戳进行编码。
这样做是为了让服务器此时不必存储有关连接的任何信息，它只需发送答案并忘记它。
然后，当客户端用它的 ACK 应答时，服务器检查 ack 字段中的散列(客户端的 ack 是服务器的序列)。如果正确，它会创建与存储在该字段中的数据的连接。
SYN cookie 解释了为什么服务器在超时时不重新发送 SYN-ACK 数据包。
但是，为什么收到ACK后就重置呢？
也许客户端(或服务器)位于修改端口的 NAT 后面，并且 NAT 也变得拥塞，因此它无法将最终的 ACK 链接到先前的 SYN，并分配一个新的源端口。当服务器收到它时，它会重置连接(是否启用 SYN cookie 无关紧要)。
或者服务器进程可能没有以连接到达的速度接受连接，内核队列已满，新的队列以这种方式被丢弃。
关于tcp - 收到三次握手的ACK后立即重置TCP，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33026669/