想象一下你在热门餐厅排队等位：一种方式是你每隔 30 秒就跑到前台问服务员一次：“现在轮到几号了？有空桌了吗？”另一种方式是你坐在休息区听广播叫号，或者手机 App 在有空位时第一时间自动给你推送通知。
前一种方式就是计算机网络里的 REST API（请求-响应轮询模式），后一种方式就是 WebSocket（全双工长连接主动推送模式）。
许多刚接触量化交易的新手，习惯用死循环写代码每隔几十毫秒去疯狂请求 REST 接口查最新价格，结果经常触发券商或交易所的频率限制（Rate Limit）导致 IP 被封，或者在剧烈波动时漏掉关键跳水行情。搞懂这两种网络协议的分工，是搭建高可靠交易系统的必备常识。
REST API 基于请求-响应机制：每个逻辑交互为单次请求与响应，而底层 HTTP 连接通常可通过 Keep-Alive 保持复用。它极其适合批量下载历史 K 线用于策略回测、查询账户快照以及提交低频交易指令。WebSocket 则通过握手建立一条持久化的双向 TCP 长连接通道，服务端在市场发生事件时主动推送到客户端。WebSocket 是流式行情数据的常见选择，但业内同样存在其他实时传输协议。
| 架构特性 | REST API (请求-响应轮询) | WebSocket (持续长连接流) |
|---|---|---|
| 连接生命周期 | 单次交互请求-响应（底层 HTTP 连接可复用 Keep-Alive） | 持久双向长连接：初次握手后长期保持开启 |
| 数据流向模式 | 客户端单向拉取（Pull 模型，按需发起） | 服务端事件驱动主动推送（Push 模型，有变化即推送） |
| 网络延迟表现 | 采样延迟受轮询间隔与往返传输影响 | 事件驱动推送（撮合成交或变动后即刻发出） |
| 接口频控压力 | 高频重复轮询极易触发 429 错误并导致 API 权限被限制 | 复用单个长连接通道，避免了高频重复请求带来的频控压力 |
| 最适用实盘环节 | 下载大段历史数据、开盘前账户资金对账、低频定时换仓 | 实时价格变动监控、盘口挂单深度刷新、快速止损指令触发 |
新手常见误区：高频 REST 轮询的“频控灾难”
许多新手常在脚本里写一个 `while True: get_price(); sleep(0.1)` 的无限循环来试图抓取实时价格。
这种做法在实盘中会立刻引发两大问题：频控超限与采样滞后盲区。
即便在底层复用 HTTP 连接的情况下，过于密集的高频轮询依然会带来巨大的无效请求开销，极易触发交易所的 429（Too Many Requests）频控限制甚至 IP 封禁。更糟糕的是，如果行情在两次轮询的空档内发生剧烈波动，程序在下一次请求返回前完全处于信息真空期，无法做到即时反应。
REST 请求如果失败，会立即返回明确的 HTTP 错误码；但 WebSocket 长连接在遇到底层网络静默断开时，系统可能感知不到（TCP 半开连接状态），程序以为还在正常监听，实际上数据流早就中断了。专业系统必须在客户端内置心跳检测（Ping-Pong Heartbeat），并遵循数据服务商特定的心跳与重连规则，及时发现假死连接并恢复通道。
专业量化团队的标配方案：混合型数据流水线
成熟的自动化交易系统从不二选一，而是将两者组合为高内聚、低耦合的协作链路：
- 11. 启动期用 REST 初始化全量状态： 系统初始化时，通过一次规范的 REST API 请求拉取当前可用现金、持仓明细、未成交挂单列表以及过去 500 根历史 K 线。
- 22. 运行期用 WebSocket 订阅增量事件： 初始化完成后，立刻建立 WebSocket 连接，持续监听最新逐笔成交、订单簿五档盘口变化以及自己的订单成交回报推送。
- 33. 定期低频 REST 状态对账（Reconciliation）： 每隔 10 到 15 分钟发起一次低频 REST 查询，比对本地内存记录与交易所服务器真实账本，防范长连接偶发丢包累积的记账误差。
常见问题
可以通过 WebSocket 直接下单交易吗？
部分新兴交易平台（如加密货币与部分现代外汇平台）支持通过 WebSocket 直接发送买卖下单与撤单指令以追求极致执行速度；但多数传统证券券商仍强制要求通过更严格的鉴权 REST 接口或专用的 FIX 协议提交订单。
免费的行情接口为什么总是比付费数据慢十几分钟？
这是全球交易所统一的商业授权合规要求。免费的公开 REST 行情通常会被强制延迟 15 分钟提供；要获取毫无延迟的即时数据，必须获得交易所的实时商业授权或通过持牌券商的私有账户接口订阅。
WebSocket 断线重连期间，错过的价格数据该怎么补齐？
重连成功后，交易系统应第一时间通过 REST 接口拉取断线期间的最新行情快照，填补本地数据空洞，完成对账后再重新恢复全自动委托逻辑。
