两种取数方式
这两种方式的工程含义完全不同。实时推送要求程序跟得上数据的速度，跟不上就会在内存里堆积；请求与响应要求程序能把结果落盘缓存，否则每次开图都要重新向数据商取一遍，很快就会撞上请求限额。一个成熟的客户端两套都要做好，并且要能在断线后用历史补上推送期间丢掉的那一段。
- 实时推送：客户端订阅一次，之后每一笔成交或每一次订单簿变化都会沿着一条长连接送过来，常见的承载是 WebSocket 或一条 TCP 会话。
- 请求与响应：客户端指定一个区间，比如一天的逐笔或者一个月的一分钟 K 线，数据商在一个或几个回包里把它返回。
接口之间差在哪里
| 属性 | 例子 | 为什么重要 |
|---|---|---|
| 传输方式 | WebSocket、TCP、UDP 组播、HTTP | 延迟、防火墙行为、断线恢复 |
| 编码 | Protocol Buffers、SBE、JSON、FIX 标签值 | 解码开销、字段变更带来的兼容风险 |
| 内容 | 带主动方的成交、几档深度、逐笔委托级数据 | 决定足迹图或热力图能画出什么 |
| 历史 | 逐笔、K 线、深度；能回溯多久 | 决定回放和回测的覆盖范围 |
| 权限 | 按交易所、按数据模式、按登录账号 | 决定你的密钥或登录实际能收到什么 |
算例：估算一次历史请求的体量
芝商所一只股指合约的交易日大约 23 小时，一分钟 K 线就是 23 × 60 = 1,380 根。一年按 250 个交易日算，大约是 1,380 × 250 = 345,000 根。同样这一年如果换成逐笔成交，数量要大上两三个数量级。这就是数据商要限制单次请求大小的原因，也是客户端必须在本地缓存历史的原因。
深度数据更夸张。一档买卖价的更新频率已经远高于成交，十档的全量快照更新则是它的若干倍。所以几乎没有哪家数据商把历史深度和历史成交打包在同一个产品里卖——成本结构完全不同。
在 Senzoukria 里
软件接了好几个接口，每个都有自己的权限：Rithmic 走 R | Protocol，用用户自己的登录信息打开一条 WebSocket 会话；Databento 用一把 API 密钥，它的实时许可是按数据集逐个实测出来的，模块要先确认许可才会开放；币安和 Bybit 的公开数据流不需要密钥；本地还可以通过 7272 和 7273 两个端口从 NinjaTrader 和 Quantower 桥接。
连接帮助页里专门写了一句最容易让人掉坑的区分：平台访问权和接口访问权是两项独立的权限。这句话的实际含义是，账户在数据商自家终端里能看到行情，并不代表同一个账户能通过接口把这些行情送到第三方软件里。
常见错误
- 以为在数据商自家平台里能用的登录信息，通过接口也一样能用。
- 以为实时权限自带历史，或者历史权限自带深度。
- 先选软件、后查接口。顺序反了：接口能给什么，是选软件之前就该知道的事。
- 把接口的请求限额当成建议而不是硬限制，结果在开发阶段就被封掉几分钟。
相关内容
同一栏目
其他语言版本
常见问题
- 为什么我的登录信息在券商平台里能用，在第三方软件里不行？
- 因为数据商自家平台和它的接口是两项独立的权限。账户可能只开通了其中一项，而这件事只有券商或数据商本人能确认。软件这边看到的只是一个被拒绝的登录，看不出是账号错了还是权限没开。
- 行情数据接口包含历史深度吗？
- 默认几乎都不包含。历史成交和历史深度通常是两个分开卖的产品，而且没有被记录下来的深度无法从成交数据反推出来——成交里没有那些没有成交的挂单。