✅ 一、定义对比
| 协议 | 简要定义 |
|---|---|
| HTTP | 一种基于请求-响应模式的、无状态的应用层协议，通常用于客户端与服务器之间的数据通信。 |
| WebSocket | 一种全双工通信协议，可以在客户端和服务器之间建立持久连接，实现实时、低延迟的数据传输。 |
✅ 二、通信方式
| 特点 | HTTP | WebSocket |
|---|---|---|
| 连接模式 | 单向（客户端请求，服务器响应） | 双向（客户端和服务器可任意发送消息） |
| 通信过程 | 每次通信都需重新建立连接 | 一次连接，持续通信 |
| 建立方式 | 每次请求重新建立 TCP 连接 | 通过 HTTP 协议进行“握手”，然后升级为 WebSocket 协议 |
✅ 三、连接状态和效率
| 项目 | HTTP | WebSocket |
|---|---|---|
| 状态保持 | 无状态，连接短暂 | 有状态，连接持久 |
| 通信效率 | 高开销（每次需携带完整请求头） | 低开销（初次连接后只传输数据帧） |
| 实时性 | 较差（需要轮询或长轮询） | 极强（服务端可主动推送） |
✅ 四、数据格式和传输方式
| 项目 | HTTP | WebSocket |
|---|---|---|
| 数据格式 | 通常是文本（如 JSON、HTML） | 可发送文本或二进制（如 Blob、ArrayBuffer） |
| 传输层 | TCP | TCP（初始用 HTTP 进行握手） |
| 安全性 | HTTPS（加密 HTTP） | WSS（加密 WebSocket） |
✅ 五、典型应用场景
| 场景 | 更适合使用 |
|---|---|
| 网页加载、API 调用 | HTTP |
| 聊天室、在线游戏、股票行情推送、协同编辑 | WebSocket |
✅ 六、图解通信流程简述
HTTP 通信：
[Client] → 发起请求 → [Server]
[Client] ← 等待响应 ← [Server]
（请求-响应后，连接断开）
WebSocket 通信：
[Client] → HTTP 握手请求 Upgrade → [Server]
[Server] → HTTP 101 Switching Protocols ← [Client]
（建立 WebSocket 连接）
双向实时通信通道持续保持：
[Client] ⇄ [Server]
✅ 七、总结对比表（建议记住）
| 项目 | HTTP | WebSocket |
|---|---|---|
| 连接方式 | 请求-响应 | 全双工 |
| 是否持久连接 | 否 | 是 |
| 通信效率 | 相对较低 | 高 |
| 服务端能否主动发消息 | 否 | 可以 |
| 常用场景 | 页面加载、REST API | 实时聊天、推送、直播 |
| 协议升级 | 无 | 初次通过 HTTP，之后升级协议 |
✅ 面试高阶回答：
✅【标准口语化面试回答模板】：
“HTTP 和 WebSocket 是两种不同的网络通信协议，各自适合不同的场景。
HTTP 是典型的请求-响应模型，也就是客户端发请求、服务器返回响应，属于单向通信，连接是短暂的、无状态的。如果客户端想要获取新的数据，比如实现聊天或推送功能，通常需要使用轮询或长轮询，这会带来性能开销。
而 WebSocket 则是全双工通信协议，建立连接时会通过一次 HTTP 请求发起握手，握手成功后，协议升级为 WebSocket，之后客户端和服务器之间可以实时、持续地双向传输数据。这个连接是持久的，服务器也可以主动推送消息，适合像聊天系统、在线游戏、股票行情等需要实时更新的场景。
在性能方面，WebSocket 建立连接之后的数据传输开销更小，不需要每次都带完整请求头，也没有重复建连接的问题，因此实时性更好、效率更高。”
✅【加分项（可选补充）】：
“另外，WebSocket 使用 TCP 作为传输层协议，也支持加密传输（通过
wss://实现），整体在安全性和性能之间做了很好的平衡。虽然 HTTP/2 也解决了一些性能问题，但它仍然不具备真正的双向通信能力，WebSocket 在实时性场景下还是更优的选择。”
如果你面试的岗位偏后端或架构师，还可以加一句：
“在实际项目中，我通常会用 HTTP 实现数据初始化和配置加载，WebSocket 用来处理高频、实时数据流，两个协议配合使用效果更好。”
