简介这是基于C与原生socket实现的WebSocket服务器源码包面向有一定C网络编程基础、需要自行搭建或理解WebSocket协议的开发者。程序中实现了协议握手、基于帧格式的数据解码与传输并附有在线测试网页的使用说明便于验证服务器功能。压缩包共40个文件约62.17MB主要包含cpp源码、h头文件、VS2017工程文件sln/vcxproj以及编译生成的exe、pdb、obj等中间文件另外还有ipch、tlog等VS缓存文件整体为可直接打开的完整VS工程。已有587人学习下载。通过该资源读者能直接查看服务器端握手流程、帧解析与数据收发实现细节也可基于现有工程二次开发适合学习WebSocket底层原理、研究服务端实现或作为课程设计的参考起点。1. C WebSocket 源码包从压缩包到能跑的服务器中间隔着什么如果你手里正攥着一个c websocket 源码.rar大概率是两种情况要么刚从某个下载站拖下来想找个能直接用的 WebSocket 服务端要么是接手旧项目别人丢给你一个不知道里面装了什么、也不知道能不能编译的压缩包。先说个反直觉的结论源码包能不能用往往不取决于代码本身写得好不好而是取决于它选的第三方库、构建方式和你本机的环境是否对得上。WebSocket 协议本身很简单——一次 HTTP 升级握手之后走帧收发——但 C 生态里没有官方标准库支持所以每个包背后都是一套依赖选型打开.rar的第一件事绝不是看代码而是先搞清楚它依赖了什么。这篇文章不猜你手里那个包里具体是什么代码而是把 C WebSocket 源码从拿到手到跑起来、改得动的完整路径走一遍怎么辨别源码归属、怎么在不同平台上编译、握手和收发的关键代码怎么读、最常见的翻车点在哪儿最后再给几个能直接抄的进阶技巧。2. 拿到压缩包先别解压源码归属与依赖自检2.1 三种最常见的源码包形态C WebSocket 源码包在市面上流通的形态我见过的基本是三种第一种是基于库的示例工程比如用 IXWebSocket、uWebSockets 或 WebSocket 写的服务端和客户端示例压缩包里通常带着 CMakeLists.txt 或 .sln 文件第二种是某个项目的完整源码比如嵌入式设备上的 WebSocket 服务、游戏服务器的消息推送模块这类包往往夹杂着业务代码协议部分只是其中一层第三种最让人头疼——只有一堆 .cpp 和 .h没有构建脚本这种一般是作者从自己工程里把 WebSocket 相关文件抠出来上传的能不能编译全靠你补环境。拿到.rar后我一般先右键看压缩包里的文件清单而不是直接解压这习惯能省不少事。文件清单里如果只有main.cpp、websocket_server.h这种孤零零的文件那基本就是第三种形态如果有CMakeLists.txt或者*.sln恭喜至少作者是想让你能编译的。还有一个细节值得看文件名的命名风格。WebSocketSession.cpp这种大驼峰命名大概率是照着某本经典 C 网络编程书的例子改的ws_server.cc这种短横线小写风格可能来自 Linux 或嵌入式项目。命名风格决定了它最初面向的平台也就决定了你现在需要在什么环境上折腾。用解压工具打开.rar看清单这个动作在 Windows 上直接用 WinRAR 或 7-Zip 都能做到。Linux 上可以用unrar l命令只列清单不解压命令是unrar l cwebsocket.rar。这一步真正的价值在于你能在动手之前判断这个源码包的“健康程度”避免解压之后发现缺了十几个头文件白忙一场。2.2 依赖自检没有 CMakeLists.txt 的包怎么识别库依赖如果源码包里没有构建脚本你需要靠读代码来猜依赖这是所有 C 源码落地里最磨人的一步。常见做法是打开main.cpp或server.cpp看#include列表WebSocket 相关的库头文件特征很明显IXWebSocket.h是 IXWebSocket 库websocketpp/目录是 WebSocketuWS/前缀是 uWebSocketsboost/beast/则是基于 Boost.Beast 的实现。除了 WebSocket 库本身还要留意其他依赖。看到#include boost/asio.hpp说明需要 Boost 库看到#include openssl/ssl.h说明依赖 OpenSSL看到#include json/json.h还要装 jsoncpp。这些依赖项在编译阶段才会暴露但提前识别能让你少走弯路。我在拿到一个没有构建脚本的包时第一步用grep -n #include *.h *.cpp一次性列出所有头文件依赖比逐个文件翻效率高得多。在 Windows 上如果看到#include winsock2.h和#include ws2tcpip.h说明这个项目用的 Windows 原生 socket链接时需要加ws2_32.lib如果在 Linux 上看到#include sys/socket.h那它就是 POSIX socket 实现。这两个方向本身没有优劣之分但你一定要在编译前弄清楚——我见过有人拿着 Linux 写的源码在 Windows 上硬编报错刷了一整屏socklen_t was not declared其实根本不是代码问题是平台 API 不兼容。3. 把源码变成可执行程序MSVC 与 MinGW 的构建路径3.1 用 CMake 构建先跑通最小可执行目标大多数能编译的 C WebSocket 源码包都会带 CMakeLists.txt因为 CMake 是跨平台构建的事实标准。先看 CMakeLists.txt 里target_link_libraries段这里写明了链接了哪些库是判断依赖关系最权威的依据。一个典型的 WebSocket 服务的 CMakeLists.txt 长这样cmake_minimum_required(VERSION 3.16) project(ws_server) set(CMAKE_CXX_STANDARD 17) find_package(Threads REQUIRED) # 如果依赖 OpenSSL取消下面这行注释 # find_package(OpenSSL REQUIRED) add_executable(ws_server main.cpp websocket_server.cpp) target_link_libraries(ws_server Threads::Threads # websocketxx 是 WebSocket 的头文件库不需要链接 # 如果用了 IXWebSocket这里改成 ixwebsocket )如果你的源码包用的是 WebSocket那它绝大部分功能是头文件实现的不需要单独链接库文件这对新手来说是最省心的一种。而如果用的是 IXWebSocket需要先vcpkg install ixwebsocket或者自己编译 IXWebSocket 源码多一层依赖。从我的实际经验看新手或者需要快速落地时不建议用 uWebSockets——它性能很好但依赖编译步骤繁琐且 API 设计对 C 新手不友好。CMake 构建顺序是固定的mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease cmake --build . --config Release -j4在 Windows 上如果没有make第二行的cmake ..会默认生成 Visual Studio 的.sln工程文件然后cmake --build .会调用 MSBuild 编译不需要额外操作。-j4参数控制并行编译线程数如果你的机器是 8 核以上改成-j8能快不少。如果你本机装了 Visual Studio 2022CMake 会默认检测到并生成对应工具链如果装了 MinGW需要显式指定cmake .. -G MinGW Makefiles。编译过程的第一个坎在 OpenSSL 依赖。当前很多 WebSocket 服务端为了让 wss 能工作也就是 WebSocket over TLS代码里会有条件编译的 TLS 支持。如果你只想在局域网里测试可以在 CMake 里关闭 TLScmake .. -DUSE_SSLOFF。编译报错时看到SSL_CTX was not declared这类信息不要慌基本就是 SSL 支持打开了但找不到 OpenSSL 头文件要么装 OpenSSL要么关掉 SSL 选项。3.2 没有 CMakeLists.txt 的手动编译命令对于没有构建脚本的源码包手动编译是最直接的落地方式。如果源码只依赖标准库和 socket API编译命令其实很简洁。Linux 上用 g 直接编g -stdc17 main.cpp websocket_server.cpp -o ws_server -lpthread这里-lpthread链接线程库因为 WebSocket 服务端基本都会开线程处理连接。如果代码里用了std::async或std::thread线程库必须链。有的包还会用到-lz因为 WebSocket 协议里的 permessage-deflate 扩展需要 zlib 做压缩。Windows 上用 MinGW 编g -stdc17 main.cpp websocket_server.cpp -o ws_server.exe -lws2_32 -lpthread-lws2_32是 Windows 的 Winsock 库。记住一个规律Linux 上编 C 网络程序链-lpthreadWindows 上链-lws2_32这两个库忘链了报错最凶。如果依赖了 Boost.Beast命令会变成g -stdc17 main.cpp -o ws_server -lboost_system -lpthreadBoost.Beast 的 WebSocket 实现比较“重量级”要求你熟悉 Boost.Asio 的 async 模型代码里到处是boost::asio::async_read和回调函数。新手读这种代码会有明显陡坡所以我个人不建议拿 Beast 上手它就是给已经熟悉 Asio 的人准备的。3.3 编译失败的三个高频信号源码编译失败时先看错误信息的第一行而不是最后一行编译器报错是滚动输出的真正的根因在最前面。我梳理了三个高频编译错误对应三种最常见的根因第一种报错websocket is not a member of boost原因是 Boost 库版本太旧或者根本没装全。Boost.Beast 在旧版 Boost 里不叫这个名字需要升级到 1.66 以上。解决方式是sudo apt install libboost-all-devUbuntu或者用 vcpkg 安装boost-beast。第二种报错fatal error: IXWebSocket.h: No such file or directory说明编译时头文件路径没配好。用 IXWebSocket 时头文件和库文件不是默认路径需要单独指定在网上搜索“IXWebSocket 编译”时先看你的库装到了哪里很多开源库默认装在/usr/local/include编译时加上-I/usr/local/include和-L/usr/local/lib就能解决。第三种报错undefined reference to SSL_CTX_new这就是链接 OpenSSL 库失败。前面说了要么编译时加上-lssl -lcrypto要么在代码里把 TLS 相关宏关掉。很多 WebSocket 源码会用宏控制 TLS 支持#ifdef ENABLE_TLS // TLS 初始化逻辑 SSL_CTX* ctx SSL_CTX_new(TLS_server_method()); #endif这种情况下如果编译时没定义ENABLE_TLS相关代码会被预处理器剔除不需要链接 OpenSSL。所以手动编译时要不要加-lssl取决于你在命令行里有没有加-DENABLE_TLS。先不加能跑通再说后期要搞 wss 了再加上也不迟。4. 最小可跑的 WebSocket 服务端握手到收发的代码逐行拆解4.1 服务端握手从 TCP 到 WebSocket 的那一次 HTTP UpgradeWebSocket 连接建立的第一步是 HTTP Upgrade 握手这是很多人一上来就懵的地方——WebSocket 不是从零设计的协议它是“借道” HTTP 完成协商的。客户端发过来的请求长这样GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13服务端要做的是校验Sec-WebSocket-Key拼接一个固定 GUID258EAFA5-E914-47DA-95CA-C5AB0DC85B11做 SHA-1 哈希再 Base64 编码然后返回 101 状态码。这个流程是写死的任何语言都一样。C 里手写这段逻辑代码大概是这样的#include openssl/sha.h #include openssl/evp.h std::string compute_accept_key(const std::string sec_ws_key) { std::string concat sec_ws_key 258EAFA5-E914-47DA-95CA-C5AB0DC85B11; unsigned char hash[SHA_DIGEST_LENGTH]; SHA1(reinterpret_castconst unsigned char*(concat.c_str()), concat.size(), hash); // 返回 Base64 编码结果这里用 EVP_EncodeBlock char base64[64]; int len EVP_EncodeBlock(reinterpret_castunsigned char*(base64), hash, SHA_DIGEST_LENGTH); return std::string(base64, len); }这段代码的逻辑说明第 4 行做字符串拼接固定 GUID 是 RFC 6455 规定的一个字都不能错第 5 行做 SHA-1 哈希第 7 行用 OpenSSL 的 EVP 函数做 Base64 编码。如果你不想从零写握手很多开源库已经封装好了但看懂这段代码有个实际好处——排查问题的时候客户端报“握手失败”而你怀疑是库的问题时可以自己写个测试程序单独验算这条链路很快能定位是服务端的问题还是客户端的问题。握手响应的格式也是固定的HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: 上面算出来的值收到这个响应的前提是客户端校验通过。这个环节最常见的坑是Sec-WebSocket-Accept的值算错了客户端会直接断开连接。如果你在实现自己的握手逻辑建议先用 Postman 的 WebSocket 客户端测试连接Postman 支持websocket://地址能直观看到握手请求和响应。4.2 帧收发理解 WebSocket 数据帧的二进制布局握手完成后通信就不再是 HTTP 格式了而是一个个二进制帧。WebSocket 帧的头部有固定的位布局列出了几个关键字段FIN 位表示这是不是最后一个分片opcode 表示帧类型1 是文本2 是二进制8 是关闭连接MASK 位表示有没有掩码客户端发往服务端的帧必须掩码服务端发往客户端的不许掩码payload length 有 7 位、16 位、64 位三种编码方式。C 里解析一个帧核心逻辑是这样的struct WebSocketFrame { bool fin; uint8_t opcode; bool masked; uint64_t payload_length; uint8_t mask_key[4]; std::vectoruint8_t payload; }; bool parse_frame(const std::vectoruint8_t buffer, size_t offset, WebSocketFrame frame) { if (buffer.size() - offset 2) return false; uint8_t b0 buffer[offset]; uint8_t b1 buffer[offset 1]; frame.fin (b0 0x80) ! 0; frame.opcode b0 0x0F; frame.masked (b1 0x80) ! 0; uint64_t len b1 0x7F; offset 2; if (len 126) { if (buffer.size() - offset 2) return false; len (buffer[offset] 8) | buffer[offset 1]; offset 2; } else if (len 127) { if (buffer.size() - offset 8) return false; len 0; for (int i 0; i 8; i) { len (len 8) | buffer[offset i]; } offset 8; } if (frame.masked) { if (buffer.size() - offset 4) return false; memcpy(frame.mask_key, buffer.data() offset, 4); offset 4; } frame.payload_length len; frame.payload.resize(len); for (uint64_t i 0; i len; i) { frame.payload[i] buffer[offset i]; if (frame.masked) { frame.payload[i] ^ frame.mask_key[i % 4]; } } offset len; return true; }这段代码拆开讲第 8 行到第 10 行读前两个字节b0高 1 位是 FIN低 4 位是 opcodeb1高 1 位是掩码标志低 7 位是长度。长度有 3 种编码方式126表示后面 2 个字节才是真实长度127表示后面 8 个字节是 64 位长度这是为了应对超大帧设计的。掩码处理在第 42 行到第 44 行逐字节异或掩码这是协议规定的操作但没有掩码处理的代码在浏览器客户端连接时会直接报错很多人第一次实现服务端时容易漏掉这一步。发帧的逻辑相比之下就要简单得多因为服务端不需要掩码void send_frame(int client_fd, uint8_t opcode, const std::string payload) { std::vectoruint8_t header; header.push_back(0x80 | opcode); // FIN opcode size_t len payload.size(); if (len 126) { header.push_back(static_castuint8_t(len)); } else if (len 0xFFFF) { header.push_back(126); header.push_back((len 8) 0xFF); header.push_back(len 0xFF); } else { header.push_back(127); for (int i 7; i 0; --i) { header.push_back((len (i * 8)) 0xFF); } } send(client_fd, header.data(), header.size(), 0); send(client_fd, payload.data(), payload.size(), 0); }这个函数处理了 7 位、16 位、64 位三种长度编码。很多人直接用send把 payload 发出去但忘记发头部导致客户端收到非法帧直接断连。理解了帧结构之后C WebSocket 源码在你眼里就不再是一个黑匣子而是一套可以按位操作的数据格式。之后再去读那些开源库的代码你会觉得豁然开朗。4.3 用选择器还是多线程一个通俗的架构选型逻辑C WebSocket 服务端的并发模型通常有三种做法。第一种是每连接一线程来一个客户端就std::thread开一个线程代码最简单但连接多了上千个线程切换开销大常见于入门级源码第二种是select/poll/epoll 事件驱动单线程管理所有连接代码复杂但性能上限高这是目前生产级服务端的主流做法第三种是协程C20 的 coroutine 结合库实现异步代码可读性比回调好但需要编译器支持 C20目前还不是所有源码包都已经切换到这种模式。拿到源码后看它的并发模型就知道写的水平怎么样能在数据收发关键路径上找到 epoll 相关调用的一般是能扛住生产流量的全是while(true) { accept(); std::thread(...) }的做学习和本地测试没问题拿到线上去比会吃亏。我自己的落地经验是如果 QPS 预期不超过几百每连接一线程的方式完全够用代码短、好维护出了问题也好复现。5. 避坑C WebSocket 开发中最常见的 6 个翻车现场5.1 现象浏览器连接秒断服务端没日志原因大概率是握手响应写错了。最典型的是Sec-WebSocket-Accept算错或者响应头里漏了Connection: Upgrade。这两个字段任何一个不对浏览器都会直接关闭连接而且不给你多余的信息。排查的时候先用浏览器的开发者工具看 Network 面板里 WS 连接的握手状态再用 Postman 的 WebSocket 客户端手动连接看服务端返回的响应头原文。我自己排查这类问题的时候最常发现的是 SHA-1 写成了 MD5——顺手复制了别的代码段结果就是验证失败。5.2 现象服务端发的消息浏览器收不到C 里常见原因是发送时用了std::cout或者调试日志里操作了同一个 socket导致发送顺序错乱。另一个高频原因是发送线程和接收线程同时操作同一个 socket 描述符没有加锁。多线程访问同一个 socket 在 POSIX 下是不确定行为表现就是时好时坏。解决方式要么用一个发送队列由专用线程统一发送要么在发送函数外面加std::mutex锁二选一。5.3 现象客户端收到中文乱码WebSocket 消息里的文本分片默认是 UTF-8 编码如果代码里直接把std::string当作 GBK 编码发送浏览器会把 UTF-8 解码后的字节流显示成乱码。解决方式是在发送前做编码转换。Linux 上用iconvWindows 上用MultiByteToWideCharWideCharToMultiByte转成 UTF-8 再发。这个问题在嵌入式设备上特别常见——不少设备上报的数据是 GBK 编码的如果服务端不转换而是原样转发第二个客户端收到必乱码。5.4 现象服务端长时间运行后内存持续增长WebSocket 长连接场景内存泄漏点一般不是连接本身而是每个连接附带的消息缓冲区和定时器。看代码时重点检查三处recv 缓冲区的resize次数、连接关闭时有没有释放附着在上面的用户数据、有没有给每个连接创建了定时器但从不清理。C 里最容易泄漏的模式是某个类内部new了一个缓冲区但析构函数什么都没做。我常用的套路是在连接关闭处理函数里从头走一遍清理逻辑逐个delete或reset宁可多清理不要少清理因为大多数库对重复清理是安全的但漏清理就是泄漏。5.5 现象握手日志显示连接进来了但业务层拿不到数据原因是数据帧解析只处理了单帧没有处理分片。WebSocket 协议允许发送方把一个消息拆成多个帧传输比如发 1MB 大字符串时会自动分片如果只读了第一帧就交给业务层后续帧就会堆积在缓冲区里业务层以为没数据。解决方式是在解析帧时判断FIN位fin false的帧要缓存起来直到出现fin true的帧才算一条完整消息。分片处理逻辑是新手最容易忽略的但浏览器在发送大文件时几乎必然触发分片。5.6 现象编译通过运行时提示不支持或握手超时出现这种问题往往不是代码的问题而是网络环境里存在代理服务器或者中间设备拦截了 Upgrade 请求。某些企业内网的防火墙对Connection: Upgrade头敏感会直接丢弃。排查方式在本地跑telnet 127.0.0.1 8888手动发一次 HTTP Upgrade 请求如果本地能通说明代码没问题问题出在网络上。关于网络环境的排查思路本身是个纯工程问题遇到这类情况换个网络环境做对照测试基本就能定位。6. 从能跑到好用三个值得掌握的实战技巧6.1 用回调代替代码里到处撒的解析逻辑开源库普遍采用回调接口处理消息如果你的源码包是自己解析帧的我建议改成回调派发。具体的做法是把解析出的opcode匹配到一个函数表比如std::unordered_mapuint8_t, std::functionvoid(const std::string)。好处是新增消息类型时不需要改解析核心只需要往表里注册一个函数。这个技巧也把源码包里的协议层和业务层解耦后面接数据库或者接其他 IPC 更方便。6.2 连接保活与心跳为什么你的连接总是被中间设备切断任何 WebSocket 服务端在长时间没有数据交互时都会被中间的 NAT 网关或者负载均衡器掐断因为空闲连接不占资源但占连接表项这些设备普遍有 60~120 秒的空闲超时策略。应对方式是发 Ping 帧保活。WebSocket 协议里 Ping/Pong 是独立于业务帧的控制帧opcode 为 9 和 10Ping 帧的 payload 可以携带任意数据通常为空对端收 Ping 必须回 Pong。给服务端加一个定时器线程每 30 秒向所有连接发一次 Ping如果 10 秒内没收到 Pong就主动关闭该连接这是生产级服务端的标准做法。6.3 wss 改造当你的服务要从内网走向公网最后一条经验是关于 wss 的。WebSocket 的ws://和http://是同级协议而wss://对应https://底层是经过 TLS 加密的。如果未来你的服务要部署到公网或者域名通过 HTTPS 提供页面浏览器会拦截非安全来源的 WebSocket 连接——也就是 HTTPS 页面里只能连wss://不能连ws://。改造方式有两种一种是在 C 代码里直接启用 TLS 支持用 OpenSSL 加载证书把 accept 套接字包成 SSL 通道另一种更常见是把 WebSocket 服务放在 Nginx 后面由 Nginx 负责 TLS 终结再反向代理到 C 服务的ws://端口这种方式对 C 代码的侵入最小只改一个 Nginx 配置加一段证书配置就能实现。我自己的习惯是不管当前项目有没有上公网的打算代码里都预埋 TLS 开关条件编译写好省得将来大动干戈改框架。这个习惯帮我在好几个项目上避免了“页面要上 HTTPS、WebSocket 掉链子”的尴尬。C WebSocket 源码这个东西只要理解了握手、帧格式、并发模型这三根柱子剩下的就是经验的积累。拿到任何一份源码包先看依赖、再理构建、然后跑通最小示例最后再谈改造——这个顺序走下来大部分包都能在半小时内跑起来。希望这篇笔记能帮你在 WebSocket 源码的迷雾里找到一条清晰的路径。本文还有配套的精品资源点击获取