WebSocket 与 HTTP 有什么区别从单向请求到全双工实时通信01. 前言为什么有了 HTTP 还需要 WebSocket02. 核心区别一句话总结03. HTTP 的通信模式请求-响应模型3.1 传统 HTTP短连接3.2 HTTP 轮询模拟实时3.3 HTTP 长轮询Long Polling改进版04. WebSocket 的全双工通信4.1 WebSocket 连接建立过程HTTP 升级握手4.2 WebSocket 通信模式05. 详细对比WebSocket vs HTTP5.1 连接建立与维护5.2 数据传输5.3 协议开销对比示例5.4 适用场景对比06. WebSocket 帧结构简介07. WebSocket 与 HTTP/2 的关系08. 何时使用 WebSocket✅ 适合 WebSocket 的场景❌ 不适合 WebSocket 的场景09. 完整选择决策流程图10. 对比总结表11. 代码示例极简对比HTTP 轮询前端WebSocket前端12. 常见问题Q1WebSocket 能穿透代理和防火墙吗Q2WebSocket 和 SocketTCP Socket有什么区别Q3WebSocket 连接能保持多久Q4WebSocket 安全吗13. 总结The Begin点点关注收藏不迷路01. 前言为什么有了 HTTP 还需要 WebSocketHTTP 协议是 Web 的基石但它有一个天生缺陷只有客户端能主动发起请求服务器只能被动响应。这种“一问一答”的模式在需要实时推送的场景聊天、股票行情、游戏、协作编辑中显得力不从心。传统解决方案轮询、长轮询要么浪费资源要么延迟高。WebSocket应运而生——它在单个 TCP 连接上建立全双工通道让服务器也能主动“说话”。本文从协议设计、连接方式、通信模式、适用场景等角度全面对比 WebSocket 与 HTTP。02. 核心区别一句话总结维度HTTPWebSocket通信模式半双工客户端→服务器一问一答全双工双方随时互发消息连接持久性短连接1.x或持久连接1.1长连接建立后持续保持服务器推送不支持需轮询/长轮询模拟原生支持协议标识http:///https://ws:///wss://默认端口80 / 44380ws/ 443wss头部开销每次请求携带完整 HTTP 头建立连接时一次握手后续帧头很小数据格式文本HTTP 报文二进制帧文本/二进制均可状态管理无状态每个请求独立有状态连接保持上下文浏览器支持全支持主流浏览器均支持IE1003. HTTP 的通信模式请求-响应模型3.1 传统 HTTP短连接客户端 服务器 │ │ │──── 请求1req1───────────────────→│ │←──── 响应1resp1──────────────────│ │ │ │──── 请求2req2───────────────────→│ │←──── 响应2resp2──────────────────│ │ │ 每次请求需要重新建立 TCP 连接HTTP 1.0 或复用连接但仍是“一问一答”HTTP 1.13.2 HTTP 轮询模拟实时客户端 服务器 │ │ │──── 请求有新消息吗────────────→│ │←──── 响应没有 ───────────────────│ │ 等待间隔如 2 秒 │ │──── 请求有新消息吗────────────→│ │←──── 响应没有 ───────────────────│ │ 重复浪费资源 │3.3 HTTP 长轮询Long Polling改进版客户端 服务器 │ │ │──── 请求有新消息就回复我 ────────→│ │ │ 服务器hold住连接不立即响应 │ │ 直到有新消息或超时 │←──── 响应消息来了 ─────────────│ │ │ │──── 再次发起长轮询请求 ───────────→│ 重复长轮询比短轮询好但仍有缺陷每个消息需重新建立 HTTP 连接服务器需维护大量挂起连接头部开销大04. WebSocket 的全双工通信4.1 WebSocket 连接建立过程HTTP 升级握手WebSocket 复用 HTTP 的Upgrade机制完成握手客户端 服务器 │ │ │──── HTTP GET 请求Upgrade: websocket───→│ │ GET /chat HTTP/1.1 │ │ Host: example.com │ │ Upgrade: websocket │ │ Connection: Upgrade │ │ Sec-WebSocket-Key: x3JJ... │ │ Sec-WebSocket-Version: 13 │ │ │ │←──── HTTP 101 Switching Protocols ──────────│ │ HTTP/1.1 101 Switching Protocols │ │ Upgrade: websocket │ │ Connection: Upgrade │ │ Sec-WebSocket-Accept: HSmrc... │ │ │ │ 协议升级完成 │ │ │ │←──── 服务器主动推送消息帧────────────────│ │──── 客户端发送消息帧────────────────────→│ │←──── 服务器再发一条─────────────────────────│ │──── 客户端再发一条──────────────────────────→│ │ 全双工任意时刻互发 │4.2 WebSocket 通信模式建立连接后 客户端 ──────────────────────────────→ 服务器 ↑ ↓ └──────────── 全双工通道 ────────────────┘ 特点 - 双方随时可以发送消息 - 消息以帧Frame为单位帧头很小2~14 字节 - 连接保持直到一方主动关闭05. 详细对比WebSocket vs HTTP5.1 连接建立与维护特性HTTPWebSocket建立连接每次请求独立 TCP 连接或复用一次 HTTP 握手后升级连接生命周期请求响应结束后可关闭长期保持直到主动关闭心跳保活无内置机制Ping/Pong 帧内置连接数上限浏览器同域名 6~8 个HTTP/1.1单个域名通常 200 个5.2 数据传输特性HTTPWebSocket方向单向客户端发起双向服务器可主动推送数据格式HTTP 报文文本数据帧文本/二进制头部大小每次数百字节Cookie、UA 等握手后每帧 2~14 字节二进制支持有限需 Base64 编码原生支持Binary Frame消息边界靠 Content-Length / chunked帧自带边界FIN 位5.3 协议开销对比示例场景发送 10 条短消息 HTTP 轮询每次独立连接 10 × (TCP 握手 HTTP 头 消息体 挥手) ≈ 巨大开销 HTTP 长轮询每次消息需新连接 10 × (HTTP 头 消息体) ≈ 几千字节开销 WebSocket 1 × (HTTP 握手) 10 × (帧头 ~6 字节 消息体) ≈ 一次握手的开销 每消息几十字节帧头5.4 适用场景对比场景推荐协议原因普通网页浏览、RESTful APIHTTP请求-响应模型天然匹配无状态便于扩展实时聊天WebSocket双向低延迟推送服务器可主动发消息股票行情/加密货币 tickerWebSocket需要持续推送高频数据在线游戏WebSocket低延迟、全双工实时协作文档/白板WebSocket双向同步操作通知推送WebSocket 或 SSESSE单向更简单WebSocket 更灵活视频流/直播WebRTC / HLS专用协议更适合上传大文件HTTP分块WebSocket 不适合大文件上传缺少断点续传等06. WebSocket 帧结构简介WebSocket 帧格式简化 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------------------------------- |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | | | |1|2|3| |K| | | ------------------------- - - - - - - - - - - - - - - - - | Extended payload length continued, if payload len 126 | -------------------------------------------------------------- | |Masking-key, if MASK set to 1 | -------------------------------------------------------------- | Data | --------------------------------------------------------------- 关键字段 - FIN是否为最后一帧 - opcode文本(0x1)/二进制(0x2)/关闭(0x8)/Ping(0x9)/Pong(0xA) - Mask客户端→服务器必须置1掩码07. WebSocket 与 HTTP/2 的关系很多人会问HTTP/2 已经支持多路复用和服务器推送了还需要 WebSocket 吗特性HTTP/2WebSocket服务器推送支持Push Promise支持原生全双工全双工实时通信半双工仍以请求-响应为主真正的全双工消息边界流Stream有边界帧有边界更细粒度协议复杂性较高HPACK、优先级树相对简单适用场景Web 性能优化资源加载实时双向通信结论HTTP/2 的服务器推送是“一个请求带多个响应”而非服务器随时主动发消息。WebSocket 在实时双向通信上仍然不可替代。08. 何时使用 WebSocket✅ 适合 WebSocket 的场景即时通讯微信网页版、Slack实时数据推送股票、体育比分、物联网传感器多人协作Figma、Google Docs在线游戏棋牌、射击游戏实时日志/监控面板❌ 不适合 WebSocket 的场景简单的 CRUD API用 REST HTTP 更简单静态资源加载图片、CSS、JS需要缓存、CDN 加速的内容单向通知SSE 更轻量09. 完整选择决策流程图是否需要服务器主动推送消息 │ ├── 否 ──────────────────────────────────→ 使用 HTTP │ └── 是 │ ▼ 实时性要求多高 │ ├── 秒级以内聊天、游戏、交易────────→ WebSocket │ └── 秒级到分钟级通知、订阅 │ ▼ 是否只需要服务器→客户端单向推送 │ ├── 是 ──────────────────────────────────→ SSEServer-Sent Events │ 比 WebSocket 更简单 └── 否需要客户端也能主动发────────────→ WebSocket 附加考虑 - 现有基础设施是否有 WebSocket 负载均衡支持 - 客户端兼容性IE 10 以下不支持 - 降级方案能否回退到长轮询10. 对比总结表对比维度HTTPWebSocket通信方向单向客户端→服务器双向客户端⇄服务器连接方式短连接/持久连接仍是一问一答长连接全双工服务器推送不支持需模拟原生支持协议建立直接 TCP 连接HTTP Upgrade 握手协议标识http:// / https://ws:// / wss://默认端口80 / 44380ws/ 443wss消息头开销大每次数百字节小握手后每帧 2-14 字节二进制传输需 Base64 编码原生支持状态无状态有状态连接保持上下文防火墙友好全支持部分企业防火墙可能拦截适用场景普通 Web、REST API实时通信、推送11. 代码示例极简对比HTTP 轮询前端// 每 2 秒询问一次setInterval(async(){constresawaitfetch(/api/messages);constdataawaitres.json();console.log(新消息:,data);},2000);WebSocket前端constwsnewWebSocket(wss://example.com/chat);ws.onmessage(event){console.log(收到服务器推送:,event.data);};// 发送消息ws.send(Hello Server);12. 常见问题Q1WebSocket 能穿透代理和防火墙吗HTTP/HTTPS 代理ws://可能被拦截wss://TLS 加密通常可以穿透。企业防火墙可能主动阻断非标准流量需配置允许。Q2WebSocket 和 SocketTCP Socket有什么区别WebSocket 是应用层协议基于 HTTP 握手运行在 80/443 端口浏览器原生支持。TCP Socket 是传输层无法直接在浏览器中使用除非使用 WebRTC 数据通道。Q3WebSocket 连接能保持多久理论上无限但实际受网络中间设备NAT、负载均衡超时影响需定期发送 Ping/Pong 保活。Q4WebSocket 安全吗wss://相当于 HTTPS使用 TLS 加密安全。ws://是明文不安全。13. 总结┌─────────────────────────────────────────────────────────────┐ │ HTTP vs WebSocket 核心口诀 │ ├─────────────────────────────────────────────────────────────┤ │ HTTP 像打电话你问一句我答一句我不主动找你 │ │ WebSocket 像拉群随时说话双方都能主动发消息 │ │ │ │ 看网页用 HTTP搞实时用 WebSocket │ │ 普通 API 用 HTTP聊天游戏用 WebSocket │ │ 单向推送考虑 SSE双向全双工上 WebSocket │ └─────────────────────────────────────────────────────────────┘最终建议默认使用 HTTP简单、无状态、易缓存遇到实时双向通信需求聊天、行情、协作果断上 WebSocket如果只是服务器单向推送通知、订阅SSE 可能是更轻量的选择The End点点关注收藏不迷路