1. 为什么 WebSocket 接口不能用 HTTP Sampler 硬套——从协议本质讲清测试前提你是不是也试过在 JMeter 里把 WebSocket 的 URL 直接粘进 HTTP Request Sampler填上 Host、Path、Method点运行结果 Response Code 永远是 400 或直接 Connection Reset我第一次遇到这问题时花了整整两天时间反复检查代理设置、Cookie 管理器、Header Manager甚至重装了 JMeter最后才发现根本不是配置错了而是用错了工具——HTTP Sampler 天然不理解 WebSocket 是什么。这不是你的错是绝大多数刚接触实时通信接口测试的人必踩的第一道坎。WebSocket 和 HTTP 看似都走 TCP但协议栈底层逻辑完全不同。HTTP 是典型的“请求-响应”单次对话模型客户端发一个 GET/POST服务端回一个 200/500连接就断了而 WebSocket 是“长连接双工通信”模型一次握手基于 HTTP Upgrade建立持久通道后客户端和服务端可以随时互相发消息没有请求发起方和响应方的固定角色。这就决定了JMeter 原生的 HTTP 协议栈只负责完成那一次 Upgrade 握手之后的帧Frame收发、心跳维持、连接状态管理、消息序列化/反序列化它一概不管。你硬塞进去的 HTTP Sampler就像让快递员去开飞机——他连驾驶舱门在哪都不知道。更关键的是真实业务中的 WebSocket 接口几乎从不裸奔。它必然携带鉴权信息如 JWT Token 放在 Sec-WebSocket-Protocol 或自定义 Header、需要心跳保活Ping/Pong 帧、消息体多为二进制或压缩 JSON、还常伴随连接建立后的初始化订阅SUBSCRIBE 命令。这些都不是 HTTP Sampler 的字段能覆盖的。我去年帮一家期货交易系统做压测时发现他们 WebSocket 接口在连接建立后第 3 秒必须收到服务端推送的行情快照否则自动断连——这种强时序依赖HTTP Sampler 根本无法建模。所以“JMeter WebSocket 接口测试”这个标题背后真正要解决的不是“怎么点按钮”而是如何让 JMeter 这个以 HTTP 为中心的压测引擎具备理解、模拟、验证 WebSocket 全生命周期行为的能力。它要求你跳出“HTTP 思维”接受“连接即资源、消息即事件、状态需维护”的新范式。本文所有内容都建立在这个认知基础上不讲虚的原理只聚焦你能立刻上手的实操路径、每个参数背后的业务含义、以及我在 17 个不同行业 WebSocket 项目中踩出的血泪坑。2. 选型决策为什么是 WebSocket Samplers by Peter Doornbosch而不是其他插件市面上叫“JMeter WebSocket Plugin”的开源项目至少有 5 个GitHub 上 star 数从 20 到 800 不等。我最初也试过那个 star 最高的 jmeter-websocket-samplers结果在测试一个带 TLS 双向认证的医疗设备远程控制接口时跑了不到 5 分钟就爆出javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure。查源码才发现它底层用的 Apache HttpClient 4.3根本不支持 TLS 1.3 的 ALPN 扩展协商——而目标服务强制要求 TLS 1.3。那一刻我意识到选插件不是看 star 数而是看它是否真实跑通过你手头这个“最刁钻”的场景。最终锁定WebSocket Samplers by Peter Doornbosch以下简称 PD 插件不是因为它文档写得最好而是因为三个硬核事实第一它的 GitHub Issues 区里90% 的问题都是“如何对接 Kafka 消息桥接”“怎样处理 Protobuf 编码帧”这类高阶需求说明真实用户都在用它干脏活累活第二它底层直接封装 Java NIO 的WebSocketContainer而非二次包装 HttpClient这意味着它对 JDK 原生 WebSocket API 的兼容性极强JDK 11 的 TLS 1.3、ALPN、SNI 全部原生支持第三也是最关键的——它把 WebSocket 的整个生命周期拆解成了 5 个原子 Sampler每个只干一件事且参数命名直白到像在读业务代码WebSocket Open Connection、WebSocket Send Text Message、WebSocket Read Text Message、WebSocket Close Connection、WebSocket Ping/Pong。这种设计让你能像搭乐高一样精准复现任何复杂交互流程。我们来对比下核心能力差异基于 JMeter 5.6 JDK 17 环境实测能力维度PD 插件v1.1.0jmeter-websocket-samplersv1.0.1JMeter 内置 JSR223 OkHttp手动编码TLS 1.3 支持✅ 原生支持无需额外配置❌ 报 handshake_failure✅ 但需手动引入 okhttp-tls 依赖二进制帧发送✅WebSocket Send Binary MessageSampler❌ 仅支持文本✅ 需手写ByteBuffer.wrap(...)超时控制粒度✅ 连接超时、读超时、写超时独立设置❌ 全局 timeout 统一配置✅ 但需在代码里分别调用setConnectTimeout()等消息断言灵活性✅ 支持正则、JSON Path、XPath、JSR223 脚本❌ 仅支持简单字符串匹配✅ 完全自由但每次都要写 20 行代码分布式压测稳定性✅ 在 200 并发节点集群中连续运行 72 小时无内存泄漏❌ 100 并发时频繁出现java.nio.channels.ClosedChannelException⚠️ 依赖 OkHttp 连接池配置易因maxIdleConnections设置不当导致线程阻塞提示PD 插件的安装极其简单——下载WebSocketSamplers.jar丢进JMETER_HOME/lib/ext/目录重启 JMeter 即可。它不修改 JMeter 任何核心类完全符合企业安全审计要求。而那些需要改jmeter.properties或注入自定义 ClassLoader 的插件我在金融客户现场直接被安全团队否决。为什么不用 JSR223 OkHttp 手写坦白说对于单接口快速验证它确实够用。但一旦进入真实压测阶段问题就来了你需要自己管理 WebSocket 连接池避免每线程新建连接、自己实现心跳保活逻辑否则服务端 30 秒无消息就踢人、自己处理连接异常重连网络抖动时不能让整个线程卡死。而 PD 插件把这些都封装好了——WebSocket Open ConnectionSampler 里的 “Reconnect on error” 勾选项背后就是一套指数退避重连算法WebSocket Ping/PongSampler 的 “Send ping every X seconds” 参数直接对应服务端要求的心跳间隔。省下的不是代码行数而是你排查“为什么 30% 请求失败”时深夜三点对着线程堆栈发呆的 3 小时。3. 从零搭建一个可运行的 WebSocket 测试计划5 个 Sampler 的真实协作逻辑很多教程教你怎么一个个添加 Sampler却从不解释“为什么必须按这个顺序”。我见过太多人把WebSocket Send Text Message放在WebSocket Open Connection前面结果所有请求都报Connection not established——这就像还没点火就猛踩油门。下面我带你用一个真实的股票行情订阅场景完整走一遍 5 个 Sampler 如何像齿轮一样咬合转动。假设我们要测试的接口是wss://api.stock.example.com/ws连接需携带 JWT Token建立后发送{ type: SUBSCRIBE, symbols: [AAPL, GOOGL] }订阅苹果和谷歌股票然后持续接收服务端推送的实时报价格式为{symbol:AAPL,price:182.34,timestamp:1715821200}。3.1 WebSocket Open Connection不只是“连上”而是“连对”这是整个链条的起点但参数远不止填个 URL。打开 Sampler重点看这几个字段WebSocket URL填wss://api.stock.example.com/ws。注意必须是wss://不是ws://否则 TLS 握手会失败。Subprotocols填auth-jwt。这是关键很多服务端通过Sec-WebSocket-ProtocolHeader 传递鉴权方式PD 插件会自动将其加入 Upgrade 请求头。如果你的 Token 存在 Cookie 里这里就填cookie-auth。Connection Timeout (ms)设为5000。别贪快金融类接口 DNS 解析或证书链校验可能耗时较长设太小会导致大量“连接超时”误判。Max Reconnects设为3。这是容错底线——网络抖动时允许重试 3 次超过就报错避免无限等待拖垮线程。Headers点击“Add Header”按钮添加两行Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...你的实际 TokenX-Client-ID: stock-tester-001用于服务端日志追踪注意PD 插件不会自动读取 JMeter 的 HTTP Header Manager 或 Cookie Manager。所有 WebSocket 特有的 Header必须在这里显式填写。这是新手最容易忽略的点——以为配了全局 Header 就万事大吉。3.2 WebSocket Send Text Message发送订阅指令的“时机”比“内容”更重要连接建立后不能立刻发消息。服务端需要时间初始化会话上下文。PD 插件提供了两种同步机制Option A推荐在WebSocket Open ConnectionSampler 后加一个Constant Timer延迟1000 ms。这是最稳妥的做法给服务端留足缓冲。Option B用WebSocket Read Text MessageSampler 的 “Wait for message” 功能设置超时2000 ms并勾选 “Ignore timeout errors”。这样只要服务端返回任意欢迎消息如{status:connected}后续发送才开始。但前提是服务端真会发。发送订阅消息的 Sampler 配置如下Message粘贴完整 JSON 字符串{type:SUBSCRIBE,symbols:[AAPL,GOOGL]}Message Type选Text不是 BinaryClose connection after sending?务必取消勾选这是生死线——勾选了发完就断连后面收不到任何推送。Response Timeout (ms)设为3000。这是等待服务端确认订阅成功的超时不是等行情数据。3.3 WebSocket Read Text Message如何区分“心跳响应”和“真实业务数据”这才是最考验功底的部分。服务端推送的消息流里混杂着三种东西1你订阅的行情数据2服务端主动发的 Ping 帧要求你回复 Pong3偶尔的系统通知如{type:NOTICE,msg:Market open}。如果只用一个Read Text MessageSampler你会收到一堆乱码或超时错误。正确做法是分层捕获第一层捕获并响应 Ping添加一个WebSocket Ping/PongSampler勾选 “Respond to server pings automatically”。它会默默监听所有入站帧一旦检测到opcode9Ping立即发回opcode10Pong无需你写一行代码。这是保持连接存活的基石。第二层捕获业务数据添加WebSocket Read Text MessageSampler关键参数Response Timeout (ms)设为1000010 秒。行情数据不是秒级必达给足缓冲。Match Pattern填正则{symbol:(AAPL|GOOGL),price:[0-9.],timestamp:[0-9]}。这确保只匹配有效行情过滤掉 NOTICE 等干扰消息。Store response in variable填last_quote。后续断言、提取价格都用它。第三层兜底捕获所有消息调试用再加一个WebSocket Read Text Message超时设100不填 Match Pattern只勾选 “Read all available messages”。把它放在最后专门抓那些漏网的、格式异常的消息方便调试。3.4 WebSocket Close Connection优雅退出的必要性很多人测试完就关 JMeter觉得无所谓。但在生产压测中这会导致服务端连接数暴增——每个未关闭的连接都占用一个文件描述符达到上限后新用户无法接入。PD 插件的WebSocket Close ConnectionSampler 提供了两种关闭方式Graceful Close推荐发送opcode8关闭帧等待服务端 ACK 后再释放资源。适合正常结束流程。Force Close直接socket.close()。仅在连接已半死如Read Timeout后时使用。配置很简单勾选 “Close connection”设置 “Close code” 为1000正常关闭 “Close reason” 填Test completed。把它放在所有读写操作之后作为线程清理的最后一步。4. 真实压测中的 5 大高频故障与根因定位法从报错日志反推服务端状态即使 Sampler 配置完美压测过程中仍会冒出各种诡异错误。下面这 5 类问题我在 32 次 WebSocket 压测中至少遇到过 200 次每一次都伴随着服务端日志的蛛丝马迹。学会看懂这些报错比记住 100 个参数更重要。4.1java.io.IOException: Broken pipe—— 不是网络问题是服务端主动断连现象线程运行中突然报此错且集中在同一时间点如每 30 秒一批。根因分析这是 Linux 内核层面的信号意味着你往一个已被对端关闭的 socket 写数据。结合我们的场景99% 是服务端因心跳超时强制踢人。验证步骤检查WebSocket Ping/PongSampler 是否启用 “Respond to server pings automatically”查看服务端日志关键词connection idle timeout,missing pong,kicked for inactivity对比 JMeter 中WebSocket Ping/Pong的 “Send ping every X seconds” 与服务端配置的heartbeat_interval通常服务端要求 25 秒发一次 Ping你就得设成 20 秒。修复方案将 Ping 间隔设为服务端要求值的 80%并确保WebSocket Ping/PongSampler 的执行频率高于其他 Sampler用Uniform Random Timer控制其优先级。4.2javax.websocket.DeploymentException: The HTTP request failed with status code 401—— Token 过期的静默陷阱现象WebSocket Open ConnectionSampler 持续报 401但 Token 明明是刚生成的。根因分析JWT Token 有exp过期时间声明。PD 插件在连接建立时只做一次鉴权若压测持续 2 小时Token 却只设了 30 分钟有效期后 90 分钟所有新连接都会失败。更隐蔽的是有些服务端会在连接建立后再用 Token 校验后续每条消息的权限。验证步骤用Debug Sampler打印vars.get(TOKEN)确认其exp时间戳在WebSocket Open Connection的 Headers 中临时把Authorization改成一个明显错误的值如Bearer invalid观察是否报 401——如果是证明鉴权发生在连接阶段若连接成功但发消息时报 401则鉴权在消息层需在WebSocket Send Text Message的 Message Body 中嵌入 Token如{token:xxx,data:{...}}。修复方案用JSR223 PreProcessor在每次WebSocket Open Connection前动态生成新 Token并存入变量vars.put(AUTH_TOKEN, newToken)再在 Header 中引用${AUTH_TOKEN}。4.3java.util.concurrent.TimeoutException: Read timed out—— 服务端没发数据还是你没读懂协议现象WebSocket Read Text MessageSampler 频繁超时但服务端监控显示消息推送正常。根因分析WebSocket 协议允许服务端“选择性推送”。例如行情接口可能只在价格变动 0.1% 时才推送而你的测试数据恰好处于横盘期。或者服务端采用“批量合并推送”10 条消息打包成一个帧发送而你的Read Text Message默认只读一个 JSON 对象。验证步骤用Wireshark抓包过滤websocket ip.addr 你的服务端IP看实际收到的帧内容在WebSocket Read Text Message中取消勾选 “Stop reading on first match”并增大 “Response Timeout” 至30000添加Debug Sampler打印prev.getResponseDataAsString()看是否收到多个 JSON 连在一起如{a:1}{b:2}。修复方案若确认是多 JSON 合并用JSR223 PostProcessor解析def raw prev.getResponseDataAsString() def jsons raw.replaceAll(}{, }|{).split(\\|) // 按 }{ 分割 for (json in jsons) { if (json.trim()) { def obj new groovy.json.JsonSlurper().parseText(json) vars.put(quote_ obj.symbol, obj.price.toString()) } }4.4java.lang.OutOfMemoryError: Direct buffer memory—— 内存泄漏的无声杀手现象压测运行 2 小时后JMeter GUI 响应迟缓命令行模式下jstat -gc pid显示CCMG压缩类空间持续增长。根因分析PD 插件底层使用 Netty 的PooledByteBufAllocator管理堆外内存。当WebSocket Read Text Message的Response Timeout设得过大如 60 秒且服务端偶发不发消息时Netty 会为每个等待线程分配一块 64KB 的 Direct Buffer超时后未及时回收。1000 线程 × 64KB 64MB 堆外内存瞬间打爆。验证步骤启动 JMeter 时加 JVM 参数-XX:PrintGCDetails -XX:PrintGCTimeStamps -XX:UseG1GC观察 GC 日志中是否有G1 Evacuation Pause频繁触发且Direct buffer memory使用率飙升用jcmd pid VM.native_memory summary查看Internal区域内存占用。修复方案将所有ReadSampler 的超时设为合理值行情类 ≤10 秒聊天类 ≤30 秒在Test Plan的Thread Group中勾选 “Run tearDown Thread Groups after shutdown of main threads”并在其中添加WebSocket Close Connection确保线程退出前强制释放连接。4.5org.apache.jmeter.protocol.http.sampler.HTTPSampleResult: Non HTTP response message: Connection refused—— DNS 缓存引发的雪崩现象压测刚开始一切正常10 分钟后大量连接失败错误信息却是Connection refused但服务端 CPU、内存、连接数均正常。根因分析JMeter 默认复用 JVM 的 DNS 缓存TTL 30 秒。当服务端做了蓝绿发布新 IP 已生效但 JMeter 仍尝试连接旧 IP导致Connection refused。这不是 WebSocket 插件的问题而是 JVM 网络层的固有缺陷。验证步骤在JSR223 Sampler中执行println java.net.InetAddress.getByName(api.stock.example.com).getHostAddress()连续运行 5 次看 IP 是否变化对比nslookup api.stock.example.com的结果。修复方案在JMETER_HOME/bin/jmeter.shLinux/Mac或jmeter.batWindows的 JVM 参数中添加-Dnetworkaddress.cache.ttl5 -Dnetworkaddress.cache.negative.ttl1这强制 DNS 缓存最多 5 秒负向缓存失败记录仅 1 秒确保 IP 变更秒级生效。5. 进阶实战如何用 WebSocket Sampler 验证“消息时序一致性”与“端到端延迟”压测的终极目标不是“能不能连上”而是“业务逻辑是否正确”。下面两个场景展示了 PD 插件如何超越基础连通性测试深入业务内核。5.1 验证订单成交推送的严格时序从下单到收推送不能超过 200ms某期货交易平台要求用户提交{type:ORDER,symbol:BTCUSD,side:BUY}后必须在 200ms 内收到{type:FILL,order_id:xxx,filled_price:...}推送且filled_price必须等于下单时的limit_price。这涉及跨 Sampler 的时间链路追踪。实现步骤在WebSocket Send Text Message发订单前用JSR223 PreProcessor记录时间戳vars.put(order_send_time, System.currentTimeMillis().toString())在WebSocket Read Text Message收成交的Response Timeout设为200确保超时即失败添加JSR223 PostProcessor解析响应并计算延迟def sendTime Long.parseLong(vars.get(order_send_time)) def recvTime System.currentTimeMillis() def latency recvTime - sendTime vars.put(latency_ms, latency.toString()) if (latency 200) { prev.setSuccessful(false) prev.setResponseMessage(Latency ${latency}ms 200ms SLA) }用Response Assertion验证filled_priceField to TestResponse DataPattern Matching RulesContainsPatterns to Testfilled_price:${__V(limit_price)}假设下单时limit_price存在变量中5.2 模拟千人在线聊天室的“消息广播风暴”压测一个典型聊天室场景1000 个用户连接到wss://chat.example.com/ws每人每 5 秒随机向频道#general发一条消息{channel:#general,text:Hello from user ${__threadNum}}服务端需将该消息广播给其余 999 人。挑战在于如何让每个线程既发消息又收消息且不互相干扰关键技巧使用__threadNum和__Random函数构造唯一标识WebSocket Open Connection的 Subprotocols 填user-${__threadNum}便于服务端日志追踪WebSocket Send Text Message的 Message 填{channel:#general,text:Hello from user ${__threadNum},seq:${__Random(1,1000000)}}WebSocket Read Text Message的 Match Pattern 填{channel:#general,text:Hello from user [0-9],seq:[0-9]}为避免一个线程收到自己发的消息某些服务端会回传在JSR223 PostProcessor中过滤def msg new groovy.json.JsonSlurper().parseText(prev.getResponseDataAsString()) if (msg.text.contains(user ${props.get(THREAD_NUM)})) { // 收到自己的消息跳过断言 return }最后分享一个血泪经验在做此类广播压测前务必先用View Results Tree查看 10 个线程的日志确认seq字段是否全局唯一。我曾因__Random函数在多线程下种子相同导致 1000 个用户发出的seq全是12345服务端当成重复消息全部丢弃压测结果全是 100% 失败——排查了 6 小时才发现是随机数函数的坑。现在我的标准动作是所有唯一 ID一律用UUID.randomUUID().toString()生成哪怕慢一点也比猜谜强。