文章总结： 服务端因Established_queue满而丢弃客户端第三次ACK，迫使连接滞留Syn-queue并周期性重传SYN-ACK，待应用accept腾出空位后再完成握手；抓包显示客户端始终未回应该重传且数据包也超时未重传，需排查客户端协议栈或中间代理异常。 综合评分： 78 文章分类： 网络安全,漏洞分析,应急响应,实战经验,安全运营

请教个问题，三次握手时候，服务端接收到了客户端ACK，为什么还会重发SYN-ACK呀?

原创

车小胖谈网络

车小胖谈网络

2026年1月8日 17:26 上海

图片为服务端抓包图，客户端的抓包数据一样。

服务器端的TCP的listen socket，有2个queue。

Syn-queue，linked list of connecting socket，接收Client的SYN，状态=SYN_Received。

Established_queue, linked list of established socket，完成三次握手，状态=Established。当application 调用accept()，将first 移出链表。

如果application 的accept()不够快，造成Established_queue满，即使收到client的第三次ACK，Server端的TCP发现Established_queue满，直接丢弃ACK，当作什么也没有发生。

因为如果不丢，这个TCP连接将完成三次握手，并从Syn-queue 移到Established_queue，后者已经满员，无法移动。势必要造成该TCP连接的状态的丢失。

而丢弃ACK，该连接依然滞留在Syn-queue。当application用accept移走一个TCP连接，势必会空出一个名额。服务器只要重传SYN-ACK，当client的ACK再次到来时，就可以移到Established_queue里了，这个如意算盘就是这么打的。

图片中的Server没有问题，一直使用超时定时器（1秒、2秒、4秒。。。）在重传。可是Client没有发出ACK，一次都没有，这是一个问题。

另外，Client发出长度为42 bytes的数据，到抓包结束也没有收到ACK，超过10秒一直没有重传这42 bytes，这是另外一个问题。

尝试增加backlog数量，以增加Established_queue的长度，看看能否顺利建立TCP连接。

但是，Client端的TCP是有问题的，为何超时不重传？看了一下client和server使用IPv6的FE80地址段，应该处于同一个link的通信，是否Client与Server之间的通信还有中间代理的存在？ 但是通过Client端的抓包显示，重传包，包括data的重传以及ACK都没有发出，这是问题的关键。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：车小胖谈网络 车小胖谈网络《请教个问题，三次握手时候，服务端接收到了客户端ACK，为什么还会重发SYN-ACK呀?》