STEP协议 Securities Trading ExchangeProtocol 证券交易交换协议
STEP协议是什么？
STEP: Securities Trading ExchangeProtocol，是中国金融行业数据通信标准JR/T0022-2004，目前被深圳交易所采用，作为LeveII数据向信息服务商分发的数据的标准协议。本文讨论的内容是基于STEP 1.0.0。
示意图
在该参考实例中证券交易数据交换协议用于市场参与者内部系统与市场参与者协议转换系统间的连接、交易所交易系统与采用STEP开放接口的市场参与者系统间的连接，同时也支持外部交易所接口系统与外部交易所的连接。
STEP协议介绍
协议，对开发同学都不陌生，在进行系统设计时，都需要定义一套技术层和业务层的通讯协议。特别对于做交易系统这种低延时要求极高的系统设计，设计一套规范标准的通讯协议设计十分关键。
今天我们简单说下：沪深交易所的STEP协议、期货交易所FTD协议、外汇交易中心（银行间）IMIX协议。
FIX（Financial Information eXchange）协议即金融信息交换协议，是用于全球金融市场机构和参与者间的电子金融信息交互的协议，以下简称FIX协议。
在FIX标准化组织(FIX Trading Community)提出的FIX 5.0标准中，单独定义有一个会话层协议（FIX Session Protocol，FIXT），其版本是FIXT 1.1。
JR/T 0022-2014《证券交易数据交换协议》 （Securities Trading Exchange Protocol，简称STEP)是FIX协议的行业标准。本标准是对FIXT 1.1及JR/T 0022-2014中会话层协议的轻量化。此标准规定了轻量级实时STEP消息传输协议（Light-weight realtime STEP message transfer protocol）使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式规范、数据字典等内容。 此标准适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。本标准也可被推广用于支持证券期货行业各机构系统间的会话连接。
名词释义
会话层重传：是标准FIX会话层协议所规定的一种重传机制，用来确保有序、无失地传输每一条会话层消息。在标准FIX会话层协议中，会话层重传由消息接收方在识别出消息序号缺口之际主动发起，采取的方式是发送一条消息重传请求给到对方。（PS：由于单个LFIXT会话使用单个TCP连接作为底层通信机制，因此在单个TCP连接内部，每一条消息将被有序、无失地传输。属于同一会话的、前后相继的若干次TCP连接之间，将可能存在会话层消息丢失，但收到的会话层消息将仍然具有有序接收的性质。由于在LFIXT下会话层可能存在消息丢失，因此丢失的业务消息将只能通过应用层重传予以恢复。）
应用层重传：由于LFIXT会话协议的会话层恢复机制仅仅是为了与标准FIX会话协议兼容，不能作为真正的消息恢复机制使用。因此，必须通过应用层商定的重传机制予以恢复。
NxtIn 和 NxtOut：会话双方收发的每条消息都带有一个消息序号。参与通信的每一端都需要维护一对序号（NxtIn，NxtOut），NxtIn表示下一个期望的入向消息序号，NxtOut表示下一条出向消息将被赋予的序号。
会话发起方和接受方：会话的建立需要一个发起方，需要一个接受方。发起方是先发出Logon消息并希望对方响应以一个Logon消息的一方，接受方则是等待发起方首先发出Logon消息并响应以Logon消息的一方。
消息序号：所有的消息都由一个唯一的会话层消息序号(即消息头中的MsgSeqNum字段)进行标识。消息序号在会话开始时一般被初始化为1，并在整个会话过程中连续递增，直到该会话过程全部结束。通过监视消息序号的连续性，通信双方可以识别消息缺口并做出反应，并可在同一会话的前后多个连接间进行同步。每次会话都会创建一套独立的入向及出向的序号序列，参与连接的任何一方都维护一套用于出向消息的序号序列(NxtOut)，同时也维护另一套独立的入向消息的序号序列(NxtIn)，用以监视接收的消息序号，以保证消息缺口的发现和处理。会话建立后，当LFIXT协议实现者接收到的消息序号不等于预期接收的消息序号(NxtIn)时，需要考虑进行修正处理。这里有几种情况：
在下述情况下，接收方收到的消息的MsgSeqNum也可能出现倒流：
- 收到的消息是SeqReset-Reset消息且PossDupFlag=Y，此时MsgSeqNum应忽略，即使出现倒流也不是错误；
- 除此以外，所收到消息的PossDupFlag是Y，且此类消息确实允许出现PossDupFlag=Y，表示这是会话层重传；
- 通过LOGON消息进行会话序号重置时，收到的消息其MsgSeqNum一定是1，因此也可能出现倒流。
- 如果入向消息序号< NxtIn，且不属于上述情况之一时：表明发生了严重的错误，必须立即结束会话，并开始进行人工干预。
- 如果入向消息序号< NxtIn，且属于上述情况之一，不属于错误，应进行正常处理。
- 如果入向消息序号> NxtIn，那么表明有消息被遗漏。因为LFIXT使用TCP为传输协议，出现这种情况说明发生了严重异常错误，应立刻终止当前会话。
心跳：在消息交换的空闲期间，连接双方将以规定的时间间隔产生心跳消息。通过心跳消息可以监控通讯连接的状态并识别出入向消息序号的缺口。心跳间隔时间由会话发起人通过登录消息的HeartBtInt字段确定。在传送了任何消息(而不仅仅是心跳消息)之后，都应立即重置心跳间隔计时器。心跳间隔时间应该得到连接双方的确认，由会话发起人给出，并得到会话接受方的确认。连接双方应使用相同的心跳间隔时间。每个心跳消息都将占用一个MsgSeqNum消息序号。
有序消息处理：LFIXT会话协议采用TCP连接作为底层通信机制，会话建立后，在同一个TCP连接的延续期间，接收方在发现入向消息缺口时，说明发生了严重异常，建议接收方终止该会话并断开TCP连接。如果接收方为会话的发起方，则应根据需要重建会话。
可能的消息重复传送：本会话协议采用TCP连接作为底层通信机制，会话双方在建立TCP连接之后，通过Logon消息进行序号协商，其后则是基于TCP进行的连续通信，正常情况下，不应该出现前面消息丢失却收到后面消息的情形。
可能的消息重新发送：在LFIXT会话协议中，应用层重发的标志应在应用层协议中明确设置，而不应该体现在会话层消息的标志位上。由于互操作的对方必须遵从同样的应用层协议，因此LFIXT会话协议将不会给出向消息打上任何Possible Resend标志。LFIXT会话协议允许在入向消息头中出现Possible Resend标志，但将忽略该标志，直接将不附带该标志的消息交由应用层处理。
消息完整性：消息数据内容的完整性可以用两种方式来验证：验证消息长度，及字符的简单校验和。消息长度被包括在BodyLength字段中，可以通过清点消息之中跟在BodyLength字段之后、直至并包括直接先于CheckSum域号（”10=”）出现的那个域界定符
混乱的消息(garbled message)：根据标准FIXT协议的附录，当至少出现以下情形之一时，一条消息被称为“混乱的”：BeginString(tag 8) 不是消息的第一个标签，或不以 8=FIXT.n.m 的形式出现。BodyLength(tag 9)不是消息的第二个标签，或未包含正确的字节计数MsgType(tag 35) 不是消息的第三个标签CheckSum(tag 10)不是最后的标签，或其取值不正确。若MsgSeqNum(tag 34)缺失，必须立刻终止FIX连接，因为这表明出现了严重的应用错误，很可能只能通过修改软件来绕过。
消息确认：由于会话层协议是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确认。但大量消息收发的确认可在应用层定义。在应用层接受和拒绝是允许的。
加密：LFIXT 会话层不对数据进行加密处理，会话双方可考虑使用通信层的加密机制。
