概述
如上图所示， 在TCP三次握手中，服务器维护一个半连接队列（sync queue） 和一个全连接队列（accept queue）。
当服务端接收到客户端第一次SYN握手请求时，将创建的request_sock结构，存储在半连接队列中（向客户端发送SYN+ACK，并期待客户端响应ACK），此时的连接在服务器端出于SYN_RECV状态。当服务端收到客户端最后的ACK确认时，将半连接中的相应条目删除，然后将相应的连接放入 全连接队列中， 此时服务端连接状态为ESTABLISHED。 进入全连接队列中的连接等待accept()调用取用。
既然是队列，肯定就有大小，那么当这两个队列满了没有空间了怎么办呢？ 例如如果我们listen()后不去accept() ,那么全连接队列肯定会满的。 我们下面分别对于这两个队列结合试验进行描述。
试验环境：
CentOS Linux release 7.5.1804 (Core)
Linux version 3.10.0-229.4.2.el7.x86_64
syns queue 半连接队列
首先说一下 SYN flooding攻击，为了应对SYN flooding（即客户端只发送SYN包发起握手而不回应ACK完成连接建立，快速填满server端的半连接队列，让它无法处理正常的握手请求），Linux实现了一种称为SYNcookie的机制，通过net.ipv4.tcp_syncookies控制，设置为1表示开启。简单说SYNcookie就是将连接信息编码在ISN(initialsequencenumber)中返回给客户端，这时server不需要将半连接保存在队列中，而是利用客户端随后发来的ACK带回的ISN还原连接信息，以完成连接的建立，避免了半连接队列被攻击SYN包填满。 也就是说，如果开启了syncookies的话（通过 TCP参数 net.ipv4.tcp_syncookies配置 ），半连接队列就相当于是无限大的了。在我的环境中就是默认开启的。
如果我们将syncookies关闭的话，半连接队列的长度将为 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog) ，，此时对半连接填满时的处理策略是 server将 丢弃请求连接的SYN,不回复SYN+ACK,这样就会造成client收不到握手响应，始终处在SYN_SENT状态，经过几次重传后，客户端 connect() 调用失败。
accept queue 全连接队列
全连接队列的长度为 min(backlog, somaxconn)，默认情况下，somaxconn 的值为 128（/proc/sys/net/core/somaxconn），表示最多有 129 的 ESTAB 的连接等待 accept()，而 backlog 的值则是由 int listen(int sockfd, int backlog) 中的第二个参数指定，listen 里面的 backlog 可以有我们的应用程序去定义。 当全连接队列满了后的处理策略基于TCP参数net.ipv4.tcp_abort_on_overflow，在我的机器上默认为0。
- tcp_abort_on_overflow 关闭时
当server收到最后一次ACK时，希望将连接从半连接队列中取出放入全连接队列，但是此时全连接队列已满，此时的策略是 将最后接收到的ACK丢弃，并且根据net.ipv4.tcp_synack_retries定义的次数重新向client发送SYN+ACK， client在接收到重传的SYN+ACK后会认为之前的ACK丢失了进而重传ACK，这样在下次重新接收到ACK后，如果全连接队列有空间了，连接就可以正确完成建立。 如果重传了规定次数后全连接队列中依旧没有空间，那么server会简单终止这次连接（这里简单终止的意思是server并没有像client发送RST表明连接无法建立，而是直接丢弃了，这样就会导致在client中的连接处在ESTABLISHED状态，并一直如此，后面的实验会有涉及，我很困惑为什么要这样设计？ 还是我没有正确理解 ！）。
- tcp_abort_on_overflow 开启时
在收到握手的最后一次ACK后，在全连接中如果没有空间，直接向client回复RST，表示连接无法建立。
原文地址：https://www.cnblogs.com/zh1164/p/10003451.html