Linux backlog如何进行测试

Linux backlog 测试方法与步骤

一、关键概念与判定依据

• 在 Linux 2.2+ 中，listen 的 backlog 指的是已完成三次握手、等待应用 accept 的“全连接队列”长度；未完成握手的“半连接队列”长度由 /proc/sys/net/ipv4/tcp_max_syn_backlog 控制，且当启用 syncookies 时半连接队列长度限制不再适用。全连接队列的实际上限为 min(backlog, /proc/sys/net/core/somaxconn)。队列满时，新连接可能被丢弃或返回 ECONNREFUSED，内核也可能选择忽略以等待重传。以上为测试判读的基础。

二、测试准备与基线检查

• 基线参数与监听状态检查
  • 查看与必要时调整系统参数（测试环境建议临时放大）：
    • 查看：cat /proc/sys/net/core/somaxconn；cat /proc/sys/net/ipv4/tcp_max_syn_backlog
    • 临时放大：sysctl -w net.core.somaxconn=4096；sysctl -w net.ipv4.tcp_max_syn_backlog=4096
  • 观察监听套接字队列占用：ss -lntp | grep <端口>，关注 Recv-Q（当前排队）与 Send-Q（最大队列长度，即 listen 的 backlog 与 somaxconn 的较小者）。
  • 基线抓包：tcpdump -i any -nn -ttt ‘tcp port <端口>’，用于对比队列满前后的握手行为。

三、验证全连接队列满的行为

• 场景A（最稳妥）：固定 backlog，禁止 accept
  • 服务端：listen(fd, N)，随后不调用 accept（或 sleep 阻塞）。
  • 客户端：并发发起 M（M >> N）个连接（短连接或连接后不发送数据均可）。
  • 观察与判定：
    • ss 显示 Recv-Q ≈ N 且不再增长；新连接在客户端表现为超时或立即被拒绝（取决于内核与参数）。
    • tcpdump 可见：服务端对超出队列的连接不再发送 SYN-ACK（或发送后被丢弃），客户端出现 SYN 重传；若开启 tcp_abort_on_overflow，队列溢出时服务端会发送 RST。
• 场景B（贴近真实）：高并发短连接压测
  • 服务端：正常 accept，但处理极慢（如 accept 后 sleep），使应用来不及消费队列。
  • 客户端：使用 ab/wrk 高并发短连接压测。
  • 观察与判定：ss 的 Recv-Q 长时间接近队列上限；错误日志/客户端可见连接失败增多；抓包可见 SYN 重传 与（若启用）溢出 RST。
• 场景C（区分半连接与全连接）：仅压半连接队列
  • 服务端：listen 正常，但在三次握手完成前不 accept（或极慢），同时用防火墙/iptables 丢弃所有到达的 ACK（模拟应用层极慢或崩溃，导致全连接队列无法消费）。
  • 客户端：并发发起大量连接。
  • 观察与判定：ss -s 的 SYNs queued 或 /proc/net/snmp 的 TcpExt:ListenOverflows/ListenDrops 增长；tcpdump 可见 SYN 洪泛与 SYN-ACK 重传，但 ACK 被丢弃，全连接队列始终不满。该场景用于验证 tcp_max_syn_backlog 与 syncookies 的行为。

四、观测指标与工具对照表

以上工具与字段可交叉验证，避免单一指标误判。

五、常见问题与排错要点

• 队列“看起来不满”但客户端仍失败：可能是半连接队列（SYN 队列）先满，检查 tcp_max_syn_backlog、是否启用 syncookies，并用 ss -s 与抓包确认 SYN 重传 与 ListenOverflows。
• backlog 设置不生效：实际生效值为 min(应用 backlog, somaxconn)，需同时调大两者；用 ss 的 Send-Q 核对。
• 抓不到溢出 RST：确认内核参数 tcp_abort_on_overflow 的取值；不同取值决定队列溢出时是静默丢弃还是回 RST。
• 生产环境建议：逐步放大 somaxconn/tcp_max_syn_backlog，配合异步/多进程/线程池提升 accept 消费能力，并用压测与监控持续验证瓶颈点。