websocket 是应用层协议，非 socket；浏览器因安全限制仅允许通过 http 升级机制建立连接，强制使用 ws/wss uri scheme，且需严格遵循 rfc6455 握手与帧格式。
WebSocket 不是 Socket 的“高级版”，也不是另一种 Socket；它根本就不是 Socket——它是应用层协议，而 Socket 是操作系统提供的通信接口。想用 WebSocket，底层必须靠 TCP Socket 支持；但你写一个 socket() 系统调用，跟 WebSocket 协议毫无关系。
WebSocket 握手阶段为什么必须走 HTTP？
因为浏览器安全策略限制：它不允许前端 JavaScript 直接创建原始 TCP 连接（即调用 socket()），只能通过标准 Web API 发起连接。所以 WebSocket 设计了“升级”机制——先发一个带 Upgrade: websocket 头的 HTTP 请求，服务端同意后，双方在同一个 TCP 连接上切换协议，后续数据就不再走 HTTP 格式。
常见错误现象：
- 直接在浏览器里 new WebSocket('tcp://127.0.0.1:8080') → 报错
SecurityError: Failed to construct 'WebSocket': The URL's scheme must be either 'ws' or 'wss' - 服务端没正确响应
101 Switching Protocols→ 浏览器连接立即关闭，控制台显示WebSocket connection to 'ws://...' failed
关键点：
-
ws://和wss://是 URI scheme，不是协议本身，只是告诉浏览器“我要走 WebSocket 协议” - 握手请求必须包含
Sec-WebSocket-Key，服务端要算出对应Sec-WebSocket-Accept值返回，否则浏览器拒绝升级 - 这个过程复用 HTTP 端口（如 80/443），方便穿透防火墙和代理
为什么不能用普通 TCP Socket 替代 WebSocket 实现网页实时通信？
不是技术上做不到，而是浏览器根本不让你干这事。JavaScript 没有暴露 socket()、connect()、send() 这类系统调用接口，这是刻意为之的安全隔离。
使用场景差异很实际：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 你想写一个桌面客户端连游戏服务器？直接用
net.Socket（Node.js）或socket.socket()（Python）建 TCP 连接，自己定义帧头、心跳、重连逻辑 - 你想让网页实时收订单通知？只能走
WebSocket，服务端得跑 WebSocket 服务（如ws库、uWebSockets、Spring WebSocket），不能只开个 raw TCP 端口等着浏览器连
性能影响小但兼容性决定生死：
- raw TCP 连接在 Node.js 后端或 C++ 服务中更轻量，无协议解析开销
- 但浏览器端零支持——你没法绕过同源策略、CSP、混合内容限制去连裸 IP + 端口
WebSocket 数据帧和 TCP 字节流有什么本质不同？
TCP 只管可靠地传字节流，不关心“哪几个字节是一条消息”；WebSocket 在其上加了一层明确的消息边界：每个 WebSocket 帧自带长度、掩码（客户端发时必掩码）、操作码（text/binary/ping 等），浏览器 onmessage 回调每次收到的都是一个完整语义消息，不是粘包或半包。
容易踩的坑：
- 用
net.Socket写的服务端，如果直接把 WebSocket 帧二进制原样转发，浏览器会静默断连——因为没按 RFC6455 解析帧、没处理掩码、没回pong - 误以为
WebSocket.send()是原子操作：它内部会分帧、加掩码、可能缓冲，网络卡顿时仍可能触发onerror或连接中断 - 二进制数据传
ArrayBuffer没问题，但传Buffer（Node.js）或bytes（Python）前必须确认服务端是否启用了 binaryType 支持
什么时候该选 raw TCP Socket，什么时候必须用 WebSocket？
看两端能不能自主控制通信栈。能，就用 Socket；一端被锁死在浏览器里，就必须用 WebSocket。
典型判断条件：
- 通信一端是浏览器（含 WebView、Electron 渲染进程）→ 强制
WebSocket，别挣扎 - 两端都是可控服务（如 Java 微服务 ↔ Go 微服务）→ 用
net.Conn+ 自定义协议更高效，省掉 WebSocket 握手和帧解析 - 需要跨公网、穿企业防火墙 →
WebSocket复用 443 端口，比自定义 TCP 端口存活率高得多 - 对延迟极端敏感（如高频交易行情推送）→ WebSocket 的帧开销（2~14 字节）比 HTTP 小，但比裸 TCP 多；若两端都可控，可考虑 QUIC 或自研 UDP 协议
最常被忽略的一点：WebSocket 不是“更高级的 Socket”，它是“浏览器唯一允许你用的、基于 Socket 的协议”。它的复杂性不在底层，而在握手、帧格式、生命周期管理——这些你用 socket() 时全得自己实现，而 WebSocket 已经帮你焊死了。
