为什么linux backlog重要

在 Linux 网络编程（尤其是 TCP 服务端）中，backlog 是一个非常重要但经常被误解的参数。它直接影响连接建立的性能、稳定性和可靠性。下面从“是什么、为什么重要、不设好会怎样”三个层面说明。

一、backlog 是什么？

在 TCP 服务端，通常流程是：

socket()
bind()
listen(sockfd, backlog)
accept()

listen() 的 backlog 参数，用来限制内核中“已完成连接”或“正在握手”的队列长度（不同内核版本含义略有差异）。

简化理解：

客户端 -> [半连接队列] -> [全连接队列] -> accept()
                ↑ backlog 相关

• 半连接队列（SYN Queue）
  收到 SYN，但三次握手还没完成
• 全连接队列（Accept Queue）
  三次握手完成，等待 accept() 取走

backlog 主要影响全连接队列长度（在老内核中也影响半连接）。

二、为什么 backlog 很重要？

1️⃣ 防止高并发时“连接被悄悄丢掉”

如果 全连接队列满了：

• 新完成的 TCP 连接不会被 accept
• 内核可能：
  • 直接 丢弃 ACK
  • 或发送 RST
• 客户端表现为：
  • 连接超时
  • connection reset
  • 偶发性失败

➡️ 高并发服务（Web、RPC、网关）中，这是隐形故障源头。

2️⃣ 平滑应对“瞬时流量洪峰”

比如：

• 秒杀
• 服务刚重启
• 客户端批量重连

如果 backlog 太小：

• 握手成功但进不了队列
• 连接失败率飙升

如果 backlog 合理：

• 连接先排队
• 应用慢慢 accept
• 系统更稳

3️⃣ 影响服务端吞吐能力

accept() 是用户态行为，可能慢（业务逻辑、锁、GC）。

backlog 相当于：

内核帮你“接住”连接，等你来处理

太小 → 内核接不住
太大 → 内存+CPU 成本上升（但不致命）

4️⃣ 避免“明明端口通，但连不上”

很多诡异问题：

• telnet 能通
• 但程序连不上
• 压力一上来就失败

最后发现：

backlog = 5 或 10（默认值太小）

三、backlog 不是“越大越好”

过大问题

• 占用内核内存
• 客户端以为连上了，但很久不被处理（体验差）
• 掩盖程序处理慢的问题

经验值

• 普通服务：128 ~ 512
• 高并发：1024 ~ 4096
• 还要配合：

  net.core.somaxconn
  

四、Linux 中的真实限制

实际生效的是：

min(backlog, net.core.somaxconn)

查看：

cat /proc/sys/net/core/somaxconn

修改：

sysctl -w net.core.somaxconn=4096

五、一句话总结

backlog 决定了“内核能帮你接住多少连接”

它重要，是因为：

• 影响连接成功率
• 决定高并发稳定性
• 是服务端“抗冲击能力”的关键参数之一

如果你愿意，我也可以：

• 画一张连接队列示意图
• 结合 Nginx / Redis / Java / Go 讲 backlog
• 帮你算一个合理的 backlog 值