websocket不能取代http，二者适用场景不同：http适合页面加载、api查询等一次性交互，websocket适用于服务端主动推送、低延迟双向通信场景。
WebSocket 和 HTTP 不是“能不能互相替代”的关系，而是“在什么场景下该用谁”的问题。直接结论：需要服务端主动推数据、低延迟双向通信时选 WebSocket；普通页面加载、API 查询、文件下载等一次性交互，HTTP 更合适、更轻量、更可靠。
WebSocket 握手为什么必须走 HTTP？
不是设计者偏爱 HTTP，而是为了绕过现有网络基础设施的限制。几乎所有防火墙、代理、CDN 都默认放行 80 和 443 端口上的 HTTP 流量。WebSocket 利用这个共识，在初始阶段伪装成一个带 Upgrade: websocket 头的 HTTP 请求，骗过中间设备完成 TCP 连接建立和协议协商。
一旦服务器返回 101 Switching Protocols，后续所有帧（frame）就彻底脱离 HTTP 格式，不再有状态码、Header、Cookie、Content-Length —— 只有精简的二进制或 UTF-8 文本帧，头部通常仅 2–14 字节。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 客户端发的
Sec-WebSocket-Key是 Base64 编码的随机数，不是密钥，只防缓存和简单探测 - 服务端算出的
Sec-WebSocket-Accept必须严格按 RFC 6455 规则：对Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"做 SHA-1 再 Base64 - 如果后端用 Nginx 做反向代理，必须显式配置
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade，否则握手直接失败
HTTP keep-alive 和 WebSocket 持久连接本质不同
Connection: keep-alive 只是复用底层 TCP 连接来发多个 HTTP 请求，每次请求仍是独立的 Request-Response，服务器不能在无请求时主动发响应。而 WebSocket 握手完成后，TCP 连接上跑的是完全不同的帧协议，双方随时可发 text、binary、ping/pong 帧，状态持续维持，直到一方发 close 帧或 TCP 断连。
- HTTP keep-alive 连接空闲超时通常由服务器设为几十秒（如 Nginx 默认
keepalive_timeout 75s），超时即断 - WebSocket 连接默认无超时，但真实环境中必须靠心跳（
ping/pong帧）保活，否则 NAT 网关或移动基站可能在 30–120 秒内静默回收连接 - 浏览器中
fetch()或XMLHttpRequest即使开了 keep-alive，也无法接收服务端自发推送的数据
什么时候不该强行用 WebSocket？
把 WebSocket 当成“更高级的 HTTP”是常见误区。它解决的是特定问题，不是通用替代品。
- 纯静态资源加载（HTML/CSS/JS/图片）：HTTP/2 多路复用 + cache-control 已足够，加 WebSocket 反而增加握手开销和连接管理复杂度
- 一次性表单提交或查询（如搜索、登录）：HTTP 语义清晰、天然支持重试、浏览器 DevTools 易调试、CDN 可缓存，WebSocket 需自己实现 request-id、超时、重发逻辑
- 弱网移动设备长连：TCP 层面对丢包、乱序、NAT 超时极其敏感，没做
ping/pong、重连退避、离线队列，连接极易无声中断 - 服务端无状态横向扩展：HTTP 天然无状态，可随意加机器；WebSocket 连接绑定具体后端实例，需额外引入 Redis 订阅/广播或 sticky session，架构陡增复杂度
真正关键的不是协议本身多酷，而是你是否清楚：谁发起第一笔数据？数据流向是否必须双向？延迟容忍度是多少？连接生命周期能否被业务自然闭环？这些比“用不用 WebSocket”更决定成败。
