金融信息交换协议（FIX）5.0 FIXT1.1（1）

本博客所有的fix相关内容都是分享来自Songzhang的博客，本人转载这里目的是自身学习，若 有人看到，建议去看其Songzhang的原创作品，谢谢。

1 简介

FIX会话协议与选择用于电子数据传递的物理介质（铜缆，光纤，卫星传输等）及传输协议规范（X.25，同步，TCP/IP等）无关。它提供了一个消息传递的可靠数据流。直到2006年10月，FIX会话协议与FIX应用协议一道，为用户提供了一个可靠的传输FIX应用消息的传输机制。

FIX会话层与数据传输相关，而FIX应用层则定义了商业相关的数据内容。

2006年10月，FPL’s Global Techenical Committee 引入了一个新的框架，将FIX会话层协议从FIX应用层协议分离开来。这就使应用协议消息可以使用任何适的会话传输技术进行传送，而FIX会话层协议是这些可选的协议中的一个。在新的框架下，GTC引入了一个新的别名，之后FIX会话层协议版本为FIXT.x.y，第一个版本为FIXT1.1。

2 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数据。

3 FIX消息传送

3.1 Sequence Numbers 序列编号

所有的FIX消息都由一个唯一的序列号进行标示。序列号在每一个FIX会话开始时被初始化为1，并在整个会话期间递增。监控序列号可以使会话参与者识别和处理丢失的消息，当在一个FIX会话中重新连接时能够优雅地进行应用程序同步。

每个会话将建立一组互不依赖的接受和发送序列。会话参与者将维护一个赋予发送消息的序列和一个监控接受消息的消息块间隙序列号。

3.2 Heartbeats 心跳信号

在消息交互期间，FIX应用程序将周期性产生Heartbeat心跳消息。该心跳消息可以监控通信链路状态及识别接受序列号间隙。发送Heartbeat的周期间隔由会话发起者使用在Logon消息中HeartBtInt域进行定义。Heartbeat心跳消息的时间间隔应当在每一个消息发送后复位，即发送一个消息后，在间隔给定的时间内无其它消息发送则发送一个Heartbeat心跳消息。HeartBtInt的值应当被会话双方认同，由会话发起方定义并由会话接收者通过Logon消息进行确认。同一个HeartBtInt被会话双方——登录的发起者和登录的接受者共同使用。

3.3 Ordered Message Processing 消息序列处理

FIX协议假设消息在所有参与者间完全按照顺序进行传输。协议的实现者在设计消息间隙填充处理时应当考虑这个假设。有两种方式处理消息间隙。每一个都要求所有的消息时最后一个接收消息的后续消息或在维护一个所有新消息有序序列时，请求特定丢失消息。比如：接收方丢失了5个消息块中的第二个，程序能忽略第3到第5个消息，产生一个对消息2到消息5的重传请求，或者从消息2到无穷大消息编号的重传请求。另外的方式是暂时存储消息3到消息5，仅要求重传消息2。对于这两种方式，消息3到消息5都不应该先于消息2进行处理。

3.4 Possible Duplicates 可能的复制

当一个FIX引擎对一个消息是否成功地被指定的目标接收或者当对一个重传请求进行响应时，将会产生一个可能的消息复制。这个消息将用同样的序列进行重新传送，此时在头部的PossDupFlag域将会被设置为‘Y’。接收端程序负责处理该重发消息，可以作为一个新消息进行处理，或者根据实际情况忽略该消息。所有重传请求的响应消息都将包含其值为‘Y’的PossDupFlag域。没有PossDupFlag域或者PossDupFlag域为‘N’的消息应被当作初始传送消息。注意，一个PossDupFlag值为‘Y’的重传消息需要重新计算其CheckSum值。一个可能的复制消息里发生变化的域包括：CheckSum，OrigSendingTime，SendingTime，BodyLength和PossDupFlag。加密相关域（SecureDataLen和SecureData）也必须被重新构造。

3.5 Possible Resends 可能的重传

模糊的应用层消息可能随同PossResend标志被重传。当一个指令没有在规定时间长度内进行确认或者终端用户挂起该指令没有进行传送时这种方法非常有用。接收程序必须识别此标志，并质疑其内部域以确定该指令是否在之前已经被接收过。注意，可能的重传消息将包含与原始消息相同的数据体，但包含PossResend标志和一个新的序列号。此外，CheckSum和与加密相关的域值需要重构。

3.6 Data Integrity 数据完整性

消息数据内容的完整性可以参用两种方式来验证：消息长度和效验码检查。

程序通过计算BodyLength域到（并包含）在CheckSum标记 （“ 10= ”）后的分界符的字符数与在BodyLength中标示的消息长度进行比较来完成完整性效验。

ChekSum完整性检查，通过计算从域“8=” 中“8”开始，包括紧跟在CheckSum标记域的分界符<SOH>每个字符的2进制和同CheckSum进行比较得到。

3.7 Message Acknowledgment 消息确认

FIX会话协议基于一个优化模型。普通的数据传送（无单个消息确认）被假设为通过消息序列间隙进行错误识别。每个消息由一个唯一的序列号进行标示。接收端应用程序负责监控接收消息序列号以识别消息间隙并产生重传请求。

FIX协议不支持单个消息的确认。然而，多数应用消息需要显示地应用层接收和拒绝。

3.8 Encryption 加密

敏感数据在公众网络上的传输建议采用数据加密技术来掩饰应用消息。

加密算法由连接双方共同协商。

一个消息的任何一个域可以被加密并放在SecureData域中。然而，一些显示的标志域必须采用明文进行传输。为确保完整性，明文域可以在SecureData域中重复。

当使用加密时，建议但不是必须，所有的消息体都进行加密。如果一个消息中的重复组数据中的部分数据要加密，这个重复组必须全部进行加密。

预先协商好的加密算法在Logon消息中进行声明。