websocket与http本质不同：前者是基于tcp的全双工长连接协议，仅握手阶段复用http，之后完全脱离；后者是单向请求-响应的无状态短连接协议，无法实现服务端主动推送。
WebSocket 和 HTTP 不是“升级关系”，也不是“谁更好”的问题——它们压根解决的是不同场景下的通信需求。选错协议，轻则浪费资源、延迟飙升，重则根本跑不起来。
WebSocket 握手后就和 HTTP 没关系了
很多人误以为 WebSocket 是“HTTP 的加强版”，其实它只是借了 HTTP 的壳完成初始握手。客户端发一个带 Upgrade: websocket 头的 HTTP GET 请求，服务端返回 101 Switching Protocols，之后所有数据帧都走 WebSocket 协议，不再带任何 HTTP Header。
- 握手阶段用 HTTP，是为了兼容现有代理、CDN、防火墙等基础设施
- 握手成功后，TCP 连接被“协议升级”，底层仍是 TCP，但上层协议彻底切换为 WebSocket 帧格式（头部仅 2–14 字节）
- 浏览器里用
new WebSocket('wss://...')，和服务端的ws或wss服务交互，不是在发 HTTP 请求
HTTP 无法实现服务端主动推送
这是最常被低估的硬边界。HTTP 的语义决定了：没有客户端请求，服务端连发个空包都不合法。你看到的“实时通知”，背后要么是轮询（setInterval + fetch），要么是长轮询（服务端 hold 住响应直到有数据），全都有明显缺陷：
- 轮询：固定间隔拉取，有延迟、空请求多、连接频繁重建，服务端压力随用户数线性上涨
- 长轮询：单连接生命周期变长，但仍是“一问一答”，服务端不能持续推多条，且超时重连逻辑复杂
- HTTP/2 Server Push 已被主流浏览器弃用，不能用于通用实时推送
而 WebSocket 允许服务端在任意时刻调用 socket.send() 推送消息，无需客户端先发信号。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
连接生命周期和状态管理完全不同
HTTP 默认无状态、短连接；WebSocket 是有状态、长连接。这个差异直接影响你写代码的方式：
- HTTP 请求中，身份靠每次携带
Authorization或Cookie维持；WebSocket 连接建立后，服务端通常在connection事件里做一次鉴权，之后整个生命周期内复用该连接上下文 - HTTP 每次请求都要解析 URL、Header、Body；WebSocket 连接建立后，收发的是裸数据帧（可 JSON、二进制），解析成本极低
- HTTP 客户端断开后服务端无感知（除非加心跳或超时清理）；WebSocket 断连会触发明确的
close或error事件，便于清理资源
别在不该用 WebSocket 的地方硬上
WebSocket 不是银弹。它带来实时能力的同时，也引入了新负担：
- 服务端需维护连接池、处理粘包/分片、实现心跳保活（如每 30s 发
ping）、设计断线重连策略 - 负载均衡器必须支持 WebSocket（识别
Upgrade头并保持连接粘滞），否则容易出现连接被随机转发导致中断 - CDN 通常不缓存 WebSocket 流量，静态资源加速和动态接口加速不能套用同一套方案
- 浏览器对并发 WebSocket 连接数有限制（一般 6–10 个/域名），不像 HTTP 可靠复用连接
真正需要它的时候，是当你的业务逻辑里反复出现“等服务器通知”“实时同步状态”“多人协同动作”这类描述——而不是因为“听起来更高级”。
