TCP半连接队列与全连接队列 描述 TCP半连接队列（SYN队列）和全连接队列（Accept队列）是操作系统中TCP协议栈为了实现三次握手而维护的两个重要队列。理解这两个队列对于诊断服务器连接问题、分析网络性能瓶颈以及防范SYN Flood攻击至关重要。 知识点详解 队列的诞生：三次握手回顾 要理解这两个队列，我们必须先回顾TCP三次握手的过程： 第一步： 客户端向服务器发送一个SYN报文，表示请求建立连接。 第二步： 服务器收到SYN后，会回复一个SYN-ACK报文，表示同意建立连接。 第三步： 客户端收到SYN-ACK后，再回复一个ACK报文，连接正式建立。 问题在于，服务器在发送完SYN-ACK之后，到收到客户端的最终ACK之前，存在一个时间窗口。在这段时间里，这个连接处于一个“中间状态”。为了管理这些处于中间状态的连接，操作系统创建了“半连接队列”。 半连接队列（SYN Queue） 定义： 当服务器收到客户端的SYN报文并回复SYN-ACK后，它会将这个连接请求放入一个专门的队列，这个队列就是 半连接队列 。此时，连接的状态是 SYN_RCVD 。 作用： 临时存放那些已经进行了第一次和第二次握手，但尚未完成第三次握手的连接信息。 队列长度限制： 队列的长度是有限的，由操作系统参数决定（在Linux中，通常是 /proc/sys/net/ipv4/tcp_max_syn_backlog ）。设置队列长度是为了防止资源被耗尽。 常见问题 - SYN Flood攻击： 恶意攻击者会伪造大量的IP地址，只发送第一次握手的SYN包，但不回复第三次握手的ACK。这会导致服务器的半连接队列迅速被占满，使得正常的连接请求无法进入队列，从而实现拒绝服务攻击。为了应对此问题，Linux提供了 syncookies 机制。当启用 syncookies 后，如果半连接队列满了，服务器会根据SYN包计算出一个特殊的cookie值并放在SYN-ACK报文中发出，而不会在队列中分配空间。只有当服务器收到携带有效cookie的ACK报文时，才会真正分配资源建立连接，从而绕过了队列长度的限制。 全连接队列（Accept Queue） 定义： 当服务器收到客户端的第三次握手ACK报文后，内核会完成连接的建立，并将这个已建立的连接从半连接队列中移出，放入另一个队列，这个队列就是 全连接队列 。此时，连接的状态是 ESTABLISHED 。 作用： 存放那些已经完成三次握手、但尚未被服务器上的应用程序（如Nginx, Apache）通过 accept() 系统调用取走的连接。 队列长度限制： 全连接队列的长度取决于两个参数中的较小值： net.core.somaxconn ： 系统级别的最大队列长度参数。 应用程序调用listen()函数时传入的backlog参数 ： 例如，在Nginx配置中的 listen 80 backlog=2048; 。 常见问题 - 队列溢出： 如果应用程序处理连接的速度跟不上新连接建立的速度，全连接队列就会被填满。当队列已满时，服务器内核会如何处理新的连接请求，取决于系统的TCP实现（如Linux的 net.ipv4.tcp_abort_on_overflow 参数）： 如果设置为0（默认），服务器会直接忽略掉客户端发来的ACK报文，假装没收到。过一段时间后，客户端会因为收不到任何响应而超时重传ACK，给服务器一个补救的机会。 如果设置为1，服务器会直接回复一个RST报文重置连接，这会导致客户端报错（如 "Connection reset by peer"）。 总结与关联 你可以将这两个队列想象成一个银行办理业务的流程： 半连接队列 就像 “取号排队” 。客户取了号（发送SYN），大堂经理给了你一个等待号（回复SYN-ACK），你就在等候区排队。这个等候区就是半连接队列。 全连接队列 就像 “业务办理等待区” 。叫到你的号了（完成三次握手），你从等候区移动到了柜台前的座位（进入全连接队列），等待柜员（应用程序）正式为你服务（调用 accept() ）。 通过理解这两个队列，你就能更深入地分析服务器在高并发场景下可能出现的连接超时、连接重置等问题，并知道如何通过调整系统参数和应用程序配置来进行优化。