本文详解 websocket 握手协议规范及 c 语言服务器端的关键实现要点，重点解决因未正确解析/编码 websocket 数据帧导致的 “invalid frame header” 浏览器错误。涵盖 sec-websocket-key 验证、sec-websocket-accept 计算、掩码处理及二进制帧解码全流程。
本文详解 websocket 握手协议规范及 c 语言服务器端的关键实现要点，重点解决因未正确解析/编码 websocket 数据帧导致的 “invalid frame header” 浏览器错误。涵盖 sec-websocket-key 验证、sec-websocket-accept 计算、掩码处理及二进制帧解码全流程。
WebSocket 协议并非简单的 HTTP 升级，而是在完成标准 HTTP 握手后，彻底切换为基于帧（frame-based）的二进制通信协议。浏览器报错 Invalid frame header 并非源于握手响应头格式错误（如你提供的 101 Switching Protocols 响应本身合法），而是因为：服务器在握手成功后，直接向 socket 写入了未经 WebSocket 帧格式封装的明文数据（如 "OK" 或 JSON 字符串），违反了 RFC 6455 对数据帧结构的强制要求。
✅ 正确握手响应的关键点
你的握手响应缺少两个必要头部，且 Sec-WebSocket-Accept 的生成必须严格符合规范：
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: 57dCnQc8YJrJ51osdI/I71QHYi4= // ✅ 必须添加（显式声明无扩展，避免协商失败） Sec-WebSocket-Extensions: // ✅ 推荐添加（明确字符集，避免解析歧义） Content-Type: text/plain; charset=utf-8
其中 Sec-WebSocket-Accept 的计算公式为：base64(sha1(Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))
请务必使用标准 SHA-1 + Base64 实现（如 OpenSSL 的 EVP_DigestInit/EVP_DigestUpdate/EVP_DigestFinal），而非简单哈希。
⚠️ 握手后通信的致命陷阱：必须帧编码
浏览器建立 WebSocket 连接后，所有后续通信必须使用 WebSocket 数据帧格式，不可直接发送裸字符串。关键规则包括：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
服务端发送给浏览器的数据必须掩码（masked）：RFC 6455 要求 客户端发送的帧必须掩码，服务端发送的帧可不掩码，但Chrome/Firefox 等主流浏览器实际强制要求服务端帧也需掩码，否则直接触发
Invalid frame header。 - 帧结构不可省略：最小文本帧至少包含 2 字节头部（FIN+opcode+payload len）+ 可选掩码键 + 实际载荷。
以下为安全发送 UTF-8 文本消息的 C 语言帧编码示例（使用 OpenSSL 和标准 socket）：
websocket
