WebSocket 是什么：和 HTTP 轮询相比解决了什么问题

聊天软件、股票行情、多人协作文档这类需要"服务器主动推消息给你"的场景，用传统 HTTP 请求-响应模式很别扭——HTTP 天生是客户端问一句服务器答一句。WebSocket 就是为解决这个问题而设计的协议。

目录

1. WebSocket 和 HTTP 的关系：从握手升级而来
2. 全双工：为什么比轮询、长轮询更适合实时通信
3. 心跳保活：为什么需要 ping/pong
4. ws:// 和 wss://

1. WebSocket 和 HTTP 的关系：从握手升级而来

WebSocket 连接的建立复用了 HTTP：客户端先发一个特殊的 HTTP 请求，带上 Upgrade: websocket 和 Sec-WebSocket-Key 这两个 Header，告诉服务器"我想把这条连接从 HTTP 升级成 WebSocket"；服务器如果同意，会返回状态码 101 Switching Protocols，并用 Sec-WebSocket-Key 加上一个协议里固定写死的 GUID 字符串（258EAFA5-E914-47DA-95CA-C5AB0DC85B11）计算 SHA-1 哈希再 Base64 编码，作为 Sec-WebSocket-Accept 返回——这个固定算法只是为了确认双方都是真的支持 WebSocket 协议的实现，防止普通 HTTP 服务器被误当成 WebSocket 服务器。握手成功后，这条 TCP 连接就不再是 HTTP 语义了，双方开始用 WebSocket 自己的帧格式通信。

2. 全双工：为什么比轮询、长轮询更适合实时通信

在 WebSocket 出现之前，Web 实时通信主要靠两种"模拟"手段：

• 轮询（Polling）：客户端每隔几秒发一次 HTTP 请求问服务器"有没有新消息"，不管有没有新数据都要发请求——大量无效请求浪费带宽和服务器资源，而且延迟取决于轮询间隔（间隔太短浪费资源，太长又不够及时）
• 长轮询（Long Polling）：客户端发请求后，服务器不立刻响应，而是"挂住"这个连接直到有新数据才返回，客户端收到响应后立刻发起下一次请求——比轮询效率高一些，但本质上还是一问一答，且需要不断建立新连接

WebSocket 是全双工的：握手完成后建立一条持久连接，客户端和服务器都能在任意时刻主动向对方发送消息，不需要"先问后答"这个前提——服务器有新数据直接推送过去，不用等客户端来问，一条连接就能支撑起真正意义上的双向实时通信。

3. 心跳保活：为什么需要 ping/pong

WebSocket 连接一旦建立就会长时间保持打开状态，但网络中间的路由器、NAT 网关、反向代理往往会把"长时间没有数据传输"的连接判定为"已经没用了"，主动断开它以节省资源。为了防止这种误判，WebSocket 协议内置了 ping/pong 帧：一方定时发一个 ping 帧，对方收到后自动回一个 pong 帧，这个小小的数据交换能让中间设备认为连接"仍然活跃"，从而避免被意外断开；同时 ping/pong 的往返也能用来检测连接是否真的还存活（超时没收到 pong 就可以判定连接已经失效，触发重连）。

4. ws:// 和 wss://

和 HTTP/HTTPS 的关系类似：ws:// 是未加密的 WebSocket 连接，wss:// 是跑在 TLS 之上的加密版本（复用 HTTPS 的加密通道）。生产环境应该始终使用 wss://，尤其是浏览器发起的连接——很多浏览器策略也要求 HTTPS 页面只能发起 wss:// 连接（禁止在加密页面里发起未加密的 ws://，即"混合内容"限制）。

在线工具：websocket接口测试