1. 问题描述与分析
1.1 问题背景
- 产品/平台: 操作系统；网络
- 内核版本:
4.19.90（宿主机与虚拟机一致） - 问题概述: SSH连接目标服务器时随机出现连接超时，复现时间不明确，但可通过重启目标服务器的
sshd服务临时恢复。 - 接手时间: 2025年5月7日
1.2 问题现象与分析
复现情况: 偶现，触发条件为高并发场景。
关键排查过程:
阶段一：前置分析
故障发生时，外部无法
telnet目标机器的SSH端口（默认22）。然而在目标机器上查看，sshd端口处于正常监听状态。系统日志中无明显异常。初步推断: 端口监听正常但
telnet不通，可能性有二：
- 服务器未收到客户端报文（被防火墙或安全设备过滤）。
- 服务器收到了报文但未能正常处理（网卡、内核协议栈或服务本身异常）。
阶段二：入会确认
确认系统内核大于4.12，排除了内核PAWS机制导致丢包的可能性。会议讨论聚焦于上述两种可能，并计划进行复现分析。
阶段三：现场复现与根因定位（5月11日）
- 服务状态检查: 登录问题服务器，确认
sshd服务进程正常运行。- 端口检查: 确认
sshd端口正常监听。- 本地探测: 在服务器本机上
telnet 127.0.0.1 22，连接失败。至此，故障点缩小至服务器本机的网络报文处理路径（网卡或内核协议栈）。
详细排查:
- 使用
ss -tln查看sshd的监听socket队列状态，发现Recv-Q(当前全连接队列长度) 为 129，而Send-Q(全连接队列最大长度) 为默认的 128。Recv-Q > Send-Q表明 TCP全连接队列已溢出，新连接无法进入。- 通常，全连接队列溢出时，半连接队列（SYN队列）也应已满。通过
netstat -s | grep -i “drop”命令查看，统计项SYNs to LISTEN sockets dropped的数值持续增长，证实了TCP半连接队列同样溢出丢包。结论: 在高并发SSH连接场景下，服务器的TCP半连接队列（SYN Queue）和全连接队列（Accept Queue）被填满，导致新的TCP三次握手无法完成，表现为SSH连接超时。
1.3 问题结论
根本原因是：服务器内核的TCP连接队列（包括半连接队列和全连接队列）在高并发连接下被占满，导致新的SSH连接无法建立。
2. 解决方案与说明
拟定解决方案：临时调大内核中TCP连接队列的大小上限。
执行命令：
# 增大TCP半连接队列（SYN Backlog）大小
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
# 增大Socket全连接队列（Accept Queue）大小
sysctl -w net.core.somaxconn=65535
效果验证：
- 执行上述调优后，持续观察
SYNs to LISTEN sockets dropped计数，停止增长。 - SSH连接立即恢复正常。
- 后续多日观察，问题未再复现，丢包计数稳定。问题得以闭环。
3. 类似问题解决思路（方法论总结）
处理此类网络连接超时问题，可遵循以下通用排查思路：
- 信息收集与归类: 了解基本故障现象（计算、存储、网络、内核等层面）。
- 排除常见陷阱: 检查操作系统基本配置，排除已知通用问题（例如，高版本内核的PAWS机制）。
- 检查服务状态: 确认目标服务进程是否存活、是否僵死。
- 检查端口状态: 从服务器内部（
netstat,ss,lsof）和外部（telnet,nc）两个角度探测端口可达性。 - 定位故障点: 通过内外对比，确定问题是发生在网络链路上、主机防火墙，还是服务本机内部。
- 深入分析根因: 在定位到本机后，利用系统工具（
ss,netstat -s，dmesg，sar等）从协议栈、资源、性能等维度进行深入分析。 - 确认并制定方案: 根据分析结论，制定针对性的解决方案或参数调整策略。
- 验证与闭环: 实施解决方案并持续观察，确保问题彻底解决。
4. 参考链接
- Linux 网络栈监控和调优：接收数据 - 深度理解Linux内核网络栈处理流程，对分析队列溢出问题非常有帮助。