在移动端实时通信中，WebSocket与HTTP/2各有何优缺点？请结合具体场景（如聊天消息推送、直播弹幕）说明如何选择合适的技术方案。
Tencent软件开发-移动客户端开发方向难度：中等
答案
1) 【一句话结论】WebSocket适合高频、双向、低延迟的实时交互场景（如即时聊天），HTTP/2适合低频、单向或少量双向、需兼容HTTP生态的场景（如直播弹幕），选择时需结合消息频率、延迟要求、兼容性需求。
2) 【原理/概念讲解】
首先解释WebSocket：WebSocket是一种基于TCP的全双工、持久化连接协议，在HTTP握手后升级为“专线”连接，客户端与服务器可同时发送数据，无需重复建立连接，类似“两个人用专线通话，随时能说随时能听，不用每次都拨号”。
再解释HTTP/2：HTTP/2是基于HTTP的优化协议，通过二进制分帧、多路复用等技术提升性能，支持一个连接上同时传输多个请求/响应，本质还是“请求-响应”模式，连接是“多车道公路”，适合少量、不频繁的通信，或需利用HTTP生态的场景。
3) 【对比与适用场景】
| 特性/维度 | WebSocket | HTTP/2 |
|---|---|---|
| 定义 | 基于TCP的全双工、持久化连接协议 | 基于HTTP的优化协议，支持多路复用 |
| 连接方式 | 持久连接（单连接多消息） | 短期连接（默认5分钟超时），可保持长连接 |
| 通信模式 | 全双工（双向同时） | 半双工（请求-响应顺序） |
| 延迟 | 低（无连接建立开销） | 较低（多路复用减少连接建立） |
| 兼容性 | 需特殊协议，兼容性一般 | 完全兼容HTTP生态（浏览器、服务器均支持） |
| 使用场景 | 即时聊天、在线游戏、实时协作 | 直播弹幕、静态资源推送、少量消息通知 |
| 注意点 | 连接建立需握手（成本较高），需处理心跳 | 需保持连接（避免频繁建立），需处理HTTP/2头部压缩 |
4) 【示例】
以“聊天消息推送”为例：
- WebSocket方案：客户端与服务器建立WebSocket连接后，服务器收到用户A的消息直接推送给A，A可实时收到，无需等待请求响应；
- HTTP/2方案：客户端发起HTTP/2请求（如POST /message），服务器返回响应（包含消息），但需多次建立连接（除非保持长连接），延迟较高。
因此，聊天消息推送更适合WebSocket。
5) 【面试口播版答案】
“面试官您好，关于WebSocket和HTTP/2在移动端实时通信的选择，核心结论是：WebSocket适合高频、双向、低延迟的实时交互场景（比如即时聊天），而HTTP/2适合低频、单向或少量双向、需兼容HTTP生态的场景（比如直播弹幕）。具体来说，WebSocket是基于TCP的全双工持久连接，像专线一样，能实时双向通信，但连接建立成本高，适合聊天这类频繁消息的场景；HTTP/2是基于HTTP的优化协议，通过多路复用减少连接建立，适合弹幕这类消息量不大、偶尔更新的场景。比如聊天消息推送用WebSocket，直播弹幕用HTTP/2，这样能平衡性能和兼容性。”
6) 【追问清单】
- 问题：WebSocket的连接建立成本如何？
回答要点：WebSocket需先通过HTTP握手升级为持久连接，首次建立成本较高，但后续消息传输成本低。 - 问题：HTTP/2的多路复用是否会影响消息顺序？
回答要点：HTTP/2的多路复用不会影响消息顺序，因为每个请求/响应都有标识符，服务器按顺序处理。 - 问题：移动端网络环境复杂，WebSocket和HTTP/2的稳定性如何？
回答要点：WebSocket需处理心跳保持连接，移动网络下更稳定；HTTP/2依赖长连接，若网络波动可能导致连接断开。 - 问题：如何处理WebSocket的连接超时？
回答要点：可通过心跳包检测连接状态，超时后重连。 - 问题：HTTP/2是否支持WebSocket？
回答要点：HTTP/2本身不支持WebSocket，但可通过WebSocket over HTTP/2（WS over WSS）实现，但需额外处理。
7) 【常见坑/雷区】
- 混淆WebSocket和HTTP/2的本质：认为HTTP/2能完全替代WebSocket，或反之。
- 忽略连接建立成本：认为HTTP/2因多路复用而适合所有实时场景。
- 忽略移动端网络特性：未考虑移动网络下的连接稳定性，比如WebSocket的心跳机制。
- 未结合具体场景：比如用HTTP/2做即时聊天，导致延迟过高。
- 忽略兼容性问题：比如某些旧浏览器不支持HTTP/2，需考虑降级方案。