第2章数据源与接入

2、数据源与接入：主流交易所Tick数据接口对比

做量化交易，第一道坎就是数据接入。

我见过太多团队，策略写得漂漂亮亮，结果一上线，数据延迟高了几个毫秒，直接亏钱。说白了，Tick数据管道就像水管，接口就是水龙头。水龙头选不对，后面再好的管道也白搭。

今天咱们就聊聊，主流的Tick数据接口到底怎么选。

2.1 三大接口：CTP、FIX、WebSocket

目前市面上，交易所提供的Tick数据接口主要有三种：CTP、FIX和WebSocket。我个人的经验是，没有绝对的好坏，只有合不合适。

接口类型	典型场景	延迟	复杂度	我的评价
CTP	国内期货（上期所、大商所等）	<1ms	高	国内期货首选，但坑也多
FIX	海外期货、股票、外汇	1-5ms	中	国际标准，但协议臃肿
WebSocket	数字货币、部分股票	10-100ms	低	上手快，别指望高频

2.2 CTP接口：国内期货的硬门槛

CTP（综合交易平台）是上期技术开发的。国内做期货，基本绕不开它。

核心特点：

基于TCP的私有协议，不是标准的FIX
支持行情和交易两套通道
行情数据是逐笔Tick，包含买卖盘口

我记得第一次对接CTP时，被它的「前置机」概念搞晕了。你得先连上交易所的前置机，再通过它转发数据。这里有个坑——前置机地址经常变。

⚠️ 避坑指南： 我曾经因为CTP前置机IP变更，导致生产环境断了半小时数据。后来我养成了一个习惯：每次启动前，先做一次前置机连通性测试。

订阅流程大致如下：

// 伪代码示例
1. 初始化CTP行情API
   CThostFtdcMdApi* pMdApi = CThostFtdcMdApi::CreateFtdcMdApi();
   
2. 注册回调
   pMdApi->RegisterSpi(new CMdSpi());
   
3. 连接前置机
   pMdApi->RegisterFront("tcp://180.168.146.187:10010");
   pMdApi->Init();
   
4. 登录认证
   // 在OnFrontConnected回调中调用
   ReqUserLogin(req, ++nRequestID);
   
5. 订阅合约
   // 在OnRspUserLogin回调中调用
   char* instruments[] = {"rb2401", "cu2402"};
   pMdApi->SubscribeMarketData(instruments, 2);

嗯，这里要注意：CTP的登录认证需要经纪商提供的账号密码，不是交易所直接给的。而且每个账号有并发限制，我见过有人开了10个连接，直接被踢下线。

2.3 FIX协议：国际通用的「老大哥」

FIX（金融信息交换协议）是国际金融市场的通用语言。海外交易所、券商、对冲基金都在用。

说白了，FIX就是一套标准化的消息格式。每条消息都有固定的字段和结构。

FIX的优势：

跨平台、跨资产类别
支持会话恢复（Sequence Reset）
生态成熟，各种语言都有现成库

但FIX也有让人头疼的地方：

协议本身很重，一个简单的登录都要来回好几条消息
不同交易所对FIX的扩展不同，比如CME和ICE的字段就有差异

我个人的习惯是，如果做海外市场，优先用FIX。但别直接用原始FIX协议，太累。找个封装好的库，比如QuickFIX/C++，能省不少事。

💡 小技巧： FIX的登录认证通常需要「SenderCompID」和「TargetCompID」。这两个ID错了，连接直接断。我曾经因为大小写问题，排查了整整一个下午。

FIX订阅Tick数据的典型消息：

// FIX Market Data Request (MsgType=V)
8=FIX.4.2|9=123|35=V|34=2|49=SENDER|52=20240101-00:00:00|56=TARGET|
262=MDReqID001|263=1|264=1|265=1|146=1|55=ESZ3|267=2|269=0|269=1|10=123|

你看，就一个订阅请求，字段多得吓人。但别怕，核心就几个：55是合约代码，269是数据类型（0=买一，1=卖一）。

2.4 WebSocket：数字货币的「轻骑兵」

WebSocket在传统金融里用得少，但在数字货币交易所（币安、OKX、Coinbase）几乎是标配。

为什么？因为WebSocket是基于HTTP升级的，防火墙友好，前端也能直接连。你想想看，一个浏览器就能收Tick数据，多方便。

WebSocket的订阅流程：

// 以币安为例
1. 建立连接
   ws wss://stream.binance.com:9443/ws

2. 发送订阅消息（JSON格式）
   {
     "method": "SUBSCRIBE",
     "params": [
       "btcusdt@trade",   // 逐笔成交
       "btcusdt@depth20"  // 20档深度
     ],
     "id": 1
   }

3. 接收数据
   {
     "e": "trade",
     "E": 1704067200000,
     "s": "BTCUSDT",
     "p": "43210.00",
     "q": "0.001"
   }

WebSocket的认证方式也简单，通常就是API Key + Secret签名。我遇到过最坑的是——连接超时。有些交易所要求每5分钟发一次Ping，否则自动断开。

⚠️ 注意： WebSocket的延迟受网络影响很大。我在国内连币安的新加坡节点，延迟大概30ms。如果你做高频，这个延迟是致命的。

2.5 数据订阅与认证流程对比

三种接口的认证流程，我整理了一张表，方便你对比：

步骤	CTP	FIX	WebSocket
建立连接	TCP直连前置机	TCP直连，需Logon消息	HTTP Upgrade到WebSocket
认证方式	经纪商账号+密码	SenderCompID+TargetCompID	API Key + Secret签名
心跳机制	内置，可配置	Heartbeat消息（MsgType=0）	Ping/Pong帧
订阅方式	SubscribeMarketData	MarketDataRequest	JSON订阅消息
数据格式	CTP私有结构体	FIX标签=值	JSON

2.6 核心逻辑：一张图看懂

下面这张SVG图，是我自己画的。它展示了三种接口从连接到数据流转的核心逻辑。你看一眼，基本就明白整个流程了。

你看，不管接口怎么变，核心流程都是：连接 → 认证 → 订阅 → 收数据。区别在于每一步的实现细节。

2.7 我的选择建议

说了这么多，到底选哪个？我个人的经验是：

做国内期货高频：别想了，CTP是唯一选择。虽然坑多，但延迟最低。
做海外市场：FIX是主流。如果交易所支持FIX，优先用FIX。
做数字货币或回测：WebSocket够用了。简单、快速、成本低。

    📌 核心要点： 接口只是手段，数据质量才是根本。我见过有人用WebSocket做高频，结果因为网络抖动，数据缺了一大片。选接口之前，先想清楚你的延迟要求。

好了，这一章就到这里。数据接入搞定了，下一章咱们聊聊数据怎么存、怎么管。

📚 课程目录

2、数据源与接入：主流交易所Tick数据接口对比

2.1 三大接口：CTP、FIX、WebSocket

2.2 CTP接口：国内期货的硬门槛

2.3 FIX协议：国际通用的「老大哥」

2.4 WebSocket：数字货币的「轻骑兵」

2.5 数据订阅与认证流程对比

2.6 核心逻辑：一张图看懂

2.7 我的选择建议