高频交易系统核心构建技术的探索与实践（一）

发表于 分类于 ， 阅读次数： 本文字数： 10k 阅读时长 ≈ 37 分钟

TL;DR

本系列文章的第一篇由 UDP 组播的业务需求场景引出。文章将介绍 UDP 组播相关的网络协议和核心技术，以及由此引出的高频交易系统中一些常见的高性能网络协议。在这些外部网络中的协议里，我们将着重探讨和剖析其中的 FAST 协议，最后再深入学习如何通过 FPGA 针对内部网络进行性能优化。当然，我们不可避免地也会简单介绍高频交易系统的背景和核心架构。

针对高频交易系统构建过程中涉及到的核心技术，本系列文章将进行深度的原理剖析，并在应用层面上做一定程度的探索实践。本系列文章在内容设计和结构组织上主要遵循以下几个方面的原则：

  • 视角：以客户端（交易系统）视角为主，服务端（交易所）视角为辅
  • 结构：本系列文章主要采用自底向上结构，通常由核心业务问题推衍出所涉及的底层核心技术，进而对相关核心技术进行深入剖析，并非传统意义上的体系化由浅入深的介绍。后者通常会涉及较多的内容，从高频交易的历史背景和业务知识，到系统架构的理论知识、核心软硬件组件、各级链路的性能优化等，以及最后的应用构建实操。
  • 主题：第一篇将深入研究高频交易系统中涉及的网络协议，系列后续文章计划侧重以下几个方面：覆盖各类核心组件的架构设计及相关业务场景的串联；核心链路的性能优化和偏上层的应用开发实践；基于 FPGA 的内部网络性能优化等。

1. 背景

1.1. 高频交易

高频交易（HFT，High-Frequency Trading）是一门多领域知识交叉融合的技术，涉及计算机系统架构、操作系统原理、网络、开发编程、金融工程等等。通常，构建一个高频交易系统需要了解交易所（Exchange）系统的工作机制、高频交易系统的构建原理、高频交易策略、计算机系统底层相关知识，以及最终实际在应用层面如何进行系统开发和优化。回顾整个高频交易历史，速度（Speed）始终是最为重要的关注点，而自动化（Automation）、吞吐量（Throughput）、性能（Performance）、延迟（Latency）等也是常被提及的关键词。

2000 年之后，随着中央限价订货簿（CLOB，Central Limit Order Book）的出现以及交易市场更加的透明化和正规化，大量的交易公司、对冲基金、电子化交易玩家纷纷涌入，但即便到了 2010 年，依然也只有 2% 的头部玩家（如：Virtu、Jump、Citadel、IMC、Tower 等）具有极强的市场竞争力，他们贡献着全市场 75% 的交易量。高频交易需要投入大量甚至是巨量的人力、物力和时间，头部玩家们不仅具有这样的投入实力，更重要的是他们掌握着隐匿的、边缘的、不为人知的对市场结构的认知和对科学技术的应用。相比之下，大量的其他高频交易公司只能称之为全市场交易量的 “搬运工”。2009 年高频交易在美国证券交易市场达到顶峰，占据了 50% 的市场交易量。2015 年，随着数字资产和加密货币交易所的出现，高频交易策略再一次呈现爆发式增长。

高频交易策略（算法交易策略的一个子集）不是本文讨论的重点，它通常涉及资产类别（Asset Classes）、流动性（Liquidity）、撮合引擎（Matching Engine）、市场做市商（Market Maker）、市场接受者（Market Taker）、套利（Arbitrage）等等概念。

需要特别说明的是，有别于常规的中低频交易，高频交易要求极致的低延迟和极致的自动化，这些技术在交易方侧可行且可实现，但同时交易所侧也需要有对应的技术来支撑高频交易。世界级的交易所，如：纳斯达克股票市场（NASDAQ）、纽约证券交易所（NYSE，New York Stock Exchange）、伦敦证券交易所（LSE，London Stock Exchange）、东京证券交易所（TSE，Tokyo Stock Exchange）、芝加哥商品交易所（CME、Chicago Mercantile Market）等在高频交易技术上都有着数亿美元的投入。

1.2. 高频交易系统

图 1 是高频量化交易系统（客户端）的全景架构图。

图 1. 高频量化交易系统全景架构图

其中：

  • 交易场所（Venue）：代指任何具有订单撮合功能的平台，如：交易所、多源聚合（Aggragator）、银行、电子通信网络（ECN，Electronic Communication Network）等。交易所的架构原理不在本文赘述，其最为核心的功能组件是订单簿管理和撮合引擎。
  • 网关（Gateway）：负责连接交易系统和交易场所，用于订阅资产后的数据通信（价格更新、订单等）。

网关和交易场所的通信，需要考量以下两个方面：

  • 通信协议：不同的交易场所采用的通信协议往往也不同，这也是本文后续讨论的重点
  • 物理位置：交易系统或网关如果能集中托管（Colocation）在交易场所，则可以最小化通信延迟；如果采用云端部署，则需要通过互联网或者专线方式进行通信，延迟会显著增加
  • 订单簿构建（Book Builder）：负责收集不同交易场所的订单簿信息，并根据实际交易策略需求进行维护和管理。高频交易中每秒会产生大量订单，如果每次都接受交易所推送的全量订单簿，则网络性能损耗严重，所以通常在高频交易场景中，交易系统会设计成只接受一次完整订单簿快照，之后获取的都是增量更新，并由交易系统负责本地维护和管理。影响性能的关键因素是订单簿的数据结构设计，目标是达到 $O (1)$ 或者 $O (\log n)$ 的插入、查询、更新和删除复杂度，相关技术不在本文展开叙述。
  • 策略引擎（Strategy Engine）：负责产生策略交易信号和策略交易执行。
  • 订单管理系统（OMS，Order Management System）：负责收集策略产生的订单，并维护订单的整个生命周期（创建、执行、修改、取消和拒绝）。在高频交易系统中，OMS 另一个很重要的作用是提早发现无效的订单（超限额、方向错误、价格错误、订单类型不准确等），避免流入交易所后再产生额外的通信损耗。

以上是高频交易系统中最为关键的核心组件，每个组件的性能（速度）都直接影响着整个系统的性能。不夸张地说，在高频交易中微秒级的性能损耗都会造成巨大的损失。通常，我们用 Tick-to-Trade 或者 Tick-to-Order 的时间来衡量一个交易系统的性能，它表示从收到价格更新进入交易系统那一刻开始，到产生订单离开交易系统为止的这段时间。

架构全景图中其他的一些非关键组件说明如下：

  • 控制管理系统：连接用户（交易员）和交易系统，可以是命令行或者用户界面操作，如：策略参数调整等。
  • 各类服务（Service）：本地维护的持仓服务、日志系统、各类面板查看系统、资讯服务等

性能，或者说高频交易各个链路上所能达到的性能上限是可以量化的，表 1 给出的性能阶梯指标便是核心环节预计优化后所能达到的参考基准。尽管这其中很多内容无法在一篇或几篇文章中面面俱到完全讲清楚（也许会在后续的文章中会详细展开），但从全局视角来看，还是有一定参考意义的。

微秒（ $\mu s$，microsecond）： $1\mu s = 10^{-6} s$；纳秒（ $ns$，nanosecond）： $1ns = 10^{-9} s$

表 1. 高频交易系统性能优化阶梯指标

1.3. TCP / IP 协议

所有高频交易系统都需要网络的支撑，要用操作系统能读懂的 “语言” 去描述网络协议栈（Protocol Stack）就不得不提图 2 中经典的 OSI（Open Systems Interconnection，开放式系统互联）七层参考模型，以及简化后的三层或四层模型。

图 2. 网络模型和协议簇

在四层模型里，应用层可以理解为软件层面的实现，相较而言，更大的优化空间则在下面三层：

  • 传输层（Transport Layer）：为两台主机上的应用程序提供端到端的通信。它主要包含 TCP 协议（Transmission Control Protocol，传输控制协议）和 UDP 协议（User Datagram Protocol，用户数据报协议）。前者提供可靠的面向连接的传输服务，后者则提供简单高效的无连接传输服务。

    所谓 “端到端” 传输（E2E，end-to-end），是相对 “连接” 而言的。在七层模型里，底下三层属于 “连接” 方式，以网络层为例，IP 协议需要做逻辑寻址才能和相邻机器进行通信，两台主机之间的通信不能跳过中间任何相邻的机器。反观上面四层，它们不需要关心底层实现细节，但凡建立连接后，两个应用程序或者进程就可以直接通信。

UDP 不具备 TCP 的会话、有序传输、可靠传输等特性，所以一般适用于对延迟要求比较高的场景中。通常我们认为 UDP 的传输速度要比 TCP 快 3 倍。为解决可靠性这个问题，人们提出了一种应用层上的轻量级点对点协议：UFO（UDP for Orders）。即使在出现网络故障的情况下，它也可以确保消息的有序投递。该协议也逐渐成为一种使用趋势。具体文档可参考：UFO (UDP for Orders)。

  • 网络层（Network Layer）：使用 IP 协议（Internet Protocol，网际互连协议）实现数据报文的逻辑寻址，在金融领域仍以 IPv4 协议为主。

    网络层的寻址机制是 IP 地址，IP 寻址实现了对底层网络地址的统一。物理链路层的寻址机制则是 MAC 地址（Media Access Control，介质访问控制），也称为硬件地址。IP 地址和 MAC 地址之间的转换由地址解析协议（ARP，Address Resolution Protocol）和反向地址解析协议（RARP，Reverse Address Resolution Protocol）实现。

  • 物理层（Physical Layer）：涉及各类物理硬件设备，诸如：光纤、铜缆、卫星、路由器、交换机等。

尽管物理层对网络延迟有着巨大影响，但并不在本文的讨论范围内，本文将着重讨论传输层和网络层，也就是三层模型中的 TCP / IP 层。

回到本文最开始的业务场景需求，UDP 组播指的就是在网络层使用 IP 协议（通常是 IPv4）进行寻址，寻址模式使用的是组播模式（Multicast Mode），而在上层的传输层则使用 UDP 作为通信协议。所谓寻址模式，是人们根据寻址目标人为地将 IP 地址划分了以下三类：

  • 单播（Unicast）地址：一对一通信；可以是 A 类、B 类、C 类地址；可以使用 TCP 或 UDP 协议。
  • 广播（Broadcast）地址：向所有主机发送数据，通常使用子网的广播地址，且只能使用 UDP 协议。
  • 多播 / 组播（Multicast）地址：向加入多播组内的一组主机发送数据，地址是 D 类地址中的 224.0.0.0～239.255.255.255，只能使用 UDP 协议。

需要注意的是，图 2 中网络层的 IGMP 协议（Internet Group Management Protocol，Internet 组管理协议）便是用来实现组播中的组成员管理的。

2. 高频交易中的金融协议设计

如图 1 中所示，高频交易系统的网关组件和交易场所之间的通信必须依赖于特定的通信协议，因此本节我们将站在金融协议（Financial Protocol）的制定者 —— 交易所的视角下，来看一下高频交易中的金融协议是如何设计的。这份电子化交易协议清单列出了主流的交易所使用的金融协议。正如文档中提到的，FIX 协议依然是传统主流的选择，但越来越多面向低延迟设计的协议也逐渐在被推广和使用。

2.1. FIX 协议

一直以来，电子化交易中最重要的通信协议是 FIX 协议（Financial Information eXchange，金融信息交换协议）。该协议始于 1992 年，当时只是富达投资公司（Fidelity Investments）和所罗门兄弟公司（Salomon Brothers）之间的一个通信框架，后来逐渐发展成为世界大部分银行和资产管理公司间进行实时电子通信的一种选择，之后被扩展到外汇（FX，Foreign Exchange）、固定收益（FI，Fixed Income）、衍生品（Derivatives）和清算（Clearing）等市场上。FIX 协议是一个基于字符串的协议，是一个具有多版本的平台无关的开放协议。目前广泛使用的 FIX 协议版本是 4.2、4.4、5.0 版本。

FIX 引擎（FIX Engine）指的是实现了 FIX 协议的软件，因此并非所有的 FIX 引擎都一样，高频交易者们通常更倾向于构建自己个性化的 FIX 引擎以实现最佳的通信速度。

FIX 协议的消息内容是键值对（Key-Value Pair）组成的列表，键值对也称为域（Field），每个域中的键都是预定义的标签，每个标签都对应一个值（数值或者文本字符串）。消息域由 ASCII 码表中的 0x01 字符所分隔，它们组合起来构整个消息的消息头、消息体和消息尾。其中：

  • 一直到 FIX.4.4 版本，消息头都由域 8（BeginString，开始字符串）、域 9（BodyLength，消息体长度）、域 35（MsgType，消息类型）构成。FIX.5.0 之后，消息头新增了两个必填域：域 49（SenderCompID，发起者 ID 标识），域 56（TargetCompID，目标接收者 ID 标识) 。
  • 消息尾由域 10 标识，它存储的值是整个消息的校验和（Checksum），通常由 3 位十进制数表示。
  • 域 35 和域 10 之间的所有域，构成整个消息体。

片段 1 是一个 FIX 协议的消息示例（域 49 和 域 56 说明了这是一条 FIX.5.0 的消息）：

片段 1. 一条 FIX.5.0 消息
1
8=FIX.4.2|9=178|35=8|49=PHLX|56=PERS|52=20071123-05:30:00.000|11=ATOMNOCCC9990900|20=3|150=E|39=E|55=MSFT|167=CS|54=1|38=15|40=2|44=15|58=PHLXEQUITYTESTING|59=0|47=C|32=0|31=0|151=15|14=0|6=0|10=128|

需要特别注意的是，域之间的分隔符是一个不可打印字符，所以通常人们使用字符 “|” 或 “<SOH>” 显式地表示这个分隔符。另外，很多文档资料中都称这个分隔符为字符 1，这个很容易造成误解。它真正代表的是 ASCII 码表中十六进制为 0x01、八进制为 0o01、十进制为 1 的那个 ASCII 字符，即 SOH（Start of Heading）字符。通常所说的阿拉伯数字 1 的 ASCII 码值是 49 或 0x31。图 3 是一条正常的 FIX 消息在文本编辑器中打开后的效果。

图 3. 一条常规 FIX 消息

了解协议规范后，就可以实现对消息的封装和解析。通常我们可以借助一些已有的工具，也就是上面提到的 FIX 引擎。商用的 FIX 库有：NYFIX、Aegisfot-Aethna、Reuters -Traid 和 Financial Fusion - Trade Force。非商用的一般使用开源的 quickfix 库，它本身是 C++ 语言写的，同时也向上提供了面向 Python、Java、Go 等语言的封装。片段 2 是一个 Python 实现的解析和封装消息的典型示例。

片段 2. FIX 消息的解析和封装
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
def fromApp(self, message: fix.Message, sessionID):
    beginString = fix.BeginString()
    msgType = fix.MsgType()
    message.getHeader().getField( beginString )
    message.getHeader().getField( msgType )

    symbol = fix.Symbol()
    side = fix.Side()
    ordType = fix.OrdType()
    orderQty = fix.OrderQty()
    price = fix.Price()
    clOrdID = fix.ClOrdID()

    message.getField( ordType )
    message.getField( symbol )
    message.getField( side )
    message.getField( orderQty )
    message.getField( price )
    message.getField( clOrdID )

    executionReport = fix.Message()
    executionReport.getHeader().setField( beginString )
    executionReport.getHeader().setField( fix.MsgType(fix.MsgType_ExecutionReport) )
    executionReport.setField( fix.OrderID(self.genOrderID()) )
    executionReport.setField( fix.ExecID(self.genExecID()) )
    executionReport.setField( fix.OrdStatus(fix.OrdStatus_FILLED) )
    executionReport.setField( symbol )
    executionReport.setField( side )
    executionReport.setField( clOrdID )
    executionReport.setField( orderQty )
    # ……

最后便是将 FIX 协议的消息应用到实际的交易业务场景，如订阅价格更新、发送订单等，这里将不再赘述。

2.2. FAST 协议

本文的第二个重点便是 FAST 协议（FIX Adapted for STreaming，适流 FIX 协议），可以将其理解为 FIX 协议的高速版，但它本身是一个相对独立的规范，不需要去实现 FIX 协议。FAST 协议是 FIX 协议社区（FIX Trading Community）在 2005 年发布的一种适合基于 UDP 连接发送组播数据的二进制协议，这也是为什么本文的主线由 UDP 组播和 FAST 协议贯穿而成，其背后真正的原因是 FAST 协议的使用者 —— 上海证券交易所（SSE，Shanghai Stock Exchange）、深圳证券交易所（SZSE，Shenzhen Stock Exchange），它们的 Level-2 行情使用的都是 FAST 协议。相较 FIX 协议而言，FAST 协议更为复杂，且相关文档资料较少，本文将花较大篇幅试图讲清其设计原理。

与 Level-2 行情（收费）相对应的是 Level-1 行情（免费），后者通常仅提供 5 个买卖档，刷新频率较低，且是聚合后的快照信息，因此隐藏了很多细节，而 Level-2 行情则是以分笔成交为单位，细节信息更多，接受速度和刷新速度也更快。

FIX 协议的一些发展现状：

  • FIX 在 5.0 版本之后实现了传输层无关的会话层协议，即：FIXT.1.1（FIX Transport）。
  • 除了 FAST 协议，社区还在 2020 年发布了新的基于 SBE（Simple Binary Encoding，简单二进制编码）的二进制协议来加速 FAST 协议的编码。
  • FIX 还发布了可直接用于算法交易的 FIX 算法交易定义语言（FIXatdl，FIX Algorithmic Trading Definition Language），可类比于数据库领域的数据定义语言（DDL，Data Definition Language）。

2.2.1. 设计思想

在深入 FAST 协议细节之前，可以试着站在协议设计者的角度，设想一下如何才能优化压缩传输的数据来提升通信性能。FAST 协议的设计者给出的答案是：

  • 使用 $\Delta$（delta）更新机制：以价格为例，只有在价格变动时才会在消息体中体现，而对于没有变动的值可以不出现在消息体中
  • 可变长度的编码机制：换言之，同一类型格式的数据，长度都是不固定的

注意这个问题本身 —— 以压缩数据为前提。显然，提升通信性能的代价是相应的编码解码处理的复杂度也提升了，尤其是对长度不固定的数据进行编码和解码，反而会带来性能损耗。幸运的是，FIX 协议社区实测证明：将 FAST 协议带来的传输延迟的提升，去除额外带来的处理延迟之后，仍显著优于未经压缩的数据流协议和使用其他压缩方式的通信协议。

为了实现上述两个机制，FAST 协议设计了以下几个核心要素：

  1. 模板（Template）
  2. 存在图（PMap，Presence Map）
  3. 停止位（Stop Bit）
  4. 长度可变的域

FAST 协议的核心设计原理是：每一类消息（如：行情数据更新）对应一个模板，模板通常是一个双方（服务端和客户端）共同遵循的 XML 文件，里面定义了消息中所有域的信息。由于双方都拥有这个模板，因此之后的通信内容都可以省略这些域的标签值，换言之，消息里全部都是值的信息。那值与值如何分隔，如何解析？如果按照定长格式设计，每一个域的长度根据其类型都是固定的，可以解析但显然会造成大量的空间浪费。FAST 协议利用存在图和停止位来实现解析可变长度的域。消息的头部有一个存在图，它标识了模板中每个域的值是否会出现在消息体中。在解析二进制流的过程中，如果一个字节的最高位（停止位）是 1，则代表一个域的值的结束，为 0 则表示这个字段值还未结束。

图 4 是一条 FAST 协议消息的完整结构。消息的最开始是代表整个消息的 PMap，之后跟随的便是和模板文件相对应的各个域，<sequence> 是一类特殊的域，它是一个序列，其中的每一项（Entry）都包含有各自的 PMap 和一组域的集合（Fields Group）。换言之，FAST 协议消息的编码和解码过程中，我们需要重点关注 PMap，它是解析后面数据域的关键。

图 4. FAST 协议消息结构体

2.2.2. 核心算法

举一个 FAST 协议中的 HelloWorld 例子来说：

片段 3. 一个简易的 FAST 协议模板文件
1
2
3
4
5
6
7
<templates xmlns="http://www.fixprotocol.org/ns/fast/td/1.1">
    <template dictionary="1" id="1" name="HelloWorld">
         <string id="58" name="Text">
             <default value=""></default>
         </string>
    </template>
</templates>

事实上，一个模板文件中可以有多个 <template> 标签，而作为演示，上述模板文件仅包含一个 id=1、名为 HelloWorld 的 <template>（它也是一个域，也需要编码和解码），这个 <template> 也只有一个 id=58、类型为 string、名为 Text 的域。

在 FAST 协议规范里，<string id="58" name="Text">...</string> 这种被称为域指令（Field Instruction），因为它指定了域的类型、名称，且里面包含域操作符（Field Operator），用于指示这个域的优化方式。

如果用 FAST 协议协议发送一条内容是 “HelloWorld” 的消息，则经过 FAST 协议编码后，实际在网络上传输的数据如表 2 所示（实际传输不包含中间的空格）：

表 2. FAST 协议编码后的“HelloWorld“消息

第一个字节 0xE0（11100000），最高位为 1，因此这个字段的值结束了，同时它也代表着这条消息的 PMap。移除高位的 1 变成 1100000 之后，就要从 PMap 的高位开始对应结合模板的每个域一起来看了。

FAST 协议解码（Decoding）的逻辑是：根据模板遍历每一个域，通过以下两个域指令中的值共同确定该域是否在 PMap 中占用一个比特位（占位），两者组合判定的结果参见表 3。

  • 域操作符：如 <default>、<copy>、<delta> 等
  • presense 的值：有 optional（可选的）和 mandatory（强制的），未指定时默认是后者值
表 3. 消息域 PMap 占位参照表

注意，有些值我们不需要检查 PMap（表 3 中 “不占位” 的场景），其含义是域对应的值不论是否为 NULL，都会出现在消息体中，因此不需要 PMap 占位符来表示。而对于需要占位的域操作符，我们需要按位（从高到低）检查 PMap 的每个比特位，若为 1，则表示消息体中有该域的数据，若为 0，则没有该域数据。整体逻辑反过来便是协议编码（Encoding）的逻辑。

回到上面的例子，我们按照模板的域依次解析：

  • 第一个 Helloworld 域： 因为 PMap 1100000 第一位是 1，所以代表这个域的值出现在了消息体里，那显然就是消息体中后面的 0x81（10000001），而且由于 10000001 的停止位是 1，所以这个值也只能是 10000001，移除高位后得到 00000001，按十进制解析后便得到 <template> 的 id=1。需要注意的是，模板的 <template> 标签总是需要解析的，且也一定会在 PMap 中占位为 1，用于表示模板 ID。
  • 第二个 Text 域：它有 <default> 操作符，没有 presence 值则使用缺省值 mandatory，由上表可知它在 PMap 占位，因此查看 PMap 1100000 的第二位，为 1 说明有值，也就是说消息体中接下来的值便是这个域的值。检查每个字节的最高位，从 0x48 开始，直到 0xE4（11100100）最高位的停止位才为 1，代表这个域的值结束。因此第二个域的值由 0x48 0x65 0x6C 0x6C 0x6F 0x57 0x6F 0x72 0x6C 0xE4 共同表示。由于该域的类型为 <string>，因此直接将其按照 ASCII 码值解码即可得到对应的十个字符：“HelloWorld”。

至此，整个消息体便解析完成，PMap 第三位开始全都是 0，也说明了后面确实没有其他数据。图 5 给出了 FAST 协议的核心解码算法流程（逆过程便是编码算法，此处不再赘述）。图中并未包含更复杂的细节处理，比如对于不同的操作符和不同的数据类型格式的处理方式，但总体来说，上述这个例子已经足够我们理解 FAST 协议的核心算法和设计原理了。

图 5. FAST 协议消息解码算法

2.2.3. 场景案例

设想一个复杂的真实场景：如果要推送市场行情数据全量更新的快照信息（Market Data Snapshot），站在 FAST 协议设计者的角度会如何设计协议规范，以及站在交易所的角度会如何设计这条消息的模板和整个消息体。显然：

  • 协议需要支持多种域的类型，在 FAST 协议中定义的域类型有：Integer（整型数）、Decimal（浮点数）、String（字符串）、Byte Vector（字节向量）、Sequence（序列）、Group（组）。Sequence 类型适合组装一组整体结构可重复的数据，如一组深度行情。
  • 协议需要提供一种机制，使得模板里的字段可以指定优化方式，在 FAST 协议里便是域操作符机制，例如：缺省的时候可以使用默认值（<default>）、沿用上一个值（<copy>）、在上一个值的基础上自增（<increment>）、基于上一个值所产生的变化量（<delta>）等，以此来大幅减少实际需要传输的数据量。图 6 概括性地给出了七种操作符（子图a至子图f）对应的核心处理机制，其中：灰色部分表示输出值或沿用输入值、或使用默认值、或从字典中取数；蓝色部分表示输出值为空；黄色部分表示输出值的结果需要更新字典。受限于篇幅，操作符相关的更多细节算法将不在本文详细展开。
    图 6. FAST 域操作符解码机制

现在便可以来看现实世界中的实际场景了 —— 上海证券交易所个股期权的数据流。图 7 是这条基于 FAST 协议的完整数据流的十六进制表示形式。

图 7. 上海证券交易所个股期权 FAST 协议消息数据

解析步骤如下所示：

  1. 第一个字节（F6）通常代表 PMap（也有特殊情况，但不影响我们理解 FAST 协议），去除停止位后就得到实际的 PMap 为：1110110。
  2. 模板 ID 必须在 PMap 占位，所以 1F A1 代表模板域，解码得到模板 ID 为 4001，并获取得到该模板文件（见表 4 和片段 4）。
    表 4. FAST 协议消息中 PMap 和模板 ID 的解码
片段 4. 模板 ID 为 4001 的模板文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
<templates
    xmlns="http://www.FIXprotocal.org/ns/FAST/td/1.1" templateNs="http://www.sse.com.cn/ns/templates/NGTS" ns="http://www.sse.com.cn/ns/STEP1.0.0">
    <template id="4001" name="MDSnapshotFullRefresh_4001">
        <string id="1500" name="MDStreamID">
            <copy/>
        </string>
        <string id="48" name="SecurityID">
            <tail/>
        </string>
        <byteVector id="55" name="Symbol" presence="optional">
            <default/>
        </byteVector>
        <uInt64 id="8503" name="NumTrades" presence="optional">
            <delta/>
        </uInt64>
        <uInt64 id="1020" name="TradeVolume" presence="optional">
            <delta/>
        </uInt64>
        <decimal id="8504" name="TotalValueTraded" presence="optional">
            <delta/>
        </decimal>
        <decimal id="140" name="PrevClosePx" presence="optional">
            <delta/>
        </decimal>
        <decimal id="734" name="PrevSetPx" presence="optional">
            <delta/>
        </decimal>
        <uInt64 id="8506" name="TotalLongPosition" presence="optional">
            <delta/>
        </uInt64>
        <sequence name="MDFullGrp">
            <length id="268" name="NoMDEntries">
                <copy/>
            </length>
            <string id="269" name="MDEntryType"></string>
            <decimal id="270" name="MDEntryPx" presence="optional">
                <delta/>
            </decimal>
            <uInt64 id="271" name="MDEntrySize" presence="optional">
                <delta/>
            </uInt64>
            <string id="273" name="MDEntryTime" presence="optional">
                <tail/>
            </string>
            <uInt32 id="290" name="MDEntryPositionNo" presence="optional"></uInt32>
        </sequence>
        <string id="8538" name="TradingPhaseCode" presence="optional">
            <copy/>
        </string>
    </template>
</templates>
  1. 依照模板文件和 PMap（110110），循环迭代模板文件中剩余的域，得到如表 5 所示的原始数据中黄色部分的解析结果。
    表 5. FAST 协议消息黄色部分数据流解码过程

有几点需要注意的是：

  • 从 NumTrades 到 TotalLongPosition，它们都是 delta 和 optional 的组合，根据表 3 对照表可知它们在 PMap 中无需占用比特位，无需检查 PMap，数据流中默认有其值。
  • decimal 类型的数据要使用两个含停止位的字节序列，分别表示指数（Exponent）和尾数（Mantissa），因此结果值为 $mantissa \times 10^{exponent}$。
  • 不同类型的数据有不同的解析方式，具体可以参考 FAST Specification Version 1.1，这里不展开赘述，并不影响我们理解核心算法流程。
  1. 根据模板文件，继续解析 <sequence>，其中 <length> 指明了序列的长度，且根据图 5 的消息结构，序列中每一项都含有各自的 PMap 信息。表 6 是解码序列中前两项得到的结果。
    表 6. FAST 协议消息绿色部分序列前两项解码过程
  2. 依次解析完剩余域，并重复上述过程完成后续数据流的解析。

2.2.4. 协议引擎

和 FIX 协议一样，FAST 协议也有很多开源的实现，包括：OpenFAST（Java）、QuickFAST（C++）、mFast（C++）、goFAST（Golang，未完全实现）等。

相较于 QuickFast，mFast 具有更少的外部依赖（仅依赖 Boost 库头文件和用于 XML 解析的 TinyXML2 库），内存占用更少，性能也更优。片段 5 是使用 mFast 解析图 7 个股期权数据流得到的结果（仅显示前 5 条消息）：

片段 5. 个股期权数据流解析结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Template id: 4001
Template name: MDSnapshotFullRefresh_4001

[Message 0]
{"MDStreamID":"M0301","SecurityID":"10000911","NumTrades":821,"TradeVolume":3529,"TotalValueTraded":473404,"PrevClosePx":0.0116,"PrevSetPx":0.0116,"TotalLongPosition":21052,"MDFullGrp":[{"MDEntryType":"0","MDEntryPx":0.012,"MDEntrySize":20,"MDEntryPositionNo":0},{"MDEntryType":"0","MDEntryPx":0.0119,"MDEntrySize":20,"MDEntryPositionNo":1},{"MDEntryType":"0","MDEntryPx":0.0118,"MDEntrySize":10,"MDEntryPositionNo":2},{"MDEntryType":"0","MDEntryPx":0.0117,"MDEntrySize":20,"MDEntryPositionNo":3},{"MDEntryType":"0","MDEntryPx":0.0116,"MDEntrySize":20,"MDEntryPositionNo":4},{"MDEntryType":"1","MDEntryPx":0.0121,"MDEntrySize":20,"MDEntryPositionNo":0},{"MDEntryType":"1","MDEntryPx":0.0123,"MDEntrySize":10,"MDEntryPositionNo":1},{"MDEntryType":"1","MDEntryPx":0.0124,"MDEntrySize":20,"MDEntryPositionNo":2},{"MDEntryType":"1","MDEntryPx":0.0126,"MDEntrySize":20,"MDEntryPositionNo":3},{"MDEntryType":"1","MDEntryPx":0.0127,"MDEntrySize":10,"MDEntryPositionNo":4},{"MDEntryType":"2","MDEntryPx":0.0121,"MDEntrySize":5,"MDEntryTime":"10343214"},{"MDEntryType":"4","MDEntryPx":0.0116},{"MDEntryType":"5"},{"MDEntryType":"6","MDEntryPx":0.00000},{"MDEntryType":"7","MDEntryPx":0.0156},{"MDEntryType":"8","MDEntryPx":0.011},{"MDEntryType":"x","MDEntryPx":0.0116,"MDEntrySize":0,"MDEntryTime":"09250017"}],"TradingPhaseCode":"T 01"}

[Message 1]
{"MDStreamID":"M0301","SecurityID":"10000912","NumTrades":342,"TradeVolume":881,"TotalValueTraded":958045,"PrevClosePx":0.117,"PrevSetPx":0.117,"TotalLongPosition":3241,"MDFullGrp":[{"MDEntryType":"0","MDEntryPx":0.1141,"MDEntrySize":20,"MDEntryPositionNo":0},{"MDEntryType":"0","MDEntryPx":0.1139,"MDEntrySize":10,"MDEntryPositionNo":1},{"MDEntryType":"0","MDEntryPx":0.1137,"MDEntrySize":3,"MDEntryPositionNo":2},{"MDEntryType":"0","MDEntryPx":0.1136,"MDEntrySize":10,"MDEntryPositionNo":3},{"MDEntryType":"0","MDEntryPx":0.1135,"MDEntrySize":10,"MDEntryPositionNo":4},{"MDEntryType":"1","MDEntryPx":0.1145,"MDEntrySize":10,"MDEntryPositionNo":0},{"MDEntryType":"1","MDEntryPx":0.1149,"MDEntrySize":10,"MDEntryPositionNo":1},{"MDEntryType":"1","MDEntryPx":0.1154,"MDEntrySize":10,"MDEntryPositionNo":2},{"MDEntryType":"1","MDEntryPx":0.1155,"MDEntrySize":10,"MDEntryPositionNo":3},{"MDEntryType":"1","MDEntryPx":0.1156,"MDEntrySize":10,"MDEntryPositionNo":4},{"MDEntryType":"2","MDEntryPx":0.1141,"MDEntrySize":1,"MDEntryTime":"10343356"},{"MDEntryType":"4","MDEntryPx":0.1172},{"MDEntryType":"5"},{"MDEntryType":"6","MDEntryPx":0.00000},{"MDEntryType":"7","MDEntryPx":0.1192},{"MDEntryType":"8","MDEntryPx":0.1014},{"MDEntryType":"x","MDEntryPx":0.117,"MDEntrySize":0,"MDEntryTime":"09250017"}],"TradingPhaseCode":"T 01"}

[Message 2]
{"MDStreamID":"M0301","SecurityID":"10000897","NumTrades":240,"TradeVolume":426,"TotalValueTraded":1170954,"PrevClosePx":0.2651,"PrevSetPx":0.2671,"TotalLongPosition":11156,"MDFullGrp":[{"MDEntryType":"0","MDEntryPx":0.2665,"MDEntrySize":10,"MDEntryPositionNo":0},{"MDEntryType":"0","MDEntryPx":0.2663,"MDEntrySize":10,"MDEntryPositionNo":1},{"MDEntryType":"0","MDEntryPx":0.2659,"MDEntrySize":10,"MDEntryPositionNo":2},{"MDEntryType":"0","MDEntryPx":0.2656,"MDEntrySize":10,"MDEntryPositionNo":3},{"MDEntryType":"0","MDEntryPx":0.265,"MDEntrySize":50,"MDEntryPositionNo":4},{"MDEntryType":"1","MDEntryPx":0.2696,"MDEntrySize":17,"MDEntryPositionNo":0},{"MDEntryType":"1","MDEntryPx":0.2697,"MDEntrySize":3,"MDEntryPositionNo":1},{"MDEntryType":"1","MDEntryPx":0.2698,"MDEntrySize":10,"MDEntryPositionNo":2},{"MDEntryType":"1","MDEntryPx":0.2699,"MDEntrySize":10,"MDEntryPositionNo":3},{"MDEntryType":"1","MDEntryPx":0.2702,"MDEntrySize":10,"MDEntryPositionNo":4},{"MDEntryType":"2","MDEntryPx":0.2699,"MDEntrySize":1,"MDEntryTime":"10341230"},{"MDEntryType":"4","MDEntryPx":0.2663},{"MDEntryType":"5"},{"MDEntryType":"6","MDEntryPx":0.00000},{"MDEntryType":"7","MDEntryPx":0.2831},{"MDEntryType":"8","MDEntryPx":0.264},{"MDEntryType":"x","MDEntryPx":0.2663,"MDEntrySize":0,"MDEntryTime":"09250017"}],"TradingPhaseCode":"T 01"}

[Message 3]
{"MDStreamID":"M0301","SecurityID":"10000898","NumTrades":226,"TradeVolume":739,"TotalValueTraded":100306,"PrevClosePx":0.0135,"PrevSetPx":0.0135,"TotalLongPosition":20007,"MDFullGrp":[{"MDEntryType":"0","MDEntryPx":0.0139,"MDEntrySize":5,"MDEntryPositionNo":0},{"MDEntryType":"0","MDEntryPx":0.0137,"MDEntrySize":6,"MDEntryPositionNo":1},{"MDEntryType":"0","MDEntryPx":0.0133,"MDEntrySize":40,"MDEntryPositionNo":2},{"MDEntryType":"0","MDEntryPx":0.0132,"MDEntrySize":19,"MDEntryPositionNo":3},{"MDEntryType":"0","MDEntryPx":0.0131,"MDEntrySize":25,"MDEntryPositionNo":4},{"MDEntryType":"1","MDEntryPx":0.014,"MDEntrySize":26,"MDEntryPositionNo":0},{"MDEntryType":"1","MDEntryPx":0.0141,"MDEntrySize":30,"MDEntryPositionNo":1},{"MDEntryType":"1","MDEntryPx":0.0142,"MDEntrySize":31,"MDEntryPositionNo":2},{"MDEntryType":"1","MDEntryPx":0.0143,"MDEntrySize":21,"MDEntryPositionNo":3},{"MDEntryType":"1","MDEntryPx":0.0144,"MDEntrySize":31,"MDEntryPositionNo":4},{"MDEntryType":"2","MDEntryPx":0.014,"MDEntrySize":2,"MDEntryTime":"10342881"},{"MDEntryType":"4","MDEntryPx":0.0132},{"MDEntryType":"5"},{"MDEntryType":"6","MDEntryPx":0.00000},{"MDEntryType":"7","MDEntryPx":0.0141},{"MDEntryType":"8","MDEntryPx":0.013},{"MDEntryType":"x","MDEntryPx":0.0132,"MDEntrySize":0,"MDEntryTime":"09250017"}],"TradingPhaseCode":"T 01"}

[Message 4]
{"MDStreamID":"M0301","SecurityID":"10000843","NumTrades":434,"TradeVolume":839,"TotalValueTraded":1835824,"PrevClosePx":0.2077,"PrevSetPx":0.2077,"TotalLongPosition":10843,"MDFullGrp":[{"MDEntryType":"0","MDEntryPx":0.2111,"MDEntrySize":10,"MDEntryPositionNo":0},{"MDEntryType":"0","MDEntryPx":0.211,"MDEntrySize":10,"MDEntryPositionNo":1},{"MDEntryType":"0","MDEntryPx":0.2107,"MDEntrySize":10,"MDEntryPositionNo":2},{"MDEntryType":"0","MDEntryPx":0.2095,"MDEntrySize":10,"MDEntryPositionNo":3},{"MDEntryType":"0","MDEntryPx":0.2091,"MDEntrySize":10,"MDEntryPositionNo":4},{"MDEntryType":"1","MDEntryPx":0.2128,"MDEntrySize":22,"MDEntryPositionNo":0},{"MDEntryType":"1","MDEntryPx":0.2137,"MDEntrySize":10,"MDEntryPositionNo":1},{"MDEntryType":"1","MDEntryPx":0.2143,"MDEntrySize":10,"MDEntryPositionNo":2},{"MDEntryType":"1","MDEntryPx":0.2148,"MDEntrySize":20,"MDEntryPositionNo":3},{"MDEntryType":"1","MDEntryPx":0.2158,"MDEntrySize":10,"MDEntryPositionNo":4},{"MDEntryType":"2","MDEntryPx":0.215,"MDEntrySize":1,"MDEntryTime":"10313301"},{"MDEntryType":"4","MDEntryPx":0.206},{"MDEntryType":"5"},{"MDEntryType":"6","MDEntryPx":0.00000},{"MDEntryType":"7","MDEntryPx":0.2256},{"MDEntryType":"8","MDEntryPx":0.2055},{"MDEntryType":"x","MDEntryPx":0.2077,"MDEntrySize":0,"MDEntryTime":"09250017"}],"TradingPhaseCode":"T 01"}

...

2.3. 其他协议

金融标准主要包括：1）数据协议的标准化；2）接口的标准化。它们规范了通信报文的格式和通信方式，从而推动直通式处理（Straight Through Processing，STP）的发展。表 7 列举了主流的金融标准。

标准 —— 为了在一定范围内获得最佳秩序，经协商一致制定并由公认机构批准，共同使用和重复使用的一种规范性文件。

—— 全国金融标准化技术委员会（金标委）

表 7. 主流金融标准

从上文提到的电子化交易协议清单中可以看出，FIX 协议依然是大部分交易所的传统主流选择。除了上文介绍的 FIX 和 FAST 协议，本节将介绍其他一些重要的通信协议。

所有金融通信协议都有相同的目标 —— 价格更新和订单处理。

2.3.1. IMIX

银行间市场最为重要的数据标准是 JR/T 0066 系列标准，它规范了整个银行间市场统一业务数据交换体系。它由金标委审查，人民银行发布实施，主要由表 8 中三项基础性标准所构成。

表 8. JR/T 0066系列标准

如表 8 所示，系列中的 JR / T 0066-2011 标准定义了数据传输的标准格式 —— IMIX 协议，它是结合了中国银行间市场实际业务，且数据模型兼容 FIX 协议标准的一种协议。IMIX 协议支持多种表示格式，如：文本格式、XML 格式和二进制格式。类似的，它也由域号、域名和域值组成一个数据域。在文本格式中，数据元素由tag=value<SOH>所表示。为保证域的唯一性，自定义域的域号一般大于 10000。图 8 是 IMIX 协议的完整报文结构，其中有几点需要说明的是：

  • 起始串（域 8）、报文体长度（域 9）、报文类型（域 35）构成报文头，且位置不可变
  • 需要加密的数据一般在加密后放置在 SecureData 域，加密方法由连接双方达成一致
  • 校验和域（域 10）作为报文尾的最后一个域，用于确保数据的完整性

图 8. IMIX 协议报文结构

IMIX 可以实现可靠传输，该机制的核心原理是 IMIX 对所有传输的报文以统一的自增长序号编号。连接双方在识别到跳号或乱序时，会以特定类型的报文触发异常场景处理以恢复传输，如报文缺口填补、报文重复发送等。

使用 IMIX 协议的应用程序开发人员通常需要关注以下几类工具：

  1. IMIX 协议包（即：协议标准类库）：它是一组对象 / 接口定义的集合，包含了对 IMIX 协议定义的报文、重复组、域等数据结构定义的具体实现。
  2. IMIX 基础组件（即：API 接口类库、IMIX 应用开发包）：负责数据交互，主要用于接入 MDS（Market Data Service，行情数据服务）、文件等接口
  3. IMIX 开发指引、API 开发手册：规范性、技术性、指导性文档

2.3.2. ITCH/OUCH

ITCH 和 OUCH 是纳斯达克股票市场（NASDAQ）主要使用的通信协议。两者都是二进制协议，使用固定的偏移量来指定标签值，它们的区别在于：

  • ITCH：主要基于组播或 TCP，负责直接数据传输（Data Feed），如：订单级数据、交易信息、事件信息等
  • OUCH：主要基于 TCP，负责直接交易（Orders），如：订单提交、订单修改和取消、订单接收执行和确认等

2.3.3. HTTP

加密货币市场的消息通信一般都基于 HTTP 协议，所以普遍采用 RESTful API 或 WebSocket 的方式，此处不再赘述。

3. 小结

本文作为《高频交易系统核心构建技术的探索与实践》系列文章的第一篇，由 UDP 组播业务需求场景引出，主要介绍了高频交易系统的背景和相关核心技术，并深入剖析了国内证券交易所使用的基于 UDP 的二进制协议 —— FAST 协议，展示了真实业务场景下数据流的编码解码。此外还介绍了其他一些主流通信协议，如：国内银行间市场主要使用的 IMIX 协议等。受限于篇幅，使用 FPGA 优化网络性能的主题并未涉及，将在系列后续文章中另行展开详述。

最后，图 9 从更宏观的视角展示了一条消息（本质是数据包）的完整生命周期，其中：NIC（Network Interface Card，网络设备），如：FPGA（Field Programmable Gate Array，现场可编程门阵列），会绕过 CPU 直接使用 DMA（Direct Memory Access，直接内存存取）操作将网络数据包复制到负责接收数据的 RX（Receive Buffer，接收缓冲区）的环形缓冲区中。网络设备驱动会分别触发软中断和硬中断，同时会为 RX 中的数据包分配 SKB（Socket Buffer，套接字缓存），随后在数据进入 IP 层和 TCP 层前，内核空间（Kernel Space）分别移除以太网头部和 IP 头部。移除 TCP 头部后，最终和用户空间（User Space）的应用层应用建立 Socket 连接。

图 9. 数据包传输和流转生命周期

4. 参考文献

  • Aldridge, Irene. High-frequency trading: a practical guide to algorithmic strategies and trading systems. United Kingdom, Wiley, 2013.
  • Narang, Rishi K.. Inside the black box: A simple guide to quantitative and high frequency trading. Germany, Wiley, 2013.
  • 魏瑾瑞. 统计学视角下的金融高频数据挖掘理论与方法研究. China, 中国社会科学出版社, 2015.
  • 许再越，程晓松. 外汇市场与交易系统. China, 浙江大学出版社, 2017.
  • Donadio, Sebastien, and Ghosh, Sourav. Learn Algorithmic Trading: Build and Deploy Algorithmic Trading Systems and Strategies Using Python and Advanced Data Analysis. United Kingdom, Packt Publishing, 2019.
  • List of electronic trading protocols
  • FAST Specification Version 1.1
  • FAST Protocol Technical Overview
  • mFast - A FAST (FIX Adapted for STreaming) encoder/decoder