网络通信中的 4 种交互模式
- 一问一答（请求-响应模式）
- [一问多答（订阅 / 推送模式）](#一问多答（订阅 / 推送模式）)
- [多问一答（批量 / 聚合模式）](#多问一答（批量 / 聚合模式）)
- 多问多答（双向实时通信模式）
- 四种模式对比总结
- 如何选择合适的模式？
一问一答（请求-响应模式）
这是最经典、最基础的交互模式。
Server Client Server Client 请求 响应
代表协议
- HTTP / HTTPS
- DNS 查询
- SQL 查询（非流式）
适用场景
- 网页浏览
- RESTful API
- 普通的增删改查操作
特点
- 简单、无状态
- 客户端必须主动发起
- 服务器不能主动推送
✅ 适合"我问你答一次就结束"的场景
一问多答（订阅 / 推送模式）
客户端只发一次请求，服务器持续返回多条数据。
Server Client Server Client loop 持续推送 订阅请求 数据 1 数据 2 数据 N
代表技术
- SSE（Server‑Sent Events）
- WebSocket（单向推送视角）
- RSS 订阅
- Kafka / MQTT 订阅
适用场景
- 股票行情
- 比赛实时比分
- 新闻 / 微博时间线推送
- 实时日志监控
特点
- 一次订阅，多次推送
- 服务器有"主动说话"能力（有限）
- 适合 观察者模式
多问一答（批量 / 聚合模式）
客户端发起多个请求，服务器聚合后返回一次响应。
Server Client Server Client 请求 A 请求 B 请求 C 统一聚合响应
代表技术
- HTTP/2 多路复用
- GraphQL
- 分片上传（最后一次性确认）
典型场景
1. 大文件分片上传
- 客户端将文件切成 1MB 的小块
- 并发上传多个分片
- 服务器全部收齐后返回"上传成功"
2. GraphQL
- 一次请求获取用户、订单、商品列表
- 减少网络往返次数
特点
- 减少网络往返（RTT）
- 更高效的批量处理
- 客户端与服务器之间有"多对一"的约定
多问多答（双向实时通信模式）
建立连接后，双方都可以随时主动发送消息。
Server Client Server Client loop 全双工通信 连接建立 控制指令 画面数据 状态通知 心跳 / 操作
代表技术
- WebSocket
- TCP / UDP 长连接
- MQTT
- SignalR / Socket.IO
典型场景
| 场景 | 说明 |
|---|---|
| 远程控制（ToDesk / TeamViewer） | 控制端输入指令，被控端持续回传屏幕画面 |
| 在线聊天（微信 / 钉钉） | 双方任意时刻都能发送消息 |
| 多人在线游戏 | 玩家动作广播 + 服务器推送状态 |
| 实时协同文档 | 多人同时编辑，互相看到光标和内容 |
特点
- 真正的 双向实时
- 需要维护长连接
- 复杂度远高于一问一答
四种模式对比总结
| 模式 | 请求次数 | 响应次数 | 方向 | 代表技术 | 典型场景 |
|---|---|---|---|---|---|
| 一问一答 | 1 | 1 | 单向请求 | HTTP | 普通 API |
| 一问多答 | 1 | N | 订阅推送 | SSE、WebSocket | 行情推送 |
| 多问一答 | N | 1 | 批量聚合 | GraphQL、分片上传 | 批量查询 |
| 多问多答 | N | N | 双向实时 | WebSocket、MQTT | 聊天、游戏 |
如何选择合适的模式？
1次响应
多次响应
不需要
需要
客户端与服务器交互
需要几次响应？
一问一答
HTTP / API
是否需要客户端
持续主动发送？
一问多答
SSE / 订阅推送
多问多答
WebSocket / 长连接
简单、无状态
订阅、观察者模式
双向实时、高复杂度