WebSocket 和 HTTP 有什么区别？

简化版

HTTP 是「请求-响应」模式、半双工、无状态——必须客户端先请求，服务器才能回，服务器不能主动推。WebSocket 是全双工的持久连接——建立一次后，双方都能随时主动发消息，适合聊天、推送、实时协作这类要服务器主动推送的场景。WebSocket 借用 HTTP 完成握手（Upgrade 升级），之后就走独立的 ws/wss 协议了。

详细版

维度	HTTP	WebSocket
通信模式	请求-响应，半双工	全双工，双向随时发
谁能发起	只能客户端请求	双方都能主动发
连接	（1.1）长连接但仍是一问一答	一次握手后持久双向
服务器推送	不能（要靠轮询）	能，天然支持
协议标识	http:// / https://	ws:// / wss://（wss 是加密的）
头部开销	每次请求都带完整头	握手后数据帧头部极小
适用	普通请求、页面、API	实时通信：聊天、推送、行情、协作

建立过程：WebSocket 复用 HTTP 完成握手——客户端发一个带 Upgrade: websocket 的 HTTP 请求，服务器同意后返回 101 Switching Protocols，连接就从 HTTP「升级」为 WebSocket，之后双方在这条 TCP 连接上全双工通信。

完整版教学

一、核心区别：谁能主动说话

HTTP 和 WebSocket 最本质的差异是通信方向：

HTTP 是半双工的一问一答：必须客户端先发请求，服务器才能响应。服务器无法主动给客户端发消息。哪怕是 HTTP/1.1 的长连接，也只是复用 TCP 连接，通信仍是「客户端问、服务器答」。
WebSocket 是全双工：连接建立后，客户端和服务器是平等的，谁都能在任意时刻主动发消息，不用等对方先开口。

所以凡是需要「服务器主动推送给客户端」的场景（新消息提醒、股票行情、在线协作），HTTP 天生做不到，WebSocket 正合适。

二、没有 WebSocket 之前：轮询的痛

在 WebSocket 出现前，要实现「服务器有新数据就通知客户端」，只能用 HTTP 变着法子模拟：

短轮询：客户端每隔几秒发一次请求问「有新数据吗」。缺点是大量无效请求、实时性差、浪费资源。
长轮询（long polling）：客户端发请求后服务器挂起不立即回，等有数据了再返回，客户端收到后马上再发下一个。比短轮询好，但仍有连接反复建立、服务器挂起连接的开销。

这些都是在「HTTP 只能客户端发起」的限制下打的补丁。WebSocket 从根本上解决了它——建立一条持久的双向通道，服务器有数据直接推。

三、WebSocket 为什么要借 HTTP 握手

WebSocket 并不是完全另起炉灶，它的握手复用 HTTP：

客户端请求（看起来像普通 HTTP 请求，但带升级头）：
  GET /chat HTTP/1.1
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: xxxxx

服务器同意：
  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: yyyyy

这么设计是为了兼容现有网络设施——借用 HTTP 的 80/443 端口和握手，能顺利穿过防火墙、代理。握手成功（101 状态码）后，这条 TCP 连接就不再走 HTTP，而是走 WebSocket 的数据帧协议了。

四、握手后的高效：极小的帧头

建立连接后，WebSocket 传输数据用的是轻量的数据帧，帧头只有几个字节。对比 HTTP：每个 HTTP 请求都要带上完整的请求头（Cookie、User-Agent 等，可能上百字节）。所以在高频小消息的实时场景，WebSocket 的开销远小于反复发 HTTP 请求。

五、怎么选

普通请求/页面加载/REST API → HTTP。请求-响应模型足够，简单、可缓存。
需要服务器主动推、双向实时 → WebSocket。聊天、消息推送、实时行情、协同编辑、在线游戏。
也有折中方案 SSE（Server-Sent Events）：基于 HTTP 的服务器单向推送，比 WebSocket 简单，但只能服务器→客户端单向。

六、常见误区

❌ 以为 HTTP/1.1 长连接就能服务器推送——长连接只是复用 TCP，通信仍是客户端发起的一问一答。
❌ 以为 WebSocket 和 HTTP 完全无关——它借用 HTTP 完成握手（101 Switching Protocols），之后才独立。
❌ 用轮询硬扛实时需求——短/长轮询浪费资源，实时推送该用 WebSocket。
❌ 把 ws 和 wss 搞混——ws 明文，wss 是基于 TLS 的加密版（对应 HTTP 与 HTTPS）。

六、常见误区与追问

考点	正确口径
HTTP	请求-响应模式，客户端主动发起
WebSocket	一次握手后全双工，服务端可主动推送
适用	实时聊天、行情、协同编辑等双向低延迟场景

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade

101 Switching Protocols

WebSocket 借 HTTP 完成握手，但升级后传输的不再是普通 HTTP 请求响应。

误区：WebSocket 是 HTTP 长轮询。 长轮询仍是反复 HTTP 请求，WebSocket 是持久全双工连接。
误区：WebSocket 建连后服务端仍必须等客户端请求。 WebSocket 全双工，服务端可以主动发送消息。
误区：WebSocket 一定比 HTTP 适合所有接口。 普通 CRUD 请求用 HTTP 更简单，WebSocket 适合高频双向实时消息。
追问：为什么握手用 HTTP？ 复用 HTTP Upgrade 机制和现有端口、代理基础设施。
追问：WebSocket 如何保证安全？ 使用 wss:// 通过 TLS 加密，并在握手阶段做认证和 Origin 校验。
追问：心跳为什么重要？ 长连接可能被 NAT、代理或网络异常断开，心跳用于探活和及时清理。

七、加强记忆

HTTP 是半双工的请求-响应、服务器不能主动推；WebSocket 是全双工持久连接、双方随时主动发，适合聊天/推送/实时协作。WebSocket 借 HTTP 握手（Upgrade + 101 Switching Protocols）后升级为独立协议（ws/wss），帧头极小。没它之前只能用短/长轮询模拟，浪费资源。

简化版

详细版