简介这是一套基于C与libevent库的WebSocket服务器源码实现主要面向需要搭建高并发、全双工实时通信服务的后端开发者也适合正在深入学习HTTP升级协议与事件驱动编程模型的C程序员。代码完整覆盖了WebSocket握手校验、Sec-WebSocket-Key/Accept安全应答、数据帧解析与构造、读写事件调度、连接保活及超时管理等核心机制并配有可运行的演示程序、聊天示例页面与简洁的说明文档方便对照代码逐段理解协议细节也可直接编译运行验证效果。资源包共20个文件包含8个头文件与7个C源文件辅以Makefile构建脚本、说明文档及gitignore配置整体容量仅16KB结构干净、依赖极少。目前已有616人浏览学习资源热度良好适合用于自研网关组件或作为协议学习的紧凑参考实例按需摘取相应模块即可快速集成。1. C 与 libevent 的 WebSocket 服务端长连接压测背后的协议级缺口做实时推送和长连接服务的人迟早要面对一个尴尬裸 TCP 能收能发但浏览器端原生只认 WebSocket自己手写握手协议又总在细节上翻车。这份资源给的是一条相对省心的路线——用 C 绑定 libevent 的事件驱动模型把 WebSocket 服务端从升级握手到数据帧收发完整搭起来。它的价值不在于“能跑通”而在于把升级请求解析、帧掩码处理、连接生命周期管理这些容易写成黑匣子的部分摊开改哪里、加什么业务逻辑都看得见。适合已经用过 libevent 写简单 TCP 服务、想往 WebSocket 协议层走一步的 C 开发者新手拿去会有一定压力但只要对照抓包工具一步步跟也能把链路从握手到推送完整走通。2. 协议与技术选型WebSocket 帧结构、掩码规则与 libevent 的回调模型2.1 为什么这个场景必须用事件驱动而不是多线程服务端要处理的是几千个长连接每个连接大多时间都在空闲等待。用一连接一线程的方案线程切换开销和内存占用都不好看epoll 配合非阻塞 IO 是 Linux 下更务实的做法。libevent 的价值是把 epoll 的细节封装成 event_base 和回调函数我可以在不手写事件循环的状态下把连接、读、写的事件都调度起来。源码包里的服务端主循环是基于 event_base_dispatch 的所有 socket 描述符都注册成 EV_READ | EV_PERSIST。EV_PERSIST 的作用很关键默认情况下事件触发一次就被移除必须重新 event_add 才能再次触发带上 EV_PERSIST回调执行完 libevent 会自动重新注册省去我在回调尾部再调一次 event_add 的琐碎操作。这样一个事件循环就能支撑几千个连接业务逻辑只需要关心回调里拿到的数据和需要写入 evbuffer 的内容。2.2 WebSocket 帧格式里最容易写错的掩码和载荷长度WebSocket 协议里客户端发送给服务端的所有帧都必须做掩码处理服务端发给客户端则禁止掩码。这是协议强制要求很多手写实现在这里翻车。帧的前两个字节承载关键信息第一字节的 FIN 位、RSV1 到 RSV3、opcode第二字节的高位是 MASK 标志位低 7 位是 payload len。payload len 的取值分三种情况小于 126 时直接就是实际长度等于 126 时后面还有 2 字节的扩展长度等于 127 时后面有 8 字节的扩展长度。源码包里对这三种情况分别做了分支处理解析掩码键的逻辑也遵守“先读 payload len再决定要不要读扩展长度最后读掩码键”的顺序。如果顺序颠倒字节流就会错位解出来的 payload 是乱的。2.3 libevent 的 bufferevent 在这套服务里负责什么这个服务端用的是 bufferevent 而不是裸 event。区别在于 bufferevent 内置了输入输出两个 evbuffer数据到达时自动追加到输入缓冲写入时通过 evbuffer_add 排队libevent 在 socket 可写时自动把缓冲区的数据刷出去。缓冲机制对 WebSocket 这种帧式协议非常重要——TCP 是流式协议一次 read 回调拿到的数据可能是半个帧也可能是一个半帧必须依赖缓冲区做积累和分隔。源码里为每个连接创建 bufferevent 的地方通常是这样绑定的struct bufferevent *bev bufferevent_socket_new( base, fd, BEV_OPT_CLOSE_ON_FREE | BEV_OPT_DEFER_CALLBACKS); bufferevent_setcb(bev, on_read, nullptr, on_event, conn); bufferevent_enable(bev, EV_READ | EV_WRITE);BEV_OPT_CLOSE_ON_FREE 让连接对象释放时自动关闭 fd避免我手动管理描述符导致泄漏BEV_OPT_DEFER_CALLBACKS 把回调推迟到当前事件循环迭代末尾再执行能避免回调里操作同一个 bufferevent 造成的重入问题。on_read 负责把输入缓冲区里的数据按 WebSocket 帧格式解析on_event 则处理连接关闭和错误事件。这两层设计是性能的基础——数据进来先落地到 evbuffer帧解析在应用层完成读写频率和网络事件解耦。2.4 资源包里的文件结构与模块边界这套源码的模块划分比较干净核心部分在 net 层和 protocol 层之间做了隔离。net 层只负责建立连接、监听回调、维护 fdprotocol 层负责帧解析、生成握手响应、维护连接状态。业务回调由上层注册协议层不关心具体业务字段。层次目录/模块职责边界关键接口网络层net/event_loop事件循环初始化、监听 socket、连接接入event_base_new、evconnlistener_new传输层net/bufferevent_wrap收发缓冲、回调入口bufferevent_socket_new、bufferevent_setcb协议层protocol/frame帧解析、掩码处理、分片重组parse_frame、apply_mask协议层protocol/handshakeHTTP Upgrade 解析、Sec-WebSocket-Accept 计算make_accept_key、parse_headers应用层app/conn_mgr连接注册、心跳扫描、广播推送register_conn、broadcast_json这个分层的直接好处是如果我想把协议从 WebSocket 换成自定义帧格式只需要替换 protocol 层net 层完全不动。实际项目中我把这套代码当作参考实现往里面加了 JSON 消息路由和鉴权逻辑业务代码只和 conn_mgr 打交道不触碰底层 buffer 操作。3. 搭起来跑通编译环境、运行参数与第一个连接3.1 依赖准备与 CMake 构建的参数说明源码包依赖两个外部库libevent 的较新稳定版版本号以实际包内 README 为准以及 OpenSSL——虽然握手阶段用不到 TLS但代码路径里通常会预留 wss 支持。我在干净容器里验证时先安装 libevent 开发头文件再用 CMake 配置构建。下面这个流程是我反复跑过的# 安装 libevent 开发包以 Ubuntu 系的包名为例 sudo apt-get install -y libevent-dev libssl-dev cmake g # 进入源码目录用 CMake 生成构建文件 mkdir -p build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j$(nproc)构建产物在 build 目录下启动前确认端口没有被占用。服务端默认监听 8080 端口这个端口号在配置文件里可以改修改 config.ini 的 listen_port 字段后重新 make 即可。日志会输出到 stderr便于和 systemd 的 journald 对接。3.2 启动服务并用命令行客户端验证三次握手启动进程后先用网络调试工具做一次手动验证。WebSocket 握手是一个 HTTP GET 请求带 Upgrade: websocket 头。我用 wscat 或浏览器控制台都能测但为了确认协议细节这里展示用 Python 命令行直接发握手请求的方式# 启动服务 ./websocket_server -c config.ini # 用 curl 验证 HTTP 层面的 Upgrade 响应 curl -i -N \ -H Connection: Upgrade \ -H Upgrade: websocket \ -H Sec-WebSocket-Version: 13 \ -H Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ \ http://127.0.0.1:8080/如果服务端正常响应头里会出现 HTTP/1.1 101 Switching Protocols以及计算正确的 Sec-WebSocket-Accept。我拿着这个响应值和在线工具算出的结果对比用来确认服务端的握手算法没问题。握手通过后我再用 wscat 发一条文本消息验证 echowscat -c ws://127.0.0.1:8080输入 hello观察服务端是否原样返回。这一步验证的不只是数据收发还有掩码解析逻辑——wscat 发出的帧带掩码服务端必须在解析时正确还原。3.3 核心代码段一握手请求解析与 Accept 值计算服务端收到第一条 TCP 数据流时不能默认它一定是完整握手请求。TCP 可能把请求头拆成多个包所以我先将数据累积到输入缓冲区直到出现 \r\n\r\n 才认为 HTTP 头部完整。源码里握手处理按这个逻辑展开int handle_handshake(struct evbuffer *input, std::string accept_out) { // 1. 从输入缓冲区中取出头部区域按 \r\n\r\n 定位 size_t header_len evbuffer_get_length(input); char *buf (char *)evbuffer_pullup(input, header_len); std::string raw(buf, header_len); size_t pos raw.find(\r\n\r\n); if (pos std::string::npos) { return HANDSHAKE_NEED_MORE; // 数据不足等待下一次 read 回调 } // 2. 解析头部行提取关键字段 std::string header raw.substr(0, pos 4); std::string key extract_header_value(header, Sec-WebSocket-Key); if (key.empty()) { return HANDSHAKE_BAD_REQUEST; } // 3. 计算 Sec-WebSocket-Accept std::string accept base64_encode( sha1(key 258EAFA5-E914-47DA-95CA-5AB0DC85B11B)); accept_out accept; return HANDSHAKE_OK; }逻辑分三段evbuffer_pullup 把分散的缓冲区数据整理成连续内存方便我直接按字符串查找分隔符extract_header_value 逐行扫描头部字段只提取需要验证的键最后把客户端 key 拼接上协议固定的 GUID做一次 SHA1 再 Base64得到响应值。需要注意代码里的常量 GUID 是 RFC 6455 规定的固定值不是随便写的我没见过有服务端能忽略这个值还能通过主流客户端握手的。3.4 核心代码段二数据帧解析与掩码还原握手完成后后续所有数据都是 WebSocket 帧格式。帧解析函数的输入是 evbuffer输出是一个结构体包含 opcode 和 payload。这里给出服务端从缓冲区解析一帧并去掉掩码的逻辑int parse_frame(struct evbuffer *input, ws_frame_t *frame) { // 1. 先读取固定的 2 字节头部 unsigned char head[2]; if (evbuffer_copyout(input, head, 2) 2) { return FRAME_NEED_MORE; } frame-fin (head[0] 0x80) 7; frame-opcode head[0] 0x0f; int masked (head[1] 0x80) 7; uint64_t payload_len head[1] 0x7f; // 2. 长度扩展126 - 2 字节127 - 8 字节 if (payload_len 126) { uint16_t ext_len; evbuffer_copyout(input, ext_len, 2); payload_len ntohs(ext_len); } else if (payload_len 127) { uint64_t ext_len; evbuffer_copyout(input, ext_len, 8); payload_len be64toh(ext_len); } // 3. 掩码处理客户端帧必须带掩码键 unsigned char mask_key[4]; if (masked) { evbuffer_copyout(input, mask_key, 4); } // 4. 攒齐完整 payload 后才读取并还原 if (evbuffer_get_length(input) payload_len) { return FRAME_NEED_MORE; } frame-payload.resize(payload_len); evbuffer_remove(input, frame-payload.data(), payload_len); if (masked) { for (uint64_t i 0; i payload_len; i) { frame-payload[i] ^ mask_key[i % 4]; } } return FRAME_OK; }这里我刻意用了 evbuffer_copyout 而不是 evbuffer_remove 来读头部因为 copyout 不会消耗缓冲区的数据如果帧不完整下次回调还能从头重新解析。等确认整个帧都到了才用 evbuffer_remove 一次性把 payload 取走。掩码还原是逐字节异或注意 mask_key 是循环取模的不是一次性整块异或——这个细节写错过的人不少。代码里的 FRAME_NEED_MORE 状态只有等到数据真正齐了才清除保证每个连接的状态机是自洽的。3.5 参数调整建议与运行时观察点服务端有两个参数直接影响线上表现bufferevent 的水位设置和心跳扫描周期。水位设置控制 evbuffer 能积压多少数据我通常把低水位设为 0、高水位设为 64KB。高水位一旦触发libevent 会停止读取 socket这对防止慢消费者拖垮内存很有用。心跳扫描周期决定空连接多久被判定失效默认配置是 60 秒未收到任何帧就回调 on_event 的 BEV_EVENT_TIMEOUT我在内部项目里调短到 20 秒因为移动端弱网环境掉线极快。验证运行状态时我在容器里用 ss 命令观察连接数和收发队列长度ss -s 看整体连接数ss -tnp | wc 看当前端口连接数结合服务端的日志输出判断哪些连接中途异常断开。4. 连接管理与业务接入把 Echo 服务改造成能推数据的后端4.1 连接生命周期与连接池的实现方式仅能 echo 的服务端没有实用价值。要落地到业务里服务端必须能主动推送数据而这要求连接不能只活在回调参数里。源码包里的 conn_mgr 模块解决这个问题每个连接对应一个 conn_id内部用哈希表维护 fd 到具体连接对象的映射。连接接入时注册关闭时反注册。连接对象里保存了 bufferevent 指针、最近活跃时间戳、以及业务自定义的 user_data 指针。连接池的关键设计是在 on_event 回调里做统一清理。当 BEV_EVENT_EOF 或 BEV_EVENT_ERROR 触发时代码调用 conn_mgr 的 remove 接口把连接从表中摘除并释放内存。我遇到的常见问题是开发者在回调中直接 free 连接对象但同一事件循环里可能还有未执行的回调引用这个指针产生悬垂访问。这套源码用引用计数解决每次回调前引用计数加一回调结束减一计数归零才真正释放。void on_event(struct bufferevent *bev, short events, void *ctx) { connection_t *conn static_castconnection_t *(ctx); conn_ref(conn); // 防重入保护 if (events (BEV_EVENT_EOF | BEV_EVENT_ERROR)) { // 先摘除连接再触发业务层的 on_close 回调 conn_mgr_remove(conn-conn_id); if (conn-on_close) conn-on_close(conn); conn_unref(conn); // 这里真正决定是否释放内存 } else if (events BEV_EVENT_TIMEOUT) { // 心跳超时主动关闭 bufferevent_free(conn-bev); } conn_unref(conn); }conn_ref 和 conn_unref 的成对调用在源码里到处可见这是 libevent 异步模型下的标配手法。如果不做引用计数有可能会出现“回调里 free 了一个还在事件队列中的 bufferevent系统直接崩溃”的情况。我在做某数据看板的推送服务时曾跳过这一步直接把释放逻辑写在 on_close 里结果一旦推送广播密集发生进程就随机分段错误加上引用计数后问题消失。4.2 广播推送与业务消息格式约定服务端要主动推送数据需要遍历连接池并逐个向缓冲写入帧。这段逻辑在源码里对应 broadcast_text 函数void broadcast_text(const std::string msg) { ws_frame_t frame; frame.fin 1; frame.opcode 0x1; // 文本帧 frame.payload std::vectoruint8_t(msg.begin(), msg.end()); for (auto kv : conn_mgr_all()) { connection_t *conn kv.second; if (conn-state ! CONN_OPEN) continue; // 服务端到客户端帧不需要掩码 std::string out; build_frame(frame, out, /*masked*/false); evbuffer_add(conn-bev-output, out.data(), out.size()); } }服务端发帧不置 MASK 位这是协议差异点。build_frame 内部把头部字节和负载拼到同一个输出缓冲区然后再通过 evbuffer_add 排进发送队列。需要注意如果某个连接对端读取很慢高水位机制会自动触发背压此时 evbuffer 的长度会持续增长。我在生产配置里给广播加了一个节流策略单个连接输出缓冲超过 1MB 就暂时跳过该连接的下一次推送并在日志里打一条 warning避免内存被慢消费者拖垮。4.3 业务回调接口设计如何接入自己的消息处理器源码包预留了三个业务钩子on_open连接建立后触发on_message收到完整业务帧后触发on_close连接释放前触发。我接入业务逻辑时只需要实现这三个函数并注册给协议层。这里给一个接入 JSON 消息处理的最小示例void on_message(connection_t *conn, const ws_frame_t *frame) { if (frame-opcode 0x1) { // 文本帧 std::string text(frame-payload.begin(), frame-payload.end()); Json::Value req; if (Json::Reader().parse(text, req)) { if (req[type] ping) { char time_buf[32]; snprintf(time_buf, sizeof(time_buf), %ld, time(nullptr)); send_text(conn, {\type\:\pong\,\ts\:\ std::string(time_buf) \}); } } } else if (frame-opcode 0x8) { // 对端主动关闭连接由协议层自动回收 } }要注意 opcode 的区分0x8 是连接关闭帧收到后不能继续 on_message 调用业务代码否则会向一个正在关闭的连接写数据。0x9 是 Ping 帧服务端必须回 Pong 帧保持链路可用源码里在帧解析阶段就拦截了控制帧业务回调不会感知到它们的存在。我一开始误把 Ping 帧也交给了业务层处理结果前端心跳检测总是失败后来顺着协议原文查才发现服务端必须自动应答 Ping——这不是业务逻辑是协议义务。4.4 从 echo 到真实业务的三步改造路径我建议按三步改造这套源码先把 on_message 里的 echo 逻辑替换成具体的业务分发函数然后注册 on_open在其中做鉴权——比如校验 URL 参数里的 token 字段校验失败直接发 Close 帧再断开最后用 conn_mgr 的连接列表做定向推送。我在一个内部即时通讯 demo 里就是这样改造的前两步只花了一个下午第三步涉及业务语义花了更多时间梳理消息路由和离线补推。改造完成后业务层与协议层之间只靠 on_message 和 send_text 两个接口交互后续换协议实现也不影响上层逻辑。5. 避坑指南WebSocket 服务端启动到上线的常见问题排查5.1 握手返回 200 而不是 101服务端把请求当普通 HTTP 处理了现象客户端连接后服务端返回了正常的 HTTP 响应头和 200 状态码但浏览器提示 WebSocket 连接失败。原因请求头解析从上一次的历史数据里取了错误位置或者服务端先走了静态文件处理逻辑忽略了 Upgrade 字段。更常见的是开发者在事件回调里先判断是否为 HTTP 请求再决定是否走 WebSocket导致在同一个端口上服务了两种协议时有状态残留。解决在握手阶段专门检查请求头中是否同时包含 Upgrade: websocket 和 Connection: Upgrade。如果不满足直接返回 400 并关闭连接不进入业务分发。我写过一个诊断函数把收到的请求头完整打印到日志再人工对照头字段确认没有大小写问题和多余空格。Sec-WebSocket-Key 用 ExactMatch 校验格式长度为 24 字节的 Base64 字符串不符合就直接拒绝。5.2 数据粘包导致帧解析错乱半包时不能直接读 payload现象客户端连续发送多条消息服务端收到的 payload 内容乱码或长度不对有时一条消息变成了两截。原因TCP 是流协议一次读事件到达的数据可能包含多个 WebSocket 帧也可能只有一个帧的一部分。解析函数如果假定“缓冲区里刚好是一个完整帧”就会把下一个帧的头部字节误当成当前帧的 payload 内容。解决严格按状态机处理——每次只解析一个帧解析完成后检查缓冲区是否还有剩余数据有则继续解析没有则等待下一次读事件。帧不完整时绝对不能从缓冲区消耗数据只能 copyout 读取头部等数据足够后再 remove。我后来加了一个保护性断言任何一次解析结束时如果缓冲区长度不为零但不是合法帧头就直接断开这个连接防止畸形数据导致无限循环。5.3 连接无故断开心跳超时设置没有区分读写现象客户端连接一段时间后服务端主动关闭但客户端一直在正常收数据没有空闲。原因libevent 的 bufferevent 超时设置如果只设置了 read 超时那么长期只有下行数据、没有上行数据的连接也会被误判为超时。纯推送场景下行流量大上行可能只有客户端的心跳 Ping间隔稍长就会触发超时。解决为读和写分别设置超时时间。读超时设置为业务心跳周期的 1.5 倍写超时设置得更大或者干脆设为 -1 表示不限制。配置文件里我习惯写成 connection_idle_timeout30 和 write_timeout0后者表示保持默认禁用。改完后用抓包工具观察连接超过 2 分钟静默期内的行为确认服务端不会主动发 FIN。5.4 推送大量数据时进程内存持续增长evbuffer 无限积压现象服务端频繁广播大数据帧连接数不多但 RSS 内存稳步上涨最终 OOM。原因对端客户端处理慢或网络拥塞时evbuffer 输出数据堆积。代码里如果只 add 数据而不检查积压量内存会在几分钟内翻倍。另一个隐藏点是发送方在事件循环里同步构建大字符串构建过程本身占用大量临时内存。解决为每个连接设置输出缓冲水位上限超过阈值就暂停后续写入。具体做法是在发送前检查 evbuffer_get_length(conn-bev-output)超限则把连接标记为 backpressure 状态等待可写事件触发时再恢复发送。广播函数则跳过处于 backpressure 状态的连接。我还会对大帧做分片——超过 16KB 的消息拆成多个帧发送避免一个帧占用连续的巨大缓冲区。5.5 对端收到了乱序帧服务端没有尊重分片语义现象客户端收到消息的顺序不对或者消息被截断且只在并行推送时出现。原因协议规定一个分片消息由 opcode 为 0x0 的连续帧组成第一个分片帧携带业务 opcode最后一个分片帧 FIN 位为 1。如果服务端把两个独立消息的分片帧交错发送客户端重组就会失败。解决在广播场景里如果消息帧大于分片阈值先完成整个分片序列的构建再写入 evbuffer避免不同消息的分片交叉。源码的 build_fragments 函数里用一个消息队列保证同一个连接的写操作是原子的——也就是说一次广播要么完整写入所有分片要么完全不写。我增加了一个 per-connection 的发送锁用互斥量保护分片写入过程虽然这多花了一点性能但换来了协议正确性。5.6 多核服务器上性能不升反降event_base 锁竞争现象把服务端部署到 8 核机器上连接数翻倍但吞吐没有相应提升甚至下降。原因单个 event_base 在多个线程里调用 event_base_dispatch 时libevent 内部锁竞争激烈事件分发成了瓶颈。很多人误以为多开几个线程调 event_base 就能并行处理但一个 base 只能被一个线程循环处理其他线程被锁挡住。解决按连接哈希取模分散到多个 event_base每个 base 绑定一个线程连接建立后固定归属某个线程。这套源码虽然默认单线程但预留了 thread_worker 的接口我实际部署时把监听 socket 分配到 4 个 worker每个 worker 处理约四分之一的连接。要注意的是连接一旦归属某个线程就不能换线程否则 bufferevent 回调的线程上下文会乱掉。6. 进阶验证并发压测、长稳运行与一切回归测试的自动化脚本代码改完后能不能上线不能只靠手工拿着 wscat 聊两句验证。我用三个维度做回归协议正确性、并发承载、长稳内存。协议正确性方面我直接用 Python 的 websocket-client 库写了一个脚本同时模拟 500 个连接每个连接发 100 条消息服务端必须全部 echo 成功。并发承载用另一个脚本验证服务端推送广播时客户端接收到的消息总数必须严格等于广播次数乘以连接数多一条少一条都算失败。长稳回归我放在容器里跑脚本循环 24 小时每 5 分钟记录一次 RSS 和连接数。判断通过的标准很简单内存曲线不持续上升连接一直维持在预期水位。做某跨平台系统联调时我就是用同样的脚本在凌晨跑了一轮把服务端一个只在 3 小时后触发的句柄泄漏揪了出来——当时连接数没变但 fd 数量缓慢增加用脚本里的 lsof -p 统计就能看到异常。#!/usr/bin/env python3 # 回归压测脚本并发连接 消息回显校验 import asyncio, websockets, json, sys, time async def echo_case(cid, host, port, count): uri fws://{host}:{port}/ws async with websockets.connect(uri, ping_intervalNone) as ws: ok 0 for i in range(count): payload json.dumps({cid: cid, seq: i, ts: time.time()}) await ws.send(payload) resp await asyncio.wait_for(ws.recv(), timeout5) if json.loads(resp).get(seq) i: ok 1 return ok count async def main(): host, port 127.0.0.1, 8080 conns int(sys.argv[1]) if len(sys.argv) 1 else 200 msg_each 100 results await asyncio.gather(*[ echo_case(i, host, port, msg_each) for i in range(conns) ]) success sum(results) print(fpassed{success}/{conns}) sys.exit(0 if success conns else 1) if __name__ __main__: asyncio.run(main())脚本里的 ping_intervalNone 是有意为之——我要覆盖的测试场景是服务端心跳超时处理不是让客户端自己保活。asyncio.gather 并发拉起所有连接响应超时时间 5 秒超过即判定失败。我用它验证 buf_watermark 参数调整后的行为把高水位从 64KB 调到 8KB连接数不变但吞吐曲线明显下降这证明之前的内存安全阈值确实是在拿性能换保护。压测之外我最后会做两件小的收尾检查一是用抓包工具过滤 ws 协议确认服务端发出的帧 MASK 位为 0、客户端帧 MASK 位为 1这是最容易通过日志验证的协议合规项二是检查服务端收到 Close 帧后的回复行为必须回一个 Close 帧而不是直接断开 TCP。从那以后我每次改完帧解析或连接管理代码都强制走一遍这套回归脚本再交付三天两头掉链子的情况明显少了。希望帮到你。本文还有配套的精品资源点击获取