138 2012，48（1） Computer Engineering and Applications 计算机工程与应用 基于扩展 FAST 协议的金融消息压缩方法 徐广斌 1，2，武剑锋 1，王 泊 1，黄寅飞 1，胡汉英 1，刘 凯 1，林 征 1，白 硕 1 XU Guangbin1，2, WU Jianfeng1, WANG Bo1, HUANG Yinfei1, HU Hanying1, LIU Kai1, LIN Zheng1, BAI Shuo1 1.上海证券交易所 技术中心，上海 200120 2.复旦大学 计算机科学技术学院，上海 200443 1.Technology Center of Shanghai Stock Exchange, Shanghai 200120, China 2.School of Computer Science, Fudan University, Shanghai 200443, China XU Guangbin, WU Jianfeng, WANG Bo, et al. Financial message compression method based on extended FAST protocol. Com- puter Engineering and Applications, 2012, 48（1）：138-141. Abstract：Recently some FAST1.1-based financial message compression methods have been presented to decrease high redundancy of commonly used financial exchange message formats such as DBF, XML etc. These methods are neither capable of supporting the new- est FAST1.2, nor can support the procedure-oriented programming paradigm and running environment. This paper presents FASTX：a financial message compression method based on Extended FAST, which achieves better encoding efficiency and faster speed than exist- ing methods. It also presents a new reference for designing and implementing FAST/Extended-FAST in procedure-oriented program- ming paradigm. The experimental results demonstrate FASTX works efficiently—for the same data content, the encoded data size is on- ly of about a quarter of the DBF’s. Some comparisons with other commonly used formats are also conducted. The experimental results verify feasibility and effectiveness of FASTX. Key words：Financial Information Exchange Adapted for Streaming（FAST）protocol; procedure-oriented; Financial Information Ex- change（FIX）protocol 摘 要：为降低金融交换消息的大小，近年来已出现 QuickFast、OpenFast 等基于 FAST1.1 协议的金融消息压缩方法。然而现有方 法不支持压缩率更高的 FAST1.2 协议，也无法支持面向过程的开发运行环境。提出基于扩展 FAST 的金融消息压缩方法 FASTX， 不仅可以达到更好的编码效率和速度，还为在面向过程编程模式下实现 FAST1.2 提供了新的方法。实验结果表明 FASTX 编码效 率十分高，只需约DBF1/4的大小就可表示相同的内容，与其他几种常用数据格式也进行了对比，验证了新方法的可行性和有效性。 关键词：适流金融信息交换（FAST）协议；面向过程；金融信息交换（FIX）协议 DOI：10.3778/j.issn.1002-8331.2012.01.040 文章编号：1002-8331（2012）01-0138-04 文献标识码：A 中图分类号：TP319 1 引言 近年来，随着金融全球化趋势的增强，以及证券、期货、银 行等业务的快速发展，金融领域内的消息量激增。根据文献[1]， 仅在证券和期货领域，全球日均产生的消息量将从 2007 年的 七十多亿条猛增至 2010 年的一千两百多亿条。实际上，消息 增长带来的带宽及延迟的问题已经成为金融信息交换的一个 技术挑战。 现有的金融信息交换大多基于 DBF、FIX、XML、XBRL、 TXT 等格式，存在信息冗余度较大、带宽占用率高的缺陷，难 以 满 足 未 来 带 宽 和 延 迟 的 需 求 。 FAST（FIX Adapted for Streaming，适流 FIX）[2]是由全球金融企业联盟组织 FPL 在 2005 年所提出的、针对业内通行的金融信息消息协议 FIX[3]的 一套压缩和传输方法。压缩率高、简单、实用的特点，使得 FAST 在推出之后很快为各主要金融单位所关注并相继开展 FAST 技术的研究和开发，例如，世界最大的期货与期权交易 所 CME，以及 NYSE ARCA、BATS、SIAC、BOVESPA 等大型 交易所，ICAP 等主要投行[4]都开始在各自的系统中采用 FAST 压缩消息大小。相应地，以 QuickFast、OpenFast 为代表的一些 方法被提出。 FPL 在 2009 年推出了扩展 FAST[5]，即 FAST1.2。通过对 字段数据类型、编码方式的扩展，FAST1.2 的编码可以达到比 FAST1.1 等老版本更优的压缩效果。然而，现有方法均是针对 FAST1.1 设计和开发的，尚未有基于扩展 FAST 的压缩方法被 提 出 。 本 文 提 出 基 于 扩 展 FAST 的 金 融 消 息 压 缩 方 法 FASTX。FASTX 基于面向过程的编程模式设计并实现了扩展 FAST，不仅可以达到比基于 FAST1.1 的现有方法更好的编码 效 率 ，而 且 基 于 标 准 C 的 FASTX 可 以 获 得 比 基 于 Java 的 OpenFast 等现有方法更快的消息编解码速度。FASTX 还为在 面向过程编程模式下实现扩展 FAST 提供了一种参考设计和 实现方法。以 DBF 格式作为输入进行测试，结果表明 FASTX 可大大降低消息数据的冗余度：表示相同数据只需 DBF 格式 约 1/4 的大小，实验还与其他几种数据格式进行了比较，验证 了 FASTX 的可行性和有效性。 2 FASTX 基于扩展 FAST 的消息编、解码机制 FAST 的基本思想是利用消息流中先后传送的消息之间 数据的逻辑联系来减少需要传送的数据内容，并针对不同的 数据类型进行高效的二进制编码，使得实际传送的数据大小 基金项目：中国证监会证券交易数据交换编解码协议专项课题。 作者简介：徐广斌（1976—），男，博士后，CCF 会员，主要研究领域为证券交易接口、网络、系统；武剑锋（1975—），男，博士，高工，副教授；白硕 （1956—），男，博士，总工，教授，博导。E-mail：gbxu@sse.com.cn 收稿日期：2010-08-25；修回日期：2010-10-25；CNKI出版：2011-02-28；http://www.cnki.net/kcms/detail/11.2127.TP.20110228.1701.014.html 

徐广斌，武剑锋，王 泊，等：基于扩展 FAST 协议的金融消息压缩方法 2012，48（1） 139 发送方 消息构建 FAST 字段 编码 FAST 传输 编码 网络传输 模版状态 一致性机制 消息 模版 （含 字典） 消息 模版 （含 字典） 副本 接收方 消息重构 FAST 字段 解码 FAST 传输 解码 网络传输 图 1 FAST 消息编、解码工作框架图 得到进一步降低。 FAST 的消息编码依据“模版”的控制结构来进行。模版 包含一个字段指令的序列，字段指令主要规定了如何将字段 的实例编码成为字节流，其顺序与数据在流中的位置相对 应。字段指令通过规定字段的顺序和结构、字段的逻辑运算 及其字段二进制编码的表示方式来控制对数据流的编码。 具体来说，FAST 按照“字段编码”和“传输编码”两个层次 的编码方法来降低数据流的大小。首先如图 2 所示，字段编码 在将 FIX 消息流序列化为字节流的过程中利用消息之间字段 数据的逻辑规律来对字段进行编码处理，从而减少需要传递 的信息。其次，在对剩余数据进行传送编码时，利用“隐式标 签”，可自描述长度的“停止位编码（SBE）”、二进制串行化编码 等手段来降低物理空间占用。 起始串 发送方 接收方 序号 时间 证券标识 价格 8=STEP.1.0.0|49=XSHG|56=EZVIEW|34=10001|52=201007131200100|55=国债 01|140=1200| 8=STEP.1.0.0|49=XSHG|56=EZVIEW|34=10002|52=201007131200200|55=国债 01|140=1210| 8=STEP.1.0.0|49=XSHG|56=EZVIEW|34=10003|52=201007131200500|55=国债 01|140=1190| constant constant constant increment tail copy delta 10001 201007131200100 200 500 国债 01 1200 10 －20 图 2 FAST 字段编码示意图 FAST 定义的应用数据类型包括 Ascii 码字符串（Ascii string）、Unicode 字 符 串（UTF-8 string）、字 节 向 量（byteVec- tor）、符号整数（signed int）、无符号整数（unsigned int）、浮点 数（decimal）、序列（sequence）、分组（group），在扩展 FAST 中又 增加了位元组（bitGroup）、枚举（enumeration）、布尔（boolean）、 集合（set）等数据类型。对于字段，可以使用拷贝（copy）、差值 （delta）、缺省（default）、递增（increment）、常值（constant）、换尾 （tail）等逻辑运算符（operator）来对字段进行优化运算。对于 每一字段，可以指定名称和类型来标识当前的应用类型，并规 定字段的二进制编码方法，还可以使用可选的存在（presence） 参数来指示字段是否必须在字节流中出现。 FAST 在根据模版进行编、解码的时候，其所含的指令在 运行上下文环境中进行执行，这包括：使用的模版集、当前使 用的模版、应用类型集、当前应用类型、字典集以及可选的字 段的初值。其中，字典是一种有状态结构，用以保存前一个包 含该字段的应用消息的该字段的应用值，也即字段的前值 （previous value）。对 FAST 编解码来说，字典对字段前值的维 护有着十分重要的意义，因为前述对字段进行的优化运算均 依赖于收发双方能够维护一致的前值和字段状态。如果采用 TCP 等可靠的传输层，则这种依赖不会造成问题，因为消息不 会丢失。但是，如果使用 UDP 等不可靠的传输层，则需要特别 考虑对数据包间的相互依赖性。为确保编解码双方模版状态 的一致性，FPL 推出了 FAST SCP 协议 [6]来支持模版交互和 FAST 会话。 3 FASTX 静态视图 FAST 主要是一种面向动态消息数据的编码方法，对于运 行时空间的要求不高，所以 FASTX 中主要采用了静态的数据 结构。由于 FASTX 是以消息为单位进行编码和解码处理的， 为此编/解码器中分别包括了输入一条消息的输入缓冲区和输 出一条消息的输出缓冲区，当作为编码器使用时，前者缓存原 始格式的消息，后者缓存编码后的消息，在 FASTX 作为解码器 使用的时候则与之相反。 在 FAST 编解码开始之前，必须提前载入需要使用的模 版。FASTX 支持两层次的模版结构：全局模版以及自定义模 版，前者主要用于使用的模版集的模版 ID 的编解码以及其他 需要在全局范围进行编解码的字段，后者主要是各类消息分 别使用的模版。全局模版相对固定，主要是全局编码字段的 数据结构的一个集合，而消息模版则根据具体应用的不同而 互不相同。对于消息所使用的模版的集合，FASTX 采用标准 的 XML 格式模版来表示，并使用标准 xml 处理库 libxml2 来进 行处理。根据扩展 FAST 模版和应用类型的特点以及标准 C 的特点，FASTX 使用一个分层嵌套的静态数据结构来表示消 息模版集，主要为一个多层级的静态连表结构。模版集唯一， 模版集中包括由一个或多个模版结构构成的静态数组，每个 模版结构包括所有应用类型的数组结构，其中每个节点包含 与该字段相关的所有变量，以及指向其他节点的静态指针，属 于该模版的第一层的所有应用类型使用静态指针串成一个静 态链表，模版包含一个指向该静态链表的静态头指针。对于 序列、分组、位元组等复合类型，则各自包括了一个子段结构， 属于该子段的第一层次的应用类型使用静态指针串成一个静 态链表，子段的静态头指针指向所属的第一个字段，尾指针指 向所属的最后一个字段。使用这种静态模版集结构，FASTX 就可以通过对 XML 模版文件进行深度递归，在内存中完成对 模版集的加载。FASTX 的静态结构如图 3 所示。 FASTX 消息 输入 编码 输出 编码消息 消息模版 全局模版 模版集 int1 int2 int3 int4 … 模版 1 模版 2 … string1 string2 next dcml1 dcml2 dcml3 dcml4 … sub seg head tail … seq2 seq1 seq4 group1 group2 group3 group4 seq3 … … … … 图 3 FASTX 静态视图 如图 4 所示，FASTX 的数据结构及处理函数按照从外至 内、从高到低的层次划分为 5 层，其中调试类为开发过程中使 用其他数据结构及函数。 

140 2012，48（1） Computer Engineering and Applications 计算机工程与应用 调用接口层 模版树处理/遍历层 应用类型编解码层 调试类 扩展 FAST 协议支持层 通用处理层 图 4 FASTX 数据结构及函数层次图 4 FASTX 运行视图 在初始化时，FASTX 从 XML 文件中载入模版集，并填装 到前述的结构中。此后，FASTX 可以根据需要动态生成多个 编/解码器运行实例来进行 FAST 编解码，每个运行实例负责一 路单向的编码或者解码。因此，一条双向的 FAST 通道可由一 个编码器和一个解码器构成，由多个编/解码器就可以构成多 条 FAST 通道。FASTX 对编/解码器的控制通过一个控制结构 来进行。在创建编/解码器实例时，编/解码器的结构由动态生 成，其指针加入编解码器控制结构，同时模版结构被拷贝到编/ 解码器包含的相应结构中。随后，该编/解码器包含的所有模 版字段的字典状态被重置为未定义（undefined）。 FASTX Codecs 消息 输入 编码 输出 编码消息 模版/ 字典 全局模 版/字典 Channel 1 消息 输出 编码 输入 编码消息 Codec Controller 模版/ 字典 全局模 版/字典 消息 输出 编码 输入 编码消息 模版/ 字典 全局模 版/字典 Channel 2 消息 输入 编码 输出 编码消息 模版/ 字典 全局模 版/字典 图 5 FASTX 运行视图 如前所述，模版结构所含的应用类型节点中封装了与该 节点相关的数据变量，如果应用类型为字段，则其还包括了字 段的前值（previous value）、初始值（initial value）、是否为可选 以及该字段的字典状态。对于一条 FIX 消息的字段来说，字典 关键字通常为其 tag 值，而对于其他数据的编码来说，通常只 要能保证各个字段名称不重复，则以其为字典关键字，但不论 是哪种情况，模版结构中不同字段采用不同节点保存的方法 保证了关键字的不重复，所有字段节点的集合也就构成对应 该模版的那部分字典。因此，在 FASTX 中，除全局字典外，自 定义模版字典的实现和模版本身使用了同一套树状数据结 构，而与普通意义的“字典”不同，FASTX 的字典实际上是对应 该模版所含字段的子集，不同模版可包括相同关键字的字段， 相互不受影响。这种设计不仅节省了不被使用的关键字所需 的空间，而且更符合应用逻辑：不同模版的相同关键字的字段 的应用数据之间可能存在较大差异，若使用相同的字典单元 来编解码可能得不偿失。利用该结构，FASTX 对消息的编解 码过程被简化为对该结构进行一次深度遍历，由于 FASTX 主 要使用静态结构，这种设计使得无需再另外使用 hash 表等更 复杂的数据结构来实现字典查找，编/解码速度也因此更快。 字典状态的重置实现起来较为简单：只要顺序地将模版集静 态结构所含的所有基本应用类型的节点的状态置为未定义状 态即可。 5 FASTX 基于扩展 FAST 的消息编解码 FASTX 对扩展 FAST 消息的编解码以消息为单位，其基本 过程是对前述的模版集结构的一次遍历，遍历结束则对一条 消息的编解码也就完成了。这种遍历的过程，也是对消息所 含的字段顺序进行编解码的过程。当遍历进行到一个应用类 型节点时，遍历函数根据应用类型的不同，调用相应的编/解码 函数来进行字段的运算和字节流编解码。FASTX 对应用类型 的编解码遵循扩展 FAST，在对各种类型，特别是序列、分组、 位元组等复杂应用类型的处理上各自不同。 FASTX 对于符号整数、无符号整数、不超过 1 字节的符号 或无符号短整数均使用相同的 int 静态链表结构来存储，其节 点带有表示数据位元范围的变量，因此在理论上可以支持任 意位大小的整数类型。可使用拷贝、差值、缺省、常值等运算 符或无运算符来定义字段数据流的逻辑特性，其中无符号整 数还可以使用递增运算符来描述序号类的字段。 对于浮点数，FAST 用带符号的两个整数来表示，它们分 别表示浮点数的底数和指数，这使得浮点数的表示范围可扩 展到 ISA 所支持的最大位数。在表示一个应用值时，指数和尾 数缺一不可，而在表示空值时，只用指数的空值表示方式来表 示。浮点数两部分的传输编解码方法与整数的情况类似。 对于字符串类型的应用值，一般的字符类型可以用 ASCII 类型来表示，中文等多国语言类型等则可用 UTF-8 的类型来 表示。FASTX 根据字符串具体是 UTF-8 类型还是 ASCII 类型 在处理有所不同：对于 ASCII 码，其字节不超过 0x7f，不仅可以 直接使用现有的字符串处理函数，而且在数据串行化为二进 制 SBE 时，也只需将最后一个字节的最高位置为 1 即可。如果 一个 Ascii 字串值为空，则与其他类型一样也用 0x80 来表示。 尽管 UTF-8 不含 0x00，可以使用 strlen 等字符串处理函数，但 UTF-8 字串中可能含字节高位为 1 的字符，这与 SBE 相冲突， 而且 UTF-8 还可能含 FIX 分隔符 0x01 等的特殊字符，因此在 进行传输编码时需要通过一个长度前导来表示字符串所占的 字节长度。应用层在对应用数据进行处理时也需要注意对于 0x01 等特殊字符的处理，通常可以在应用值的结尾加上一个 表示空的 0x00 尾值。 字节向量的运算与字符串类似，且与 UTF-8 的编解码相 似，数据无需转换为 SBE 传输。不同的是，字节向量对原始数 据的格式不做任何规定，不能通过字符串处理函数来获得长 度，所以应用层需要有一个长度的处理句柄。事实上，在应用 层，字节向量总是紧接在一个表示长度的字段之后，在 FAST 中其为一个 32 位无符号的整数类型字段。因此，FASTX 在对 这种应用类型的节点进行编解码的时候需要特别判断：如果 后面紧接的是一个字节向量，则默认为是其应用层的长度前 导，其应用值也拷贝到字节向量节点中以便随后对其编解 码。除应用层带长度前导外，在字节向量编解码时也需像 UTF-8 那样添加一个编码层的长度前导。UTF-8 字串和字节 

徐广斌，武剑锋，王 泊，等：基于扩展 FAST 协议的金融消息压缩方法 2012，48（1） 141 向量类型的字段空值用其编码层长度前导的空值方式来表示。 FASTX 中序列、分组、位元组由一个或多个的段来组成。 如果有必要，每个段可具有私有的 PMAP。FASTX 在遍历到 这些应用类型的节点时会进入段的“子树”结构进行处理。其 中，根据序列的长度前导来决定重复进入处理的次数，分组或 位元组则只需被处理一次。位元组不带私有的 PMAP，且当分 组所含字段无需任何PMAP槽位时，分组也不带私有的PMAP。 在 FAST1.1 中，除字节向量外的上述几种基本数据类型在 转换为 SBE 时，最小的编码单位为字节。为进一步提高 FAST 的编码效率，FASTX 采用了 FAST 扩展版本的短整型、枚举、集 合、布尔、位元组等数据类型。其中，短整型用来描述那些表 示范围占用空间不超过 1 个字节的字段。枚举和布尔类型使 用占最少比特的无符号整数来编码。位元组用来将这些最大 占用空间不超过 1 字节的数据类型字段填充到同一个 SBE 中。FASTX 对这些字段的编码和解码过程采用了格外的处 理：在编码时，首先短整型字段按照整数类型编码为 SBE，枚 举、布尔按照无符号整数编码为 SBE，然后 FASTX 根据各个字 段位元的占用大小将这些 SBE 进行合并，属于同一个位元组 的将合并为一个 SBE，其大小可能超过 1 个字节；解码时的过 程则与之相反，先取出该位元组的 SBE，然后逐一解码所含字 段，在这个过程中，如果需要的话，从位元组的 SBE 中提取相 应位元扩展成对应的字段 SBE，然后调用相关应用类型的解 码函数来进行解码。值得注意的是，位元组中不论字段是否 可选、是否有值，各字段始终对应相同位置的位元空间。 6 FASTX 测试结果 基于标准 C 实现了 FASTX，以两个静态数据文件的记录 作为消息输入模拟对 FASTX 进行了测试，并且与常用数据文 件格式的数据尺寸做了比较。 表 1 FASTX 编解码测试数据示例 代码 名称 今开 最高 最低 最新 000001.SZ 000002.SZ 000004.SZ 000005.SZ 000006.SZ 000007.SZ 000009.SZ 000011.SZ 深发展 A 万科 A ST 国农 世纪星源 深振业 A ST 零七 中国宝安 深物业 A 17.27 7.21 9.39 4.28 5.47 7.15 9.85 7.35 17.47 7.26 9.67 4.34 5.52 7.52 10.04 7.48 17.08 7.13 9.26 4.23 5.42 7.10 9.80 7.27 17.11 7.15 9.50 4.24 5.43 7.31 9.92 7.29 涨跌 －0.56 －0.15 0.05 －0.09 －0.11 0.14 －0.03 －0.22 涨跌幅 －0.031 7 －0.020 5 0.005 3 －0.020 8 －0.019 9 0.019 5 －0.003 0 －0.029 3 成交量 28 464 074 57 343 575 678 495 10 843 786 5 154 657 3 964 004 12 572 009 4 539 558 … … … … … … … … … 实验 1 选取 2010 年 6 月 10 日的沪深股市股本信息数据， 剔除少量空字段记录后共 1 791 行记录，每行记录对应一种证 券。一条记录的格式为{“代码”，“名称”，“今开”，“最高”，“最 低”，“最新”，“涨跌”，“涨跌幅”，“成交量”，“成交金额”，“换手 率”，“年初至今涨跌幅”，“5 日涨跌幅”，“每股收益”，“市盈 率”，“市净率”，“所属行业”，“时间”}，表 1 中列出了实验 1 中 部分记录的部分字段数据的示例。实验 2 选取 2010 年 6 月 11 日的沪市 A 股上市公司概览数据，剔除少量空字段记录后共 832 行记录，每行记录对应 1 种证券，15 个字段。 FASTX 在两次实验中都正确地完成了编解码，测试的 FAST 编码消息比 DBF 小 70%以上，只需 DBF 的约 1/4 大小就 可表示相同的内容，具体地：实验 1 的 FAST 编码消息平均大小 为 63 字节，大大小于 DBF 的 275 字节；实验 2 FAST 的编码消 息平均大小为 75 字节，也远低于 DBF 的 261 字节。还与中国 证券交易数据交换协议（STEP）、Unicode 编码文本以及 Ascii 文本等其他几种常用的金融数据格式进行了比较，测试了表 示相同内容的数据，其相应的平均消息大小与 FAST 消息大小 之间的倍比情况，测试结果如图 6 所示，其中 STEP 约为 3 倍， Unicode 文本约为 3.5 倍，Ascii 文本约为 2 倍。此外，在对相同 数据的编解码处理上 FASTX 的速度也大大快于基于 Java 的 OpenFast，约为后者的 8~10 倍。 DBF Unicode STEP Ascii 5 4 3 2 1 0 比 倍 寸 尺 FAST 图 6 几种常用格式数据与 FAST 数据的尺寸倍比图 7 结论 针对现有方法不能够支持扩展 FAST 协议，也无法支持面 向过程的编程模式，本文提出基于扩展 FAST 的金融消息压缩 方法——FASTX。在兼容 FAST1.1 和 FAST1.2 的基础上，设计 并实现了基于标准 C 的 FASTX，其中针对扩展 FAST 协议和标 准 C 的特点设计了 FASTX 的静态结构、处理层次结构和运行 结构，为面向过程的编程模式下实现扩展 FAST 提供了一种参 考方法。作为测试，以静态的 DBF 数据文件作为消息输入测 试了 FASTX，结果表明 FASTX 运转正常。同时，与不同数据 格式文件的对比测试结果表明 FAST 可大大降低消息数据的 冗余度，验证了 FASTX 的可行性和有效性。 FASTX 适用于对实时性要求较高，或带宽资源较稀缺的 金融、证券、新闻等应用场合，也可用于数据的备份和保存等。 参考文献： [1] Agarwal V，Bader D A.Faster FAST：multicore acceleration of streaming financial data[EB/OL].[2010-06-01].http://www.cc.gat- ech.edu/~bader/papers/FastFinancial-CSRD2009.pdf. [2] FPL.FAST specification version 1.x.1[EB/OL].[2010-06-01].http：// www.fixprotocol.org/documents/3064. [3] FPL.Financial Information Exchange protocol（FIX） version5.0[EB/OL]. （2008-03）[2010-06-01].http：//www.fixprotocol.org/. [4] NYSE.NYSE technologies feed handler inventory Q3 2009 edi- tion[EB/OL].[2010-06-01].http：//www.nyse.com/pdfs/wfsfhi.pdf. [5] FPL.FAST version 1.2 extension proposal[EB/OL].（200-01-18） [2010-06-01].http：//www.fixprotocol.org/documents/4376/FAST12Ex- tensionv10.pdf. [6] FPL.FAST session control protocol version 1.1[EB/OL].（2007-08-27） [2010-06-01].http：//www.fixprotocol.org/documents/3795/FASTSes- sionControlProtocol1.1.doc1.