ssh和rdp接入控制压测核心是验证真实并发下认证、会话建立与指令响应的稳定性、低延迟与不降级，暴露jumpserver或终端服务网关及底层系统（pam/sshd/termservice）和网络路径瓶颈。

SSH 和 RDP 接入控制的性能压测，核心不是测“能不能连上”，而是测“在真实并发规模下，认证、会话建立、指令响应是否稳定、低延迟、不降级”。它直接反映 JumpServer 或 Windows 终端服务这类接入网关的承载能力，也暴露底层系统（如 PAM、sshd、TermService）和网络路径的真实瓶颈。

SSH 接入链路压测重点：认证+会话初始化时延与吞吐

SSH 连接看似简单，但完整流程包含 TCP 握手 → 密钥交换 → 用户认证（密码/密钥）→ 会话通道建立 → Shell 启动。压测需分层验证：

• 认证层压力：使用 ssh-keyscan + ssh -o ConnectTimeout=2 模拟海量短连接，观察 sshd 的 fork 频率、PAM 调用耗时、以及 /var/log/secure 中认证失败率；建议配合 systemd-analyze blame 查看 PAM 模块（如 pam_faillock、pam_tally2）是否拖慢响应
• 会话稳定性：用 parallel-ssh 或自定义脚本发起 500+ 并发 SSH 登录，执行 uptime; free -h 后立即退出；监控 ss -s 中 ESTAB 连接数、ps aux | grep sshd | wc -l 的进程数，确认无僵死子进程或 fork 失败
• JumpServer 场景特化：若走 JumpServer 中转，必须在 Web 前端、Core 服务、Koko 终端组件三处分别打点监控；重点看 Koko 的 WebSocket 连接建立成功率（HTTP 101 升级）、SSH 会话复用率（避免重复鉴权），以及 audit 日志写入延迟（I/O 瓶颈常在此暴露）

RDP 接入压测关键：NLA 启用状态决定压测逻辑

Windows RDP 是否启用网络级身份验证（NLA），极大影响压测方式和结果解读：

• NLA 开启时（推荐且默认）：认证发生在 TLS 隧道内，不启动完整会话；此时压测应聚焦于 tscon 和 query session 响应速度，以及 PerfMon 中 “Terminal Services” 计数器的 Active Sessions、Logon Rate/sec；单台 Win Server 2022 标准版理论支持 100+ 并发登录，但实测中 >60 会明显抬高 CPU 在 csrss.exe 和 winlogon.exe 上的占用
• NLA 关闭时：客户端直接进入图形协商阶段，资源消耗翻倍；压测需关注显存分配（GPU 加速开启时）、桌面堆（Desktop Heap）大小（注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows 下 SharedSection 参数），否则易触发 0x500 错误（无法创建会话）
• JumpServer RDP 中转注意点：RDP over WebSocket 依赖 Guacamole 或自研代理；必须测试不同 color_depth（如 16-bit vs 32-bit）、是否启用 smart_sizing、是否开启音频重定向——这些选项会显著增加后端解码 CPU 和带宽开销，建议在压测中固定关闭非必要通道

统一接入网关的极限并发评估方法

当 JumpServer 或类似平台同时承载 SSH/RDP/数据库/K8s 等多协议接入时，不能只看“总连接数”，而要按协议类型拆解资源竞争：

• CPU 绑定分析：SSH 密钥计算（OpenSSL）、RDP 图形编码（Microsoft RDP Encoder）、TLS 握手（BoringSSL 或 SChannel）均为 CPU 密集型；用 perf record -g -a sleep 30 抓取热点函数，确认瓶颈是否在 crypto 或 encoder 模块
• 内存与文件描述符：每个活跃 SSH 会话约占用 4–8MB 内存；每个 RDP 会话（含桌面堆）约需 30–60MB；检查 ulimit -n 和 fs.file-max，确保不会因 fd 耗尽导致新连接被拒绝（错误日志常为 “Too many open files”）
• 真实业务模拟压测：避免只做 TCP 连接数测试；应构造典型操作流，例如：SSH 连接后执行 tail -f /var/log/syslog 持续流式输出；RDP 连接后运行 notepad.exe 并输入长文本——这能触发真实 I/O、内存拷贝与显示刷新路径，比空闲会话更能暴露问题

常见瓶颈识别与优化方向

压测中若出现连接缓慢、认证超时、会话断连或资源飙升，可按以下顺序排查：

• 确认系统时间同步（NTP）正常——RDP NLA 和 SSH Kerberos 认证对时间偏移极其敏感（>5 分钟即失败）
• 检查 SELinux/AppArmor 是否拦截了 sshd 或 TermService 的 socket 创建或 execve 调用
• Windows 侧禁用“远程桌面体验优化”中的所有视觉效果（动画、透明度），仅保留“桌面背景”以外的全部关闭项，可降低单会话 GPU/CPU 开销 20% 以上
• JumpServer 部署中，将 Core、Koko、Lion 分离到不同节点，并为 Koko 配置独立 Redis 实例（避免会话状态争抢）