原标题：TCP 半连接队列和全连接队列满了会发生什么？又该如何应对？前言

网上许多博客针对增大 TCP 半连接队列和全连接队列的方式如下：增大 TCP 半连接队列方式是增大 tcp_max_syn_backlog；增大 TCP 全连接队列方式是增大 listen 函数中的 backlog；

这里先跟大家说下， 上面的方式都是不准确的。

“你怎么知道不准确？”

很简单呀，因为我做了实验和看了 TCP 协议栈的内核源码，发现要增大这两个队列长度，不是简简单单增大某一个参数就可以的。

接下来，就会以 实战 + 源码分析，带大家解密 TCP 半连接队列和全连接队列。

“源码分析，那不是劝退吗？我们搞 Java 的看不懂呀”

放心，本文的源码分析不会涉及很深的知识，因为都被我删减了，你只需要会条件判断语句 if、左移右移操作符、加减法等基本语法，就可以看懂。

另外，不仅有源码分析，还会介绍 Linux 排查半连接队列和全连接队列的命令。

“哦？似乎很有看头，那我姑且看一下吧！”

行，没有被劝退的小伙伴，值得鼓励，下面这图是本文的提纲：

本文提纲正文

什么是 TCP 半连接队列和全连接队列？

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：半连接队列，也称 SYN 队列；全连接队列，也称 accepet 队列；

服务端收到客户端发起的 SYN 请求后， 内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后， 内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

半连接队列与全连接队列

不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回 RST 包。

实战 - TCP 全连接队列溢出

如何知道应用程序的 TCP 全连接队列大小？

在服务端可以使用 ss命令，来查看 TCP 全连接队列的情况：

但需要注意的是 ss命令获取的 Recv-Q/Send-Q在「LISTEN 状态」和「非 LISTEN 状态」所表达的含义是不同的。从下面的内核代码可以看出区别：

在「LISTEN 状态」时，Recv-Q/Send-Q表示的含义如下：