随着网络的使用，目前所有大型的金融机构都已经实现了自动化和数字化。当中肯定少不了互联网的加入，那么在这当中，我们主要介绍一下FIX协议。它是由国际FIX协会组织提供的一个开放式协议，目的是推动国际贸易电子化的进程，在各类参与者之间，包括投资经理、经纪人，买方、卖方建立起实时的电子化通讯协议。Fix协议的目标是把各类证券金融业务需求流程格式化，使之成为一个个可用计算机语言描述的功能流程，并在每个业务功能接口上统一交换格式，方便各个功能模块的连接。
FIX协议结构
当前,FIX协议的格式存在着两种结构:"标记〉=〈值"域结构和 FIXML 结构。下面针对域结构模式对FIX协议的组成，连接建立、信息交换方法等进行简要说明，以便于了解FIX协议的概念。
FIX信息格式
信息格式
一条FIX协议信息的基本格式是：
《标准头》 《信息正文域》 《标准尾》
每条信息都是由一系列带有〈标记〉=〈值〉的域组成的。在每个域之间通过"< >"分开。除了一些特殊规定外，信息中的域可按照任意顺序排列。所有域在都以"定界符"表示终止。
标准的信息标题
每条命令或应用信息都有一个标准的标题。标题表明了信息类型、长席、目的地、序号、起始点和时间。
标准的信息尾部
所有的信息，无论是命令类的，还是应用类的，以一个标准结尾终止。尾部被用来把信息分离，并包括含有3位数的"检验和"值。
数据类型
各域所使用的数据类型包括以下几种：整数、浮点数、布尔数、字符串、多元值串、货币、交易所字符串域、国际标准时时间戳、国际标准时时间、本地市场日期等。
数据完整性
信息数据内容是否完整可以通过"检查信息长度"和字符的简单"检验和"两个方法进行检查。
加密
为了保证信息安全，对传递的信息需要加密，加密方法的选择由传送中的有关双方协议而定。任何域都可被加密并被添加于"密码"的域内，不过，被确信可被清楚识别的域必须以非加密方式进行传送，这些公开的域能在密码的域内被重复以完整地检验公开的数据。
FIX协议的连接建立
建立一个FIX连接包括：电信层面连接的创立、经由接收方对发起方的确认、信息同步三个步骤。
FIX信息交换过程的实施
FIX信息交换过程的定义为：
在两方之间，一个连续的序号系列范围内的双向定单信息传送。每条信息都有独特的序号识别。在每次FIX交换过程开始时，就是序号的开始，首先从1开始，并依次增加直至贯穿整个交换过程。当在FIX交换过程中重新进行连接的时候，监控序号将能使各方能识别错过的信息，并能做出反应，来使应用方达到一致地同步。
在整个信息没有被激活的时期里，信息交换方将在有规则的时间间隔里产生"心跳信息"。通过"心跳信息"可监控通信连接的状况，识别进入的序号缺口，并确认是否接收到最后的信息串。"心跳间隔"是由交换过程发起人使用"心跳指令"域在"登录"信息中宣布的。
当信息交换连接的任何一方在"心跳指令"的时间内都不发送任何数据的时候,"心跳信息"将被传送。当连接的任何一方在"心跳指令" "合理的传输时间"的时间内仍没有收到"心跳信息"，那么，可以认为此次连接失败，而且需开始实施修正操作。如果"心跳指令"被设置为零，将不会生成定期的"心跳信息"。
FIX的连接注销
信息交换过程的正常结束是通过双方互相发送"注销"信息来完成。"注销"信息是开始或确认一个FIX过程终止的信息，未经"注销"信息的交换而断开的连接是反常情况，并应按错误来处理。
FIX通信协议的应用
针对国内的证券交易模式的分布式结构，即证券公司的各营业部、分支机构数据分布存放，各自独立，直接与交易所联系，国内券商正在探讨并逐步推出集中交易系统,集中交易系统可以带来集中风险控制、提高系统效率等优势，可以在集中交易系统的构建、规划过程中，借鉴应用FIX标准化协议，构建具有数据层、核心业务层 FIX通信层、应用层的广义三层结构。用FIX金融信息交换协议包取代过去的文件或通信包交换的模式。
在FIX协议的应用过程中应该注意到，由于亚洲地区的证券交易方式与FIX协议的主导地区美洲和欧洲国家有一定的差异，因此直接利用现有的FIX协议，特别是证券业务流程上的规范有一定的困难。
例如FIX协议在日本证券行业的应用就遇到了信息定义内容和信息流程顺序上的问题。因此国内的FIX的开展首先要关注FIX及其在中国的适用性，吸收其它市场的经验，将国内外不同的交易程序加以比较，分析协议的使用方法以及协议使用环境，结合国内证券市场的实际，使得该项协议既能成为一项标准又能为中国证券市场服务，为中国证券交易的标准化过程中发挥作用。
1 简介FIX会话协议与选择用于电子数据传递的物理介质及传输协议规范无关。它提供了一个消息传递的可靠数据流。直到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会话协议的标准头，标准尾部和管理消息是基于“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。加密相关域也必须被重新构造。3.5 Possible Resends 可能的重传模糊的应用层消息可能随同PossResend标志被重传。当一个指令没有在规定时间长度内进行确认或者终端用户挂起该指令没有进行传送时这种方法非常有用。接收程序必须识别此标志，并质疑其内部域以确定该指令是否在之前已经被接收过。注意，可能的重传消息将包含与原始消息相同的数据体，但包含PossResend标志和一个新的序列号。此外，CheckSum和与加密相关的域值需要重构。3.6 Data Integrity 数据完整性消息数据内容的完整性可以参用两种方式来验证：消息长度和效验码检查。程序通过计算BodyLength域到在CheckSum标记后的分界符的字符数与在BodyLength中标示的消息长度进行比较来完成完整性效验。ChekSum完整性检查，通过计算从域“8=” 中“8”开始，包括紧跟在CheckSum标记域的分界符
每个字符的2进制和同CheckSum进行比较得到。3.7 Message Acknowledgment 消息确认FIX会话协议基于一个优化模型。普通的数据传送被假设为通过消息序列间隙进行错误识别。每个消息由一个唯一的序列号进行标示。接收端应用程序负责监控接收消息序列号以识别消息间隙并产生重传请求。FIX协议不支持单个消息的确认。然而，多数应用消息需要显示地应用层接收和拒绝。3.8 Encryption 加密敏感数据在公众网络上的传输建议采用数据加密技术来掩饰应用消息。加密算法由连接双方共同协商。一个消息的任何一个域可以被加密并放在SecureData域中。然而，一些显示的标志域必须采用明文进行传输。为确保完整性，明文域可以在SecureData域中重复。当使用加密时，建议但不是必须，所有的消息体都进行加密。如果一个消息中的重复组数据中的部分数据要加密，这个重复组必须全部进行加密。预先协商好的加密算法在Logon消息中进行声明。4 SESSION PROTOCOL会话协议一个FIX会话定义为一个在连接双方间的的带有连续序列号的有序消息双向传输流。 单个FIX会话能够跨越多个连续的物理连接。在一个维持的，单独的FIX会话中，参与方能够多次连接和断开连接。连接的参与方必须根据单个系统及时间区域需求，公共协商会话的开始和结束。无论什么原因，重新设置接收和发送序列号为1，意味着一个新的FIX会话的开始。建议一个新的FIX会话在每24小时期间建立一次。可以维持24小时的连接和通过设置在Logon消息中的ResetSeqNumFlag建立一套新的序列号。FIX会话协议基于一个优化模型。普通的数据传送被假设为通过消息序列间隙进行错误识别。这个部分详细介绍了FIX会话层和消息序列间隙的实现。以下术语将在这部分使用：Valid FIX Message有效FIX消息 是按照协议正确生成，包含有效消息体长度和效验域的消息。Initiator发起者 建立通信连路，通过发送初始Logon消息发起会话的参与方。Acceptor接收方 FIX会话的接收方。负责执行第一层次的认证和通过传输Logon消息的确认正式声明连接请求被接受。FIX ConnectionFIX连接 由3部分组成：logon登录，message exchange消息传输，和logout注销。FIX SessionFIX 会话 由一个或多个FIX Connection FIX连接组成。意思是一个FIX会话可以有多次登录。4.14.1 Logon 登录建立一个FIX连接，分别包含3个操作：创建通信层链路，接收者认证/接受发起者和消息同步。连接流程如下：l会话发起者同会话接收者建立通信链路。l发起者发送一个Logon消息。接收者检查Logon消息，认证发起者身份。Logon消息包含支持之前双方协商好的认证方法所必须的数据。如果发起者被成功认证，接收者用一个Logon消息进行响应。如果认证失败，会话接收者将关闭链接，之前可以选择发送一个Logout消息以提示认证失败的原因。这个Logout消息不时必须发送的，如果这样做将会占用该会话的一个序列号，在某些情况下会有问题，如：在会话期进行多次Logon时。发起者可以在Logon消息后紧接着开始发送消息。然而，接收者可能没有准备好接收它们。发起者必须等待接收者发送的Logon确认消息才能认为完全建立回话。在发起者认证通过之后，接收者立即响应一个Logon确认消息。依据会话使用的加密方法，这个Logon消息可以，也可以不报还同样的会话密钥。发起者方将把接收方反悔的Logon确认消息视为一个FIX会话建立的标志。如果会话接收方选择干边会话加密密钥，会话的发起方必须发送一个Logon消息到对方以确认密钥改变请求。这样，能让会话接收者知道发起者何时开始使用新的会话密钥。双方有责任诊断和避免在此阶段出现无限循环。l认证完成之后，发起方和接收方必须在发送任何查询或新消息之前通过询问MsgSeqNum域来同步其消息。将Logon消息中的MsgSeqNum同内部监控的下一个希望的序列号进行比较可以指示任何的消息间隙。此外，发起方能通过比较确认Logon消息的MsgSeqNum及下一个期望值来侦测消息的间隙。后面的消息恢复部分文当将介绍如何进行消息间隙的处理。l推荐引擎应当在一个临时的队列中存储发送消息系列，在消息间隙关闭时处理它们。这样可以阻止对n->m，n->m 1，n->m 2，…的重发请求，这些请求能导致许多PossDupFlag=’Y’的消息。l当使用ResetSeqNumFlag来维持24小时连接和建立一套新的序列号时，应该按照下面的方式进行处理。双方应当协商一个复位时间以及此过程的发起方。注意，ResetSeqNum过程的发起方可以与Logon过程的发起方不是同一个。一方通过发送一个TestRequest初始化此过程，并等待一个Heartbeat的响应以确认没有序列号间隙。一旦收到Hearbeat，发起者应当发送一个带有ResetSeqNumFlag值为‘Y’和MsgSeqNum为1的Logon消息。接收方应当发送一个带有ResetSeqNumFlag值为‘Y’和MsgSeqNum为1的Logon消息作为响应。此时，任何一方发送的新的消息可以从MsgSeqNum编号为2开始计数。应当注意，一旦发起方发送设置了ResetSeqNumFlag的Logon消息，接收者必须遵守这个请求，并且作为最后一个序列号发送的消息的“yesterday”值不再可用。如果此过程的初始化未被正确执行，链接应当被关闭，手动关闭方式将会被介入。4.2 Message exchange 消息交换初始化过程之后，正常德的消息交换将开始。所有有效的消息格式的细节将在“Adminitrative Message ”管理消息和“Application Messages”应用消息部分介绍。4.3 Logout正常的消息交换的终止将通过交换Logout消息来完成。换句话说，通信的终止应被看作异常并作为一个错误进行处理。没有接收到Logout消息的会话终止应当作参与方的注销。推荐发送一个TestRequest消息强制请求从对方获取Heartbeat。这样可以帮助判断没有序列间隙。在实际的会话关闭前，Logout的发起者应等待对方响应一个Logout确认消息。这种方式给接收者在需要时一个执行任何间隙填充错作的机会。一旦ResendRequest消息被接收，接收者应发起Logout操作。会话可以终止，如果接收者在适当的时间表内没有响应。注意：注销不会影响任何指令的状态。左右活动的指令将继续有机会在注销后被执行。4.4 Message Recovery 消息恢复在FIX会话初始化过程及会话过程中，通过跟踪接收序列号，消息间隙的出现将会被侦测到。以下部分介绍了如何恢复消息。如前所述，每个FIX参与方必须为FIX会话维护两个序列号，一个是接收序列号，一个是发送序列号，两者都在建立FIX会话开始时初始化为1。每个消息被赋予一个唯一的序列号值，并在消息发送后递增。此外，每个收到的消息都有一个唯一的序列号，接收序列号计数器在收到每个消息后将会被递增。当接收序列号与所希望得到的的正确序列号不必配时，必须采取纠错处理。注意，SeqReset-Reset消息对于这个规则来说是个例外，它应当被处理，而不用考虑其MsgSeqNum值。如果接收消息的序列号小于期望接收的序列号，并且PossDupFlag值未被设置，这表示出现一个严重错误。强烈推荐终止会话，启用手动干预。如果接收消息的序列号大于期望值，这表明有丢失消息，并通过Resend Request 重传请求这些消息的重新传输。注意：后续的请求者指为请求发送方；重传者指请求的响应方。消息重传和消息同步叫做“间隙填充”。再收到重传请求的情况下，重传者可以用三种方式之一进行响应：1、按照原先序列号，顺序重新传输请求消息，并将PossDupFlag设置成‘Y’。2、发出一个SeqReset-GapFill和一个PossDupFlag值为‘Y’的消息代替管理和应用消息的重传。3、发出一个SeqReset-GapFill和一个PossDupFlag值为‘Y’的消息强制进行序列号的同步。通常情况下使用1，2的组合。而3则仅用于从灾难中，且不能通过间隙填充模式进行数据恢复的场景。在间隙填充过程中，一些管理消息应不被重传。取而代之的是一个特殊的SeqReset-GapFill消息将被产生。不能被重传的消息有：Logon，Logout，ResendRequest，Heartbeat，TestRequest和SeqReset-Reset，SeqRest-GapFill。所有的FIX协议的实现，都必须监控接收消息以侦测管理消息的重传。当接收到这些消息时，应当仅对序列号完整性进行处理，而商业/应用消息应被跳过。如果有连续的管理消息需要重发，推荐只发送一个SeqRest-GagFill消息。SeqRest-GapFill消息的序列号为下一个希望发送的序列号。GapFill消息的NewSeqNo域包含了这些管理消息中的最高序列号值加上1。如，在一个重传错作中，有7个顺序的管理消息等待重发。它们的序列号从9到15。替代7个间隙填充消息，一个SeqReset-GapFill消息将会被发送。此间隙填充消息的序列号被设置为9，因为远端把序列号9作为下一个期望接收的消息。GapFill消息的NewSeqNo的值为16，表示下一个发送消息的序列号。序列号检查是FIX会话管理最重要的部分。然而，一些FIX消息的序列号处理存在一些不同，下表列出了接收序列号比期望接收序列号大时的处理方法。注意：除了Reset消息外的所有情况，如果接收序列号小于期望接收序列号，且PossDupFlag未被设置，FIX会话应被终止。在关闭会话前，一个Logout消息和一些描述性文本应被发送给对端。消息类型
