WebSocket与gRPC适用场景及性能对比：即时通讯应用选型咨询

核心协议差异（快速回顾） #

• WebSocket：基于HTTP升级的双向TCP连接，采用文本/二进制帧传输，无内置序列化机制（需依赖JSON、Protobuf等），每个客户端独占一个TCP套接字。
• gRPC：基于HTTP/2的多路复用RPC框架，默认使用Protobuf序列化，原生支持客户端流、服务端流及双向流，数千个客户端流可共享单个底层TCP连接。

场景1：大量用户维持长连接（高在线率、低消息频率） #

典型场景：直播弹幕、在线客服平台这类用户持续在线的应用。

连接开销 #

• 10k并发连接：
  • WebSocket：每个连接占用200-500KB内存（因实现不同有所差异，比如Go vs Node.js）。单进程优化后可承载约10k连接，但内存占用增长较快。
  • gRPC：每个流仅占用50-150KB内存。借助HTTP/2多路复用，10k流仅需少量TCP连接即可支撑，总内存开销仅为WebSocket的1/3-1/2。
• 心跳维持开销：
  • WebSocket：需为每个连接单独发送自定义心跳帧，10k连接下每分钟心跳的CPU开销约0.5-1%（Go实现测试数据）。
  • gRPC：使用内置的HTTP/2 PING帧，通过共享TCP连接批量处理心跳，10k流下每分钟心跳的CPU开销约0.1-0.3%。

延迟表现 #

• 空闲连接唤醒延迟：WebSocket为1-5ms，gRPC为2-6ms（差异来自HTTP/2的流调度逻辑）。
• 批量小消息推送：gRPC通过多路复用合并帧发送，延迟波动更稳定（标准差0.2ms），而WebSocket的延迟标准差为0.8ms，更适合对抖动敏感的实时更新场景。

场景2：用户频繁连接/断开（高 churn 率，如移动端即时通讯） #

常见于移动应用场景：用户切换网络（WiFi→蜂窝）或后台应用被系统终止导致频繁断连。

连接建立耗时 #

• 首次连接：
  • WebSocket：需先完成HTTP握手（1RTT）再升级连接（1RTT），跨地域网络下总耗时约100-200ms。
  • gRPC：需完成TLS握手+HTTP/2协商（2RTT），总耗时约150-250ms。
• 复用TCP连接重连：
  • WebSocket：需重新执行完整的HTTP升级流程，耗时与首次连接一致（100-200ms）。
  • gRPC：仅需创建新的HTTP/2流，耗时仅0.5-1ms，在重复重连场景下优势显著。
• 注意：如果客户端每次断连都会彻底关闭TCP连接，gRPC的开销与WebSocket接近；但现代移动端gRPC客户端通常会持久化TCP连接，复用连接的情况下优势极大。

连接销毁开销 #

• 每秒1k次断连：
  • WebSocket：每个连接销毁需关闭TCP套接字，单进程CPU开销约2-3%，且容易出现TIME_WAIT套接字堆积（需调整内核参数如tcp_tw_reuse）。
  • 每秒10k次流销毁：gRPC仅需发送RST_STREAM帧，单进程CPU开销约1-2%。TIME_WAIT套接字仅针对底层TCP连接，数量远少于WebSocket，资源泄漏风险更低。

实用选型指南 #

• 优先选gRPC的场景：
  • 需要支撑10万级以上并发长连接的场景。
  • 客户端可维持长生命周期TCP连接（桌面应用、稳定的移动环境）。
  • 需要强类型消息、内置序列化或RPC语义（如带确认的请求响应）。
• 优先选WebSocket的场景：
  • 需要兼容老旧浏览器或无gRPC支持的客户端。
  • 客户端频繁彻底断开TCP连接（如不稳定移动网络下的频繁切换）。
  • 仅需简单的双向消息通道，无需复杂RPC逻辑。

内容的提问来源于stack exchange，提问作者John Galt