SSH/RDP压测对象非协议本身，而是底层认证服务与会话链路；需分层设计：先测认证子系统吞吐（如每秒成功SSH握手数），再模拟真实接入，最后长期运行观察资源泄漏；须监控TIME_WAIT堆积、连接跟踪表、日志错误及会话状态，并提供P95耗时趋势、内存句柄变化、失败抓包等可回溯证据。
SSH 和 RDP 接入控制本身不是被压测的“服务性能”主体，而是访问通道。真正的压测对象是底层认证服务（如 OpenSSH 的 auth 子系统、Windows 的 Terminal Services 认证模块）和会话建立链路（网络层、协议解析、用户上下文初始化）。直接对 SSH/RDP 做高并发连接冲击，容易误判——很多失败源于连接未完成就断开、密钥交换超时或防火墙限速，而非服务本身崩溃。因此，有效的方案必须分层设计：先隔离验证认证子系统承载力，再模拟真实接入行为，最后叠加长期运行观察资源泄漏与状态退化。
SSH 接入链路压力与稳定性测试要点
重点不在“能连多少台”，而在“单台服务器每秒可成功建立多少个新 SSH 会话”，尤其关注密钥认证路径（非密码）下的吞吐与内存驻留表现：
- 使用 ssh-bench 或自研脚本（基于 paramiko 或 libssh），控制并发连接数，每次连接后立即执行
exit，不维持 shell；记录每秒成功 handshake 数、平均建立耗时、失败原因（timeout / auth-fail / connection-reset） - 强制启用公钥认证并禁用密码，关闭
UsePrivilegeSeparation（仅测试环境），避免 fork 开销干扰核心 auth 性能 - 监控关键指标：
ss -s查看 TIME_WAIT 连接堆积；cat /proc/net/nf_conntrack | grep :22 | wc -l观察连接跟踪表占用；journalctl -u sshd -n 100 --no-pager检查是否有 “max startups” 或 “fork failed” 日志 - 稳定性阶段：持续以 70% 极限速率运行 8 小时，检查
systemctl status sshd是否出现 restart、free -h是否内存缓慢增长、ss -i是否重传率上升
RDP 接入链路压力与稳定性测试要点
RDP 压测更复杂，因涉及图形协商、NLA 验证、会话初始化及 Windows Session Manager 调度。不能只看“能否弹出桌面”，而要看“会话是否真正进入 Active 状态且可交互”：
- 使用 PowerShell + WMI 或 RDPSessionBench 工具（非 GUI 客户端），调用
Invoke-WmiMethod -Class Win32_TerminalServiceSetting -Name CreateSession模拟登录，跳过 mstsc.exe 图形握手开销 - 确保 NLA 强制开启（
UserAuthentication = 1），否则压测结果反映的是弱认证路径，无实际安全意义 - 监控项包括：
query session输出中状态为Active的数量；Get-Counter '\Terminal Services*\*'中Active Sessions、Logon Rate/sec、Failed Logons/sec；事件查看器中Microsoft-Windows-TerminalServices-LocalSessionManager/Operational日志中的 21/24/40 事件 - 极限测试后执行
logoff /server:xxx *清理会话，观察是否存在 “ghost session”（状态为 Disc / Listen 却无法注销），这是资源泄漏典型信号
统一接入网关层的协同压测设计
若部署了跳板机、堡垒机或 Azure AD Conditional Access 等前置网关，SSH/RDP 实际走的是代理链路。此时压测重心要上移：
- 在网关节点部署
tcpdump -i any port 22 or port 3389，统计原始连接新建速率与 TLS 握手成功率，区分是后端服务瓶颈还是网关转发瓶颈 - 对网关做连接复用能力验证：同一客户端 IP 发起 1000 次 SSH 连接，观察网关是否触发
MaxStartups限流，或 RDP 网关是否返回 0x204 错误（表示连接队列满） - 模拟网络抖动：用
tc netem在网关出口注入 5% 丢包 + 100ms 延迟，测试认证超时容忍度与重试逻辑健壮性 - 日志关联分析：将网关 access.log、后端 sshd 日志、Windows Security Event ID 4624/4625 按时间戳对齐，定位延迟毛刺发生在哪一跳
报告输出必须包含的稳定性证据项
一份可信的评估报告，不能只有“通过/失败”，而应提供可回溯的行为证据：
- 每个测试周期的 连接建立 P95 耗时趋势图（横轴时间，纵轴毫秒），标注拐点时刻
- 内存与句柄数变化曲线（Linux：
/proc/PID/status中 VmRSS / HandleCount；Windows：Get-Process sshd | Select PM, Handles） - 失败样本抓包（pcap），标出 SYN → SYN-ACK → ACK → SSH banner 的完整时序，确认是服务未响应还是中间设备拦截
- 连续运行 24 小时后的对比快照：启动时 vs 结束时的
ss -s、query session、netstat -an | grep ESTAB | wc -l
