由于作者还未在真实项目中实践，以下知识均限于学习，有些知识来源网络，不保证绝对准确。

一、FIX是什么？

是一个适用于实时证券和金融电子交易开发、不受单一实体控制的开放的数据通信标准，此协议能够被调整适用于任何一个企业的需求。

二、FIX的发展和地位

FIX（Financial Information eXchange Protocol，金融信息交换协议）是由国际FIX协会组织提供的一个开放式协议，目的是推进国际贸易电子化进程，把证券金融业务流程格式化，成为一个可用计算机语言描述的功能流程，在各种参与者之间，包括投资经理、经纪人、买方、卖方创建实时的统一交换格式的通信协议。

优点是接入新的合作方, 时间大大缩短，接入方式提明显便捷,相当于多国使用一个统一的语言交流无障碍。

缺点是据说速度慢

三、FIX基本流程

3.1 使用成员

Initiator ：发起者，建立通信连路，通过发送初始Logon消息发起会话的参与方。

Acceptor ：接收方，负责执行第一层次认证和经过传输Logon消息响应确认正式链接请求被接受

3.2 基本流程

FIX连接 由3部分组成：logon登录，message exchange消息传输，logout注销。

logon：

logout注销：

session（会话）：

介绍：一个FIX会话定义为一个在连接双方间的的带有连续序列号的有序消息双向传输流，由一个或多个FIX Connection 组成。一个FIX会话可以有多次登录，参与方能够多次连接和断开连接。

开始和结束：参与方必须根据单个系统及时间区域需求，公共协商会话的开始和结束。重新设置接收和发送序列号为1，意味着一个新的FIX会话的开始。

过程：每一个FIX参与方必须为FIX Session维护两个序列号：接收序列号和发送序列号，二者都在创建Session时初始化为1。每一个消息被赋予一个惟一的序列号值，并在消息发送后递增。每一个收到的消息都有一个惟一的序列号，接收序列号计数器在收到每一个消息后将会被递增。

3.3 使用建议

（来自网络，未实际项目实践）

建议一个新的FIX会话在每24小时建立一次。维持24小时的连接后通过设置在Logon消息中的ResetSeqNumFlag建立一套新的序列号。重置seq, 可以由session的任何一方发起, 一般会提前协商好

四、具体协议

FIX协议的数据类型:整数int,浮点数float,单个字符char,布尔Boolean,字符串String,数据data

4.1 消息格式简介

FIX协议的格式存在着两种结构

Tag=Value 域结构, 一维的文本协议，一般大家都使用此结构
FIXML 结构

4.2 Tag=Value

基本格式为:[标准头]+[信息正文域]+[标准尾]，每条信息都是由一系列Tag=Value对组成的。

除了一些特殊规定外，信息中的域可按照任意顺序排列。所有域在都以定界符0x01(<SOH>）表示终止。

列举常见的tag（仅供了解tag功能，具体参考官方文档）

4.3 结构规定

这些规定构成了消息的基石

一条FIX消息的组成, 必须是<header>+<body>+<tail>, 顺序不能变，即：开始部分应是消息头，随后是正文，最后是消息尾;
<header>的前三个tag一定是8=FIX.X.X<SOH>9=xx<SOH>35=xx<SOH>，即：起始串(Tag =8)、消息体长度(Tag =9)、消息类型(Tag =35)
<tailer>（消息尾）的最后一个tag一定是10=xxx<SOH>
重复域组的顺序, 一定是先有NoXXX+repeated fields，，域出现的顺序应遵循该重复组在消息或组件中定义时的次序;
在一条消息中，除重复组域外任何其他域不能重复出现。

图中信息解释：

域块：多个域的集合

重复组：由多个重复组块组成

组块：表示重复组中的重复部分，由域块组成

组件：多个域的集合，它们所代表的含义间有关联。

4.4 标准头结构（了解）

只列举必须字段

Tag	字段名称	字段说明	必送	注释
8	BeginString	版本号	Y	固定为FIX.4.2(不能加密，必须是消息的第1个字段)
9	BodyLength	消息体长度	Y	(不能加密，必须是消息的第2个字段)，不包括8\9\10字段长度
35	MsgType	消息类型	Y	(不能加密，必须是消息的第3个字段)
49	SenderCompID	发送者ID	Y	(不能加密)
56	TargetCompID	接收者ID	Y	(不能加密)
34	MsgSeqNum	会话序号	Y	开市期间不允许重置，除非当天第一次登录
52	SendingTime	发送时间	Y	使用UTC时间格式

4.5标准尾结构（了解）

只列举必须字段

Tag	字段名称	字段说明	必送	注释
10	CheckSum	校验位	Y	整包校验码，收发检查

4.6 自定义域（了解）

FIX为给用户提供最大的灵活性，FIX协议允许用户自定义域。这些域在认同的参与者之间实现、应用，并且应注意避免冲突。

Tag数在5000 到9999保留用于用户自定义域。这些tag值用于企业联盟的信息交换。可以通过FIX网站进行注册。10000以上保留用于单一企业内部使用。不用注册。

4.7 FIXML及其它基于XML数据的传输（了解）

尽管FIX会话协议的标准头（Standard Header），标准尾部（Standard Trailer）和管理消息是基于“tag=value”语法的，但它能够支持传输FIXML及其它基于XML的数据。FIXML及其它XML数据被夹在FIX标准头与FIX标准尾部中间，并通过标准头的XmlDataLen域指定其内容长度，XmlData域包含其具体的数据。这样，FIX引擎可以通过多年使用的，可靠的，实时地异步传输机制传送FIXML及其它XML数据。当MsgType域值为’n’时，代表传输的数据为FIX未在MsgType中定义的XML数据。

4.8实例（后续补充）

五、保证数据可靠的机制

数据传输基本存在两个核心问题：泄露和篡改。

笔者认为，主流解决方案分别就是签名（解决篡改）和加密（解决泄露），下面看下FIX的做法。

5.1保证数据完整

通过BodyLength 和CheckSum 进行检查

BodyLength（包体长度）:在tag BodyLength后面所有的数据, 包括<SOH>,程序通过计算BodyLength域到CheckSum标记（“10=”）分界符的字符数，域BodyLength标示的消息长度进行比较来完成完整性效验。

ChekSum（消息校验和）:完整性检查，通过计算从域“8=***” 中“8”开始，直到CheckSum前面的<SOH>,每个字符的2进制和，同CheckSum进行比较得到。然后，校验和被转换为模256的数字用于传送和比较。校验和在所有加密操作之后被计算。

比如：如果消息的校验和为274，则模256后为18（256+18 = 274）。这个值将采用|10=018|进行传输，其中“10=”是校验和域的标签。

char *GenerateCheckSum( char *buf, long bufLen ) {
    static char tmpBuf[ 4 ];
    long idx;
    unsigned int cks;
    for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] ); 
    sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) );
    return( tmpBuf );
}

5.2保证数据安全

为了保证信息安全，除某些需要公开识别的域以明文传输外，其他任何域都可以加密放置密文数据域 (SecureData)内，加密方法双方协议而定。（如果有些确实需要明文传输以便识别的tag, 可以再加密一份, 用于校对）

当然，这些被加密的域也可以同时保留明文的表示方式。

六、保证交互过程可靠的机制

和大多数网络传输的问题一样，需要保证：不重、不漏、时序性，为此，介绍一个重要概念

seq：每条FIX消息都有一个惟一的序列号进行标识，序列号在每个FIX Session开始时被初始化为1，并在整个Session期间递增，此序列号也是FIX实现可靠传输过程的基石。

6.1不丢包

seq

session的两端, 各自维护一个outgoing seq(每个新的msg, seq+1)和一个incoming seq(用来监控是不是丢包了)。每条FIX消息都会有一个seq, 每个FIX Session建立的时候会将seq初始化为1, 后续消息会依次累加.

通过seq, 接收方就可以知道是不是有FIX MSG丢了, 一旦发现丢失, 可以及时做出补救措施（连接管理与业务处理解耦）

HeartBeat

监控连接状态, 检查是否有msg丢失. (发送Heartbeat的周期间隔由会话发起者使用Logon消息中HeartBtInt域设置好, 双方相同，由会话发起方定义并由会话接收者通过Logon消息进行确认).

和大多数优秀的开源组件一样（如redis），在消息交互期间，FIX程序周期性产生心跳消息，该消息可以监控通信链路状态及识别接受序列号间隙。

Heartbeat心跳消息的时间间隔在每一个消息发送后复位，即发送一个消息后，在间隔给定的时间内无其它消息发送则发送一个Heartbeat心跳消息。

再强调一遍，同一个HeartBtInt被会话双方——登录的发起者和登录的接受者共同使用。

6.2不重复

6.3时序性

客户端：

还是通过seq，按照seq的从小到大, 依次处理.

如果收到了5个消息中的1,2, 4, 5, 而丢掉了第3个msg, 那么处理方式有2种.
1、接收方生成这个ResendRequest, 要求发送方将3-5这3个消息全都
重新发送一遍.
2、接收方生成这个ResendRequest, 要求发送方将第3个消息重新发
送一遍

两种方式的利弊很明显，就不分析了，记住：无论怎样，客户端收到完整的消息后, 再依次处理。

服务端：

重传请求的响应消息都包含值为‘Y’的PossDupFlag域。没有PossDupFlag域或PossDupFlag域为‘N’的消息应被看成初始传送消息。值为‘Y’的重传消息要重新计算其CheckSum值。复制消息中发生变化的域包括：CheckSum，OrigSendingTime，SendingTime，BodyLength和PossDupFlag，加密相关域（SecureDataLen和SecureData）也必须被重新构造。

两种重传情况

1）Possible Duplicates

收到接收方的ResendRequest, 或怀疑没发出(如进程重启时的msg), 设置PossDupFlag=Y, 使用原来的seq, 重新计算CheckSum将msg重新发送一次
2）Possible Resend

订单很久没响应时, 会怀疑这个单没发出去, 就会考虑重新下一单. 设置msg的PossResendFlag=Y, 使用新的seq, 但是OrderId不变, 重新下单。接收方需要识别PossResendFlag, 并通过OrderId准备识别出这个Order是不是之前已经收到过, 并正确处理。

PossResend 和 PossDupFlag 区别就是前者使用了新序列号发送老的消息，可以通过检查消息中的域来确定是否已经收到过该消息，比如 order 的 ID 等；后者是用老的序列号重发消息，可以直接检查序列号来确定是否已经收到过该消息，若已收到过了就丢弃该消息。

七、其它协议（了解）

FAST协议

为了解决FIX协议传输市场数据存在的冗余度高，带宽需求大的问题，芝加哥商品交易所（CME）在2003年向FPL（FIX Protocol Ltd）提交了一个解决方案，FPL在2004年成立了市场数据优化工做组(MDOWG)，2005年MDOWG开始根据一些POC(Prove of Concept)的结果进行协议标准制定，并于2006年初完成了FAST(FIX Adapted for Streaming) V1.0，2006年12月完成了FAST V1.1。
FAST协议核心是一个压缩算法，将按照FIX规范定义的数据通过压缩后，能够在很大程度上下降发送、接收双方的带宽。
FAST协议的优势是高压缩比，低资源消耗，算法简单高效，每秒百万级别的消息处理能力。

STEP协议

STEP（Securities trading exchange protocol，证券交易数据交换协议）是基于FIX4.4版本FIX协议制定出来的中国本地化FIX协议版本，是中国国家金融行业标准，已成为事实上的证券数据标准，其语法简单定义灵活易扩展，数据相对冗余。

Binary协议

Binary即二进制协议，定义了各类报文的字段、编解码规则等。在深交所的Binary协议中，全部的消息都有3部分组成：消息头，消息体和消息尾。消息头有8个字节，包括整数MsgType和整数BodyLen，MsgType表示消息的类型，BodyLen表示消息体的长度；消息体根据BodyLen大小进行读取；消息尾是4个字节的 checksum。