JR/T 0182-2020
基本信息
标准号： JR/T 0182-2020
中文名称：轻量级实时STEP消息传输协议
标准类别：金融行业标准(JR)
英文名称：Light weight realtime STEP message transfer protocol
标准状态：现行
发布日期：2020-02-26
实施日期：2020-02-26
出版语种：简体中文
下载格式：.zip .pdf
下载大小：768170
标准分类号
标准ICS号： 社会学、 服务、公司(企业)的组织和管理、行政、运输>>03.060金融、银行、货币体系、保险
中标分类号：综合>>经济、文化>>A11金融、保险
关联标准
出版信息
出版社：中国标准出版社
标准价格：0.0
相关单位信息
起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东
起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信息技术服务有限责任公司
归口单位：全国金融标准化技术委员会（SAC/TC180）
提出单位：全国金融标准化技术委员会证券分技术委员会（SAC/TC180/SC4）
发布部门：中国证券监督管理委员会
主管部门：中国证券监督管理委员会
标准简介
标准号：JR/T 0182-2020
标准名称：轻量级实时STEP消息传输协议
英文名称：Light weight realtime STEP message transfer protocol
标准格式：PDF
发布时间：2020-02-26
实施时间：2020-02-26
标准大小：489K
标准介绍：本标准规定了轻量级实时STEP消息传输协议( Light- weight realtime STEP message transfer protocol)使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式规范、数据字典等内容。
本标准JR/T 0182-2020适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。
本标准也可被推广用于支持证券期货行业各机构系统间的会话连接。
本标准依据GB/T1.1-2009给出的规则起草
本标准由全国金融标准化技术委员会证券分技术委员会(SAC/TC180/SC4)提出
本标准由全国金融标准化技术委员会(SAC/TC180)归口本标准起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信息技术服务有限责任公司
本标准主要起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东
本 标 准 规 定 了 轻 量 级 实 时 STEP 消 息 传 输 协 议 （ Light-weight realtime STEP message transfer protocol）使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式规范、数据字典等内容。 本标准适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。本标准也可被推广用于支持证券期货行业各机构系统间的会话连接。
本标准依据GB/T 1.1—2009给出的规则起草。
本标准由全国金融标准化技术委员会证券分技术委员会（SAC/TC180/SC4）提出。
本标准由全国金融标准化技术委员会（SAC/TC180）归口。
本标准起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信息技术服务有限责任公司。
本标准主要起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东。
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
JR/T 0022—2014 证券交易数据交换协议
ISO 10383:2012 证券及相关金融工具 交易所和市场识别码（Securities and related financial instruments-Codes for exchanges and market identification(MIC)）
Financial information exchange protocol(FIX) Version 5.0 Service Pack 2,August 2011
Financial information exchange protocol(FIX) FIX session protocol version1.1,March 2008
前言 II
引言 III
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 会话机制 1
41 关键概念的重要说明1
42 会话管理 5
43 恢复 6
5 消息规范 6
51 消息结构 7
52 管理消息 8
6 数据字典 14
61 数据类型 14
62 会话层域规范15
附录 A （规范性附录）计算校验和17
附录 B （规范性附录）处理心跳和测试请求18
附录 C （规范性附录）登录场景19
C1 正常登录场景一19
C2 正常登录场景二20
C3 正常登录场景三20
C4 异常登录场景一22
C5 异常登录场景二22
附录 D （规范性附录）处理会话拒绝24
附录 E （规范性附录）处理重传请求场景25
E1 处理重传请求场景一25
E2 处理重传请求场景二26
附录 F （规范性附录）注销场景27
标准名称：轻量级实时STEP消息传输协议
英文名称：Light weight realtime STEP message transfer protocol
标准格式：PDF
发布时间：2020-02-26
实施时间：2020-02-26
标准大小：489K
标准介绍：本标准规定了轻量级实时STEP消息传输协议( Light- weight realtime STEP message transfer protocol)使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式规范、数据字典等内容。
本标准JR/T 0182-2020适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。
本标准也可被推广用于支持证券期货行业各机构系统间的会话连接。
本标准依据GB/T1.1-2009给出的规则起草
本标准由全国金融标准化技术委员会证券分技术委员会(SAC/TC180/SC4)提出
本标准由全国金融标准化技术委员会(SAC/TC180)归口本标准起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信息技术服务有限责任公司
本标准主要起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东
本 标 准 规 定 了 轻 量 级 实 时 STEP 消 息 传 输 协 议 （ Light-weight realtime STEP message transfer protocol）使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式规范、数据字典等内容。 本标准适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。本标准也可被推广用于支持证券期货行业各机构系统间的会话连接。
本标准依据GB/T 1.1—2009给出的规则起草。
本标准由全国金融标准化技术委员会证券分技术委员会（SAC/TC180/SC4）提出。
本标准由全国金融标准化技术委员会（SAC/TC180）归口。
本标准起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信息技术服务有限责任公司。
本标准主要起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东。
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
JR/T 0022—2014 证券交易数据交换协议
ISO 10383:2012 证券及相关金融工具 交易所和市场识别码（Securities and related financial instruments-Codes for exchanges and market identification(MIC)）
Financial information exchange protocol(FIX) Version 5.0 Service Pack 2,August 2011
Financial information exchange protocol(FIX) FIX session protocol version1.1,March 2008
前言 II
引言 III
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 会话机制 1
41 关键概念的重要说明1
42 会话管理 5
43 恢复 6
5 消息规范 6
51 消息结构 7
52 管理消息 8
6 数据字典 14
61 数据类型 14
62 会话层域规范15
附录 A （规范性附录）计算校验和17
附录 B （规范性附录）处理心跳和测试请求18
附录 C （规范性附录）登录场景19
C1 正常登录场景一19
C2 正常登录场景二20
C3 正常登录场景三20
C4 异常登录场景一22
C5 异常登录场景二22
附录 D （规范性附录）处理会话拒绝24
附录 E （规范性附录）处理重传请求场景25
E1 处理重传请求场景一25
E2 处理重传请求场景二26
附录 F （规范性附录）注销场景27
标准图片预览
标准内容
ICS03.060
iiiKAa~cJouakAa
中华人民共和国金融行业标准
JR/T0182—2020
轻量级实时STEP消息传输协议
Light weight realtime STEP message transfer protoco2020-02-26发布
中国证券监督管理委员会
2020-02-26实施
iiiKAa~cJouaKAa
引言，
规范性引用文件
3术语和定义
4会话机制
iiikAacJouakAa-
关键概念的重要说明
会话管理、
5消息规范
消息结构.
管理消息
6数据字典
附录A
附录B
附录C
附录D
附录E
附录F
数据类型此内容来自标准下载网
会话层域规范.
（规范性附录）计算校验和
（规范性附录）处理心跳和测试请求.（规范性附录）登录场景
正常登录场景
正常登录场景
正常登录场景
异常登录场景
异常登录场景工
（规范性附录）处理会话拒绝
（规范性附录）处理重传请求场景处理重传请求场景
处理重传请求场景
（规范性附录）注销场景
JR/T0182—2020
JR/T0182—2020
iiiKAa~cJouakAa
本标准依据GB/T1.1一2009给出的规则起草。本标准由全国金融标准化技术委员会证券分技术委员会（SAC/TC180/SC4）提出本标准由全国金融标准化技术委员会（SAC/TC180）归口。本标准起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信息技术服务有限责任公司。
本标准主要起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东。11
iiiKAa~cJouakAa
JR/T0182—2020
FIX（FinancialInformationeXchange）协议即金融信息交换协议，是用于全球金融市场机构和参与者间的电子金融信息交互的协议，以下简称FIX协议。在FIX标准化组织（FIXTradingCommunity）提出的FIX5.0标准中，单独定义有一个会话层协议（FIXSessionProtocol，FIXT），其版本是FIXT1.1。JR/T0022-2014《证券交易数据交换协议》（SecuritiesTradingExchangeProtocol，简称STEP）是FIX协议的行业标准。本标准是对FIXT1.1及JR/T0022-2014中会话层协议的轻量化。iiiKAa~cJouaKAa
1范围
iiiKAa~cJouaKAa-
轻量级实时STEP消息传输协议
JR/T0182—2020
本标准规定了轻量级实时STEP消息传输协议（Light-weightrealtimeSTEPmessage
transfer
protocol）使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式规范、数据字典等内容。
本标准适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。本标准也可被推广用于支持证券期货行业各机构系统间的会话连接。规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。JR/T0022—2014
IS010383:2012
financial
证券交易数据交换协议
证券及相关金融工具
交易所和市场识别码（Securitiesandrelated
instruments-Codesfor exchanges and market identification(Mic))Financial
August2011
Financial
March2008
3术语和定义
information
information
exchange
protocol(FIx)
Version
5.0Service
exchangeprotocol(FIx)FIX
下列术语和定义适用于文件。
证券交易数据交换协议
session protocol
versionl.1
securtieatradingexchangeprotocol;STEp证券交易所交易系统与市场参与者系纤之间进行证券交易数据交换的行业信息标准。3.2
金融信息交换协议
financialinformationexehangeFix进行证券交易信息电子交换的国际信息标准。3.3
FIX会话层协议
fix sessionlayerprotocol;FixT独立于通信协议（如TCP、UDP等）和通信介质（如光缆、卫星等）的电子数据佳精协议，FIX协议的重要子协议。
4会话机制
4.1关键概念的重要说明
JR/T0182—2020
4.1.1会话层重传
iiiKAa~cJouakAa
4.1.1.1本标准给出了市场参与者内部系统通过开放接口与证券交易所间的会话层连接标准。本标准是FIX标准化组织的FIXT1.1标准的精简版，且消息标签的使用遵循FIX5.0SP2的规定。由于JR/T0022-2014证券交易数据交换协议只是FIX协议的本地化版本，为凸显标准的直接来源，以下简称本标准为“LFIXT”。
4.1.1.2如无特别说明，本标准中提及的接收方、发送方等通信参与方均特指遵循本标准而实现的应用程序或模块，以下简称为“LFIXT参与方”。基于FIXT开发的程序或模块（以下简称为“FIXT参与方”），若要和LFIXT参与方进行通信，也需遵循本标准的约束。4.1.1.3会话层重传是会话层协议所规定的一种重传机制，用来确保有序、无失地传输每一条会话层消息。在FXT会话层协议中，会话层重传由消息接收方在识别出消息序号缺口之际主动发起，采取的方式是给对方发送一条消息重传请求。本标准在事实上取消了FIXT会话层协议的会话层重传，只对外仍然表现为标准的FIXT会话层，且可以和对端的FIXT参与方进行互操作。由于单个LFIXT会话使用单个TCP连接作为底层通信机制，因此在单个TCP连接内部，每一条消息将被有序、无失地传输。属于同一会话的、前后相继的若于次TCP连接之间，虽然可能存在会话层消息去失，但收到的会话层消息将仍然具有有序接收的性质。由于在LFIXT标准下会话层可能存在消息丢失，因此丢失的业务消息将只能通过应用层重传予以恢复。
4.1.1.4和FIXT协议一样，LFIXT协议本身并不限定所用的标准端口号。作为基于TCP的会话层协议，LFIXT使用的端口号建议在区间[1024，49151]内，具体取值由通信双方事先另行约定，4.1.2应用层重传
由于本标准的会话层恢复机制仅仅是为了与FIXT会话协议兼容，不能作为真正的消息恢复机制使用。因此，应通过应用层商定的重传机制予以恢复。应用层重传的具体机制不属于本标准规定的范畴。4.1.3NxtIn和NxtOut
会话双方收发的每条消息都带有一个消息序号。参与通信的每一端都需要维护一对序号（NxtIn，NxtOut），NxtIn表示下一个期前入向消息序号，NxtOut表示下一条出向消息将被赋予的序号。4.1.4会话发起方和接受方
4.1.4.1会话的建立需要一个发起方，需要一个接受方。发起方是先发出Logon消息并希望对方响应以一个Logon消息的一方，接受方则是等待发起方首先发出I.ogon消息并响应以Logon消息的一方。会话的发起方和接受方在会话建立后都可以双向地进行息的发送和接收。不要将会话发起方（initiator）、会话接受方（acceptor）同某条特定消息的发送（ender）和接收方（receiver）限卖
混为一谈。
4.1.4.2类似于会话发起方和会话接受方，也定义有注销发起方和注销接受方、会话重置发起方和会话重置接受方的概念。
4.1.4.3FIXT协议适用于各种不同的传输层协议（如UDP），因此不可能根据TCPsocket等特定的传输层信息来区分哪些报文隶属于同一个FIXT会话，而且由于FIXT中并不为每个FIXT会话定义有所谓“会话号”标签，且不是全部报文都具有username一类的标签，因此区分FIxT会话的唯一标识符是SenderCompID和TargetCompID字段的组合。LFIXT标准作为FIXT标准的精简版，也遵循此要求。2
iiiKAa~cJouaKAa
JR/T0182—2020
4.1.4.4FIXT协议中，单个FIXT参与方不能同时保有具有相同SenderCompID+TargetCompID的两个会话。在FIT中推荐的做法是：在已存在一个合法会话时，若一方试图以同样的SenderCompID+TargetCompID发起新的会话，对方将不发送任何Logout消息就直接终止新发起的会话原先已存在的会话不应受到影响。另一方面，FIXT协议并未明确不同的FIXT参与方是否允许同时保有同样标识的会话。一般而言，同一台服务器上的同标识会话较易进行查重，针对不同服务器建立的同标识会话则较难实现查重，但也非无法做到。在处理入向登录报文时，应利用SenderCompID和TargetCompID进行会话查重，之前已存在的同标识会话一定不受影响，但较晚收到的同标识会话请求可能被接受，但也可能被拒绝，FIXT协议不作限定。若请求被拒绝，则拒绝方式将遵循FIXT协议的约定，不回送Logout消息，直接断开TCP连接。会话发起方应当对这种情形做好准备。LFIXT标准作为FIXT标准的精简版，也遵循此要求。4.1.4.5本标准只充许单个会话同时通过单个TCP连接进行全双工通信，因此在通过登录报文信息确定是否允许继续通信后，可以直接利用socket来区分报文所属会话，但对于从同一socket上收到的后续报文仍应检查其SenderCompID和TargetCompID是否和登录时一致。4.1.5消息序号
所有的消息都由一个唯一的会话层消息序号（即消息头中的MsgSeqNum字段）进行标识。消息序号在会话开始时在大多数情况下被初始化为1，并在整个会话过程中连续递增，直到该会话过程全部结束。通过监视消息序号的连续性，通信双方可以识别消息缺口并做出反应，并可在同一会话的前后多个连接间进行同步。
上述的“连续递增”是针对通常情况而言。在下述情况下，接收方收到的消息的MsgSeqNum也可能出现倒流，但此时的倒流并非异常，而是被称为“正常倒流”：a）收到的消息是SeqReset-Reset消息且PossDupFlag=Y，此时应忽略MsgSeqNum，即使出现倒流也不是错误：
收到消息的PossDupFlag是Y，且此类消息确实允许出现PossDupFlag=Y，表示这是会话层重b)
c）通过Logon消息进行会话序号重置时，收到的消息其MsgSeqNum一定是1，因此也可能出现倒流。
每次会话都会创建一套款立的入向及出向的序号序列，参与连接的任何一方都维护一套用于出向消息的序号序列（NxtOut），同时也维另一套独立的入向消息的序号序列（NxtIn），用以监视接收的消息序号，以保证消息缺口的发现和处理。会话建立后，当LFIXT协议实现者接收的消息序号不等于预期接收的消息序号（NxtIn）时，需要考有长
虑进行修正处理。这里有几种情况：a）如果入向消息序号如果入向消息序号如果入向消息序号>NxtIn，那么表明有消息被遗漏。因为LFIXT使用TCT为传输协议，出现这种情况说明发生了严重异常错误，应立刻终止当前会话，4.1.6心跳
在消息交换的空闲期间，连接双方将以规定的时间间隔产生心跳消息。通过心跳消息可以监控通讯连接的状态并识别出入向消息序号的缺口。3
JR/T0182—2020
iiiKAa~cJouaKAa
心跳间隔时间由会话发起人通过登录消息的HeartBtInt字段确定。在传送了任何消息（而不仅仅是心跳消息）之后，都应立即重置心跳间隔计时器。心跳间隔时间应该得到连接双方的确认，由会话发起人给出，并得到会话接受方的确认。连接双方应使用相同的心跳间隔时间。每个心跳消息都将占用一个MsgSegNum消息序号4.1.7有序消息处理
本标准采用TCP连接作为底层通信机制。在会话建立后，在同一个TCP连接的延续期间，接收方在发现入向消息缺口时，说明检测到了对方或通信连接发生了严重异常，建议接收方终止该会话并断开TCP连接。如果接收方为会话的发起方，则应根据需要重建会话。4.1.8可能的消息重复传送
本会话协议采用TCP连接作为底层通信机制，会话双方在建立TCP连接之后，通过Logon消息进行序号协商，其后则是基于TCP进行的连续通信，正常情况下，不应该出现前面消息丢失却收到后面消息的情形，所以：
a）在发现入向消息序号缺口时，LFIXT参与者不应发送重传请求，应回送Logout后直接断开连接；
b）允许在入向消息中出现重传请求，比如基于FIXT的通信对手方虽然收到前面的消息但其自已没保存，并期望能按FIXT会话层协议的方式通过重传请求取回，对此LFIXT参与者将简单回送SeqReset-Reset消息予以回应；c）允许在入向消息中出现PossDupFlag=Y的消息，比如基于FIXT的通信对手方虽未收到本方发出的重传请求，但仅仅因为怀疑本方可能错过某些消息，而向本方发送这类PossDupFlag=Y的消息。
根据FIXT标准，除了Reject消息之外，其他管理消息理论上都不应被重发，而是通过发送带有同样消息序号的、带有PossDupFlag标志的SeqReset-GapFill消息对原消息进行替代。在此过程中，被替代的SeqReset-GapFi11消息本身虽然仍然以同样的消息序号、带上同样被置位的PossDupFlag标志出现，也被FIXT标准解释为“替代”而非“重发”。4.1.9可能的消息重复发送
在本标准中，应用层重发前标志应车应用层协议中明确设置，而不应该体现在会话层消息的标志位上。由于互操作的对方应遵从同样的应用层协议，因此本标准将不会给出向消息打上任何PossibleResend标志。
本标准允许在入向消息头中出现PossibleReserd标志，但将忽略该标志，直接将不附带该标志的消息交由应用层处理。
4.1.10消息完整性
消息数据内容的完整性可以用两种方式来验证：验证消息长度及字符的简单校哈和。消息长度被包括在BodyLength字段中，可以通过清点消息之中跟在BodyLengtn字段之后、直至并包括直接先于CheckSum域号（“10=）出现的那个域界定符之间的字符来验证。校验和的验证方法是：从消息头中“8=”中的“8开始、直到并包括直接先于CheckSum域号“10=”出现的字符，将每个字符的二进制值加总后，将计算值的最低8位同CheckSum字段中的值进行比较。4.1.11混乱的消息
当至少出现以下情形之一时，一条消息被称为“混乱的”：4
iiiKAa~cJouakAa
JR/T0182—2020
BeginString（tag8)不是消息的第一个标签，或不以8=FIXT.n.m的形式出现；a)I
BodyLength（tag9)不是消息的第二个标签，或未包含正确的字节计数：b)
MsgType（tag35)不是消息的第三个标签；c）
CheckSum（tag10)不是最后的标签，或其取值不正确：若MsgSeqNum（tag34)缺失，表明出现了严重的应用错误，应立刻终止FIX连接。e
4.1.12消息确认
由于本标准是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确认。但大量消息收发的确认可在应用层定义，并在应用层接受或拒绝4.1.13加密
LFIXT会话层不对数据进行加密处理，会话双方可考虑使用通信层的加密机制，比如使用建构于TCF之上的TLS通信加密机制。
4.2会话管理
4.2.1会话和连接
本标准采用TCP连接作为底层通信机制。若LFIXT参与方作为会话的主动发起方，应在每次新建TCP连接之后通过置位序号重设标志（ResetSeqNumFlag）的Logon消息来将起始消息序号重置回1，此时会话和TCP连接是一一对应的虽然本标准可以被设计成底层使用两个独立的TCP连接，每个连接都以单工模式工作，但由于在TCP连接上实现全双工的通信并不困难且维护简单，因此本标准规定：对于单个会话而言，同时只使用一个全双工的TCP连接。
若LFIXT参与方作为会话的接收方，由于该会话的发起方可能是标准的FIXT，此时建立的会话可以跨越多个TCP连接
在单次TCP连接内部，每个会话都分为三个部分：建立会话、消息交换、终止会话。4.2.2建立会话
4.2.2.1会话步骤
建立会话包含三个内部步骤：建连接、身份认证、消息同步。唯准信
4.2.2.2建立连接
会话的发起方与接受方应先建立TCP连接。LFIXT与方在TCP连接建立后，应当总是初始化NxtIn=1，NxtOut=1。
4.2.2.3身份认证
会话发起方发送登录消息（Logon），会话接受方认证发起方身份的合法性。处理逻辑如下：如果发起方身份通过认证，则接受方发送一个登录消息作回应。a
如果认证失败，会话接受方则在可选地发送一个含失败说明的注销消息（Logout）后关闭连接。b）
发送注销消息并非是必须的，因为这样做会消耗一个序号，在某些情况下可能会引起其他问题。c)
会话发起方应等待来自接受方的确认Logon消息，方可向接受方发送其他消息。否则，接受方可能尚未准备好接收它们，
JR/T0182—2020
iiiKAa~cJouaKAa
d）在发起方被认证后，接受方将立即回应一个确认Logon消息。发起方将把从接受方返回的Logon消息作为“一个会话已经建立”的确认。4.2.2.4消息同步
本标准并不提供真正的会话层重传机制，因此LFIXT参与方作为会话的发起方时，可通过会话重置消息（即ResetSeqNumFlag=Y的Logon消息）将会话双方的消息序号重置，来完成会话层消息同步。LFIXT参与方作为会话接受方时，可以利用Logon消息中的NextExpectedMsgSeqNum来完成会话层消息同步。这种方式提供了对FIXT会话协议的消息同步的兼容，具体机制见4.3.2登录消息处理。4.2.3消息交换
在建立会话之后，会话双方可以开始进行正常的消息交换。交换的消息包括“管理消息”和“应用消息”，本标准仅对管理消息进行描述。4.2.4注销会话
LFIXT会话的正常结束是通过连接双方互相发送注销消息（Logout），注销时不需要进行消息缺口检查。若结束时没有收到回送的注销消息（Logout），则把对方视作已注销。除此之外的其它方式的会话结束视为非正常，并应按错误来处理。在结束会话之前，注销消息（Logout）的发起方应等待对方回送的注销消息（Logout）。如果接收方在一定时间内没有答复，那么会话就可以立即中断。注销不影响任何业务层消息的状态。所有有效的业务层消息都可在注销（Logout）之后执行。4.3恢复
4.3.1会话恢复机制概述
本标准的会话层恢复机制是为了与FIXT会话协议兼容，不能作为真正的消息恢复机制使用，会话对端应通过应用层的消息恢复机制来获得缺失的数据。LFIXT参与方只在建立会话阶段存在消息序号同步，在会话持续期间不提供真正的消息恢复，而是简单地通过回应SeqResrt-Reset消息来打发消息重传请求。4.3.2登录消息处理
LFIXT参与方作为会话接受方时，只需将不方xtIn设置为发起方Logon消息的MsgSeqNum+1，NxtOut设置为发起方Logon消息中的NextExpectedMsgseqNur(79）即可。会话接受方不需要检查任何缺口，会话接受方也不会向发起方请求重传任何消息。如果会发起没有提供NextExpectedMsgSeqNum字段，则会话接受方的NxtOut设置为1
4.3.3重传请求消息处理
LFIXT参与方不会主动发送重传请求，但可能收到FIXT参与方发送的重传请求当LFIXT参与方收到重传请求时，会使用SeqReset-Reset消息重置发送方序号，而不会提供历史消息的重传。4.3.4序号重设消息处理
LFIXT参与方收到序号重设消息时，会根据序号重设消息中的NewSeqNo来重置本方NxtIn。5消息规范
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
iiiKAa~cJouakAa
中华人民共和国金融行业标准
JR/T0182—2020
轻量级实时STEP消息传输协议
Light weight realtime STEP message transfer protoco2020-02-26发布
中国证券监督管理委员会
2020-02-26实施
iiiKAa~cJouaKAa
引言，
规范性引用文件
3术语和定义
4会话机制
iiikAacJouakAa-
关键概念的重要说明
会话管理、
5消息规范
消息结构.
管理消息
6数据字典
附录A
附录B
附录C
附录D
附录E
附录F
数据类型此内容来自标准下载网
会话层域规范.
（规范性附录）计算校验和
（规范性附录）处理心跳和测试请求.（规范性附录）登录场景
正常登录场景
正常登录场景
正常登录场景
异常登录场景
异常登录场景工
（规范性附录）处理会话拒绝
（规范性附录）处理重传请求场景处理重传请求场景
处理重传请求场景
（规范性附录）注销场景
JR/T0182—2020
JR/T0182—2020
iiiKAa~cJouakAa
本标准依据GB/T1.1一2009给出的规则起草。本标准由全国金融标准化技术委员会证券分技术委员会（SAC/TC180/SC4）提出本标准由全国金融标准化技术委员会（SAC/TC180）归口。本标准起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信息技术服务有限责任公司。
本标准主要起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东。11
iiiKAa~cJouakAa
JR/T0182—2020
FIX（FinancialInformationeXchange）协议即金融信息交换协议，是用于全球金融市场机构和参与者间的电子金融信息交互的协议，以下简称FIX协议。在FIX标准化组织（FIXTradingCommunity）提出的FIX5.0标准中，单独定义有一个会话层协议（FIXSessionProtocol，FIXT），其版本是FIXT1.1。JR/T0022-2014《证券交易数据交换协议》（SecuritiesTradingExchangeProtocol，简称STEP）是FIX协议的行业标准。本标准是对FIXT1.1及JR/T0022-2014中会话层协议的轻量化。iiiKAa~cJouaKAa
1范围
iiiKAa~cJouaKAa-
轻量级实时STEP消息传输协议
JR/T0182—2020
本标准规定了轻量级实时STEP消息传输协议（Light-weightrealtimeSTEPmessage
transfer
protocol）使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式规范、数据字典等内容。
本标准适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。本标准也可被推广用于支持证券期货行业各机构系统间的会话连接。规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。JR/T0022—2014
IS010383:2012
financial
证券交易数据交换协议
证券及相关金融工具
交易所和市场识别码（Securitiesandrelated
instruments-Codesfor exchanges and market identification(Mic))Financial
August2011
Financial
March2008
3术语和定义
information
information
exchange
protocol(FIx)
Version
5.0Service
exchangeprotocol(FIx)FIX
下列术语和定义适用于文件。
证券交易数据交换协议
session protocol
versionl.1
securtieatradingexchangeprotocol;STEp证券交易所交易系统与市场参与者系纤之间进行证券交易数据交换的行业信息标准。3.2
金融信息交换协议
financialinformationexehangeFix进行证券交易信息电子交换的国际信息标准。3.3
FIX会话层协议
fix sessionlayerprotocol;FixT独立于通信协议（如TCP、UDP等）和通信介质（如光缆、卫星等）的电子数据佳精协议，FIX协议的重要子协议。
4会话机制
4.1关键概念的重要说明
JR/T0182—2020
4.1.1会话层重传
iiiKAa~cJouakAa
4.1.1.1本标准给出了市场参与者内部系统通过开放接口与证券交易所间的会话层连接标准。本标准是FIX标准化组织的FIXT1.1标准的精简版，且消息标签的使用遵循FIX5.0SP2的规定。由于JR/T0022-2014证券交易数据交换协议只是FIX协议的本地化版本，为凸显标准的直接来源，以下简称本标准为“LFIXT”。
4.1.1.2如无特别说明，本标准中提及的接收方、发送方等通信参与方均特指遵循本标准而实现的应用程序或模块，以下简称为“LFIXT参与方”。基于FIXT开发的程序或模块（以下简称为“FIXT参与方”），若要和LFIXT参与方进行通信，也需遵循本标准的约束。4.1.1.3会话层重传是会话层协议所规定的一种重传机制，用来确保有序、无失地传输每一条会话层消息。在FXT会话层协议中，会话层重传由消息接收方在识别出消息序号缺口之际主动发起，采取的方式是给对方发送一条消息重传请求。本标准在事实上取消了FIXT会话层协议的会话层重传，只对外仍然表现为标准的FIXT会话层，且可以和对端的FIXT参与方进行互操作。由于单个LFIXT会话使用单个TCP连接作为底层通信机制，因此在单个TCP连接内部，每一条消息将被有序、无失地传输。属于同一会话的、前后相继的若于次TCP连接之间，虽然可能存在会话层消息去失，但收到的会话层消息将仍然具有有序接收的性质。由于在LFIXT标准下会话层可能存在消息丢失，因此丢失的业务消息将只能通过应用层重传予以恢复。
4.1.1.4和FIXT协议一样，LFIXT协议本身并不限定所用的标准端口号。作为基于TCP的会话层协议，LFIXT使用的端口号建议在区间[1024，49151]内，具体取值由通信双方事先另行约定，4.1.2应用层重传
由于本标准的会话层恢复机制仅仅是为了与FIXT会话协议兼容，不能作为真正的消息恢复机制使用。因此，应通过应用层商定的重传机制予以恢复。应用层重传的具体机制不属于本标准规定的范畴。4.1.3NxtIn和NxtOut
会话双方收发的每条消息都带有一个消息序号。参与通信的每一端都需要维护一对序号（NxtIn，NxtOut），NxtIn表示下一个期前入向消息序号，NxtOut表示下一条出向消息将被赋予的序号。4.1.4会话发起方和接受方
4.1.4.1会话的建立需要一个发起方，需要一个接受方。发起方是先发出Logon消息并希望对方响应以一个Logon消息的一方，接受方则是等待发起方首先发出I.ogon消息并响应以Logon消息的一方。会话的发起方和接受方在会话建立后都可以双向地进行息的发送和接收。不要将会话发起方（initiator）、会话接受方（acceptor）同某条特定消息的发送（ender）和接收方（receiver）限卖
混为一谈。
4.1.4.2类似于会话发起方和会话接受方，也定义有注销发起方和注销接受方、会话重置发起方和会话重置接受方的概念。
4.1.4.3FIXT协议适用于各种不同的传输层协议（如UDP），因此不可能根据TCPsocket等特定的传输层信息来区分哪些报文隶属于同一个FIXT会话，而且由于FIXT中并不为每个FIXT会话定义有所谓“会话号”标签，且不是全部报文都具有username一类的标签，因此区分FIxT会话的唯一标识符是SenderCompID和TargetCompID字段的组合。LFIXT标准作为FIXT标准的精简版，也遵循此要求。2
iiiKAa~cJouaKAa
JR/T0182—2020
4.1.4.4FIXT协议中，单个FIXT参与方不能同时保有具有相同SenderCompID+TargetCompID的两个会话。在FIT中推荐的做法是：在已存在一个合法会话时，若一方试图以同样的SenderCompID+TargetCompID发起新的会话，对方将不发送任何Logout消息就直接终止新发起的会话原先已存在的会话不应受到影响。另一方面，FIXT协议并未明确不同的FIXT参与方是否允许同时保有同样标识的会话。一般而言，同一台服务器上的同标识会话较易进行查重，针对不同服务器建立的同标识会话则较难实现查重，但也非无法做到。在处理入向登录报文时，应利用SenderCompID和TargetCompID进行会话查重，之前已存在的同标识会话一定不受影响，但较晚收到的同标识会话请求可能被接受，但也可能被拒绝，FIXT协议不作限定。若请求被拒绝，则拒绝方式将遵循FIXT协议的约定，不回送Logout消息，直接断开TCP连接。会话发起方应当对这种情形做好准备。LFIXT标准作为FIXT标准的精简版，也遵循此要求。4.1.4.5本标准只充许单个会话同时通过单个TCP连接进行全双工通信，因此在通过登录报文信息确定是否允许继续通信后，可以直接利用socket来区分报文所属会话，但对于从同一socket上收到的后续报文仍应检查其SenderCompID和TargetCompID是否和登录时一致。4.1.5消息序号
所有的消息都由一个唯一的会话层消息序号（即消息头中的MsgSeqNum字段）进行标识。消息序号在会话开始时在大多数情况下被初始化为1，并在整个会话过程中连续递增，直到该会话过程全部结束。通过监视消息序号的连续性，通信双方可以识别消息缺口并做出反应，并可在同一会话的前后多个连接间进行同步。
上述的“连续递增”是针对通常情况而言。在下述情况下，接收方收到的消息的MsgSeqNum也可能出现倒流，但此时的倒流并非异常，而是被称为“正常倒流”：a）收到的消息是SeqReset-Reset消息且PossDupFlag=Y，此时应忽略MsgSeqNum，即使出现倒流也不是错误：
收到消息的PossDupFlag是Y，且此类消息确实允许出现PossDupFlag=Y，表示这是会话层重b)
c）通过Logon消息进行会话序号重置时，收到的消息其MsgSeqNum一定是1，因此也可能出现倒流。
每次会话都会创建一套款立的入向及出向的序号序列，参与连接的任何一方都维护一套用于出向消息的序号序列（NxtOut），同时也维另一套独立的入向消息的序号序列（NxtIn），用以监视接收的消息序号，以保证消息缺口的发现和处理。会话建立后，当LFIXT协议实现者接收的消息序号不等于预期接收的消息序号（NxtIn）时，需要考有长
虑进行修正处理。这里有几种情况：a）如果入向消息序号
在消息交换的空闲期间，连接双方将以规定的时间间隔产生心跳消息。通过心跳消息可以监控通讯连接的状态并识别出入向消息序号的缺口。3
JR/T0182—2020
iiiKAa~cJouaKAa
心跳间隔时间由会话发起人通过登录消息的HeartBtInt字段确定。在传送了任何消息（而不仅仅是心跳消息）之后，都应立即重置心跳间隔计时器。心跳间隔时间应该得到连接双方的确认，由会话发起人给出，并得到会话接受方的确认。连接双方应使用相同的心跳间隔时间。每个心跳消息都将占用一个MsgSegNum消息序号4.1.7有序消息处理
本标准采用TCP连接作为底层通信机制。在会话建立后，在同一个TCP连接的延续期间，接收方在发现入向消息缺口时，说明检测到了对方或通信连接发生了严重异常，建议接收方终止该会话并断开TCP连接。如果接收方为会话的发起方，则应根据需要重建会话。4.1.8可能的消息重复传送
本会话协议采用TCP连接作为底层通信机制，会话双方在建立TCP连接之后，通过Logon消息进行序号协商，其后则是基于TCP进行的连续通信，正常情况下，不应该出现前面消息丢失却收到后面消息的情形，所以：
a）在发现入向消息序号缺口时，LFIXT参与者不应发送重传请求，应回送Logout后直接断开连接；
b）允许在入向消息中出现重传请求，比如基于FIXT的通信对手方虽然收到前面的消息但其自已没保存，并期望能按FIXT会话层协议的方式通过重传请求取回，对此LFIXT参与者将简单回送SeqReset-Reset消息予以回应；c）允许在入向消息中出现PossDupFlag=Y的消息，比如基于FIXT的通信对手方虽未收到本方发出的重传请求，但仅仅因为怀疑本方可能错过某些消息，而向本方发送这类PossDupFlag=Y的消息。
根据FIXT标准，除了Reject消息之外，其他管理消息理论上都不应被重发，而是通过发送带有同样消息序号的、带有PossDupFlag标志的SeqReset-GapFill消息对原消息进行替代。在此过程中，被替代的SeqReset-GapFi11消息本身虽然仍然以同样的消息序号、带上同样被置位的PossDupFlag标志出现，也被FIXT标准解释为“替代”而非“重发”。4.1.9可能的消息重复发送
在本标准中，应用层重发前标志应车应用层协议中明确设置，而不应该体现在会话层消息的标志位上。由于互操作的对方应遵从同样的应用层协议，因此本标准将不会给出向消息打上任何PossibleResend标志。
本标准允许在入向消息头中出现PossibleReserd标志，但将忽略该标志，直接将不附带该标志的消息交由应用层处理。
4.1.10消息完整性
消息数据内容的完整性可以用两种方式来验证：验证消息长度及字符的简单校哈和。消息长度被包括在BodyLength字段中，可以通过清点消息之中跟在BodyLengtn字段之后、直至并包括直接先于CheckSum域号（“10=）出现的那个域界定符
当至少出现以下情形之一时，一条消息被称为“混乱的”：4
iiiKAa~cJouakAa
JR/T0182—2020
BeginString（tag8)不是消息的第一个标签，或不以8=FIXT.n.m的形式出现；a)I
BodyLength（tag9)不是消息的第二个标签，或未包含正确的字节计数：b)
MsgType（tag35)不是消息的第三个标签；c）
CheckSum（tag10)不是最后的标签，或其取值不正确：若MsgSeqNum（tag34)缺失，表明出现了严重的应用错误，应立刻终止FIX连接。e
4.1.12消息确认
由于本标准是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确认。但大量消息收发的确认可在应用层定义，并在应用层接受或拒绝4.1.13加密
LFIXT会话层不对数据进行加密处理，会话双方可考虑使用通信层的加密机制，比如使用建构于TCF之上的TLS通信加密机制。
4.2会话管理
4.2.1会话和连接
本标准采用TCP连接作为底层通信机制。若LFIXT参与方作为会话的主动发起方，应在每次新建TCP连接之后通过置位序号重设标志（ResetSeqNumFlag）的Logon消息来将起始消息序号重置回1，此时会话和TCP连接是一一对应的虽然本标准可以被设计成底层使用两个独立的TCP连接，每个连接都以单工模式工作，但由于在TCP连接上实现全双工的通信并不困难且维护简单，因此本标准规定：对于单个会话而言，同时只使用一个全双工的TCP连接。
若LFIXT参与方作为会话的接收方，由于该会话的发起方可能是标准的FIXT，此时建立的会话可以跨越多个TCP连接
在单次TCP连接内部，每个会话都分为三个部分：建立会话、消息交换、终止会话。4.2.2建立会话
4.2.2.1会话步骤
建立会话包含三个内部步骤：建连接、身份认证、消息同步。唯准信
4.2.2.2建立连接
会话的发起方与接受方应先建立TCP连接。LFIXT与方在TCP连接建立后，应当总是初始化NxtIn=1，NxtOut=1。
4.2.2.3身份认证
会话发起方发送登录消息（Logon），会话接受方认证发起方身份的合法性。处理逻辑如下：如果发起方身份通过认证，则接受方发送一个登录消息作回应。a
如果认证失败，会话接受方则在可选地发送一个含失败说明的注销消息（Logout）后关闭连接。b）
发送注销消息并非是必须的，因为这样做会消耗一个序号，在某些情况下可能会引起其他问题。c)
会话发起方应等待来自接受方的确认Logon消息，方可向接受方发送其他消息。否则，接受方可能尚未准备好接收它们，
JR/T0182—2020
iiiKAa~cJouaKAa
d）在发起方被认证后，接受方将立即回应一个确认Logon消息。发起方将把从接受方返回的Logon消息作为“一个会话已经建立”的确认。4.2.2.4消息同步
本标准并不提供真正的会话层重传机制，因此LFIXT参与方作为会话的发起方时，可通过会话重置消息（即ResetSeqNumFlag=Y的Logon消息）将会话双方的消息序号重置，来完成会话层消息同步。LFIXT参与方作为会话接受方时，可以利用Logon消息中的NextExpectedMsgSeqNum来完成会话层消息同步。这种方式提供了对FIXT会话协议的消息同步的兼容，具体机制见4.3.2登录消息处理。4.2.3消息交换
在建立会话之后，会话双方可以开始进行正常的消息交换。交换的消息包括“管理消息”和“应用消息”，本标准仅对管理消息进行描述。4.2.4注销会话
LFIXT会话的正常结束是通过连接双方互相发送注销消息（Logout），注销时不需要进行消息缺口检查。若结束时没有收到回送的注销消息（Logout），则把对方视作已注销。除此之外的其它方式的会话结束视为非正常，并应按错误来处理。在结束会话之前，注销消息（Logout）的发起方应等待对方回送的注销消息（Logout）。如果接收方在一定时间内没有答复，那么会话就可以立即中断。注销不影响任何业务层消息的状态。所有有效的业务层消息都可在注销（Logout）之后执行。4.3恢复
4.3.1会话恢复机制概述
本标准的会话层恢复机制是为了与FIXT会话协议兼容，不能作为真正的消息恢复机制使用，会话对端应通过应用层的消息恢复机制来获得缺失的数据。LFIXT参与方只在建立会话阶段存在消息序号同步，在会话持续期间不提供真正的消息恢复，而是简单地通过回应SeqResrt-Reset消息来打发消息重传请求。4.3.2登录消息处理
LFIXT参与方作为会话接受方时，只需将不方xtIn设置为发起方Logon消息的MsgSeqNum+1，NxtOut设置为发起方Logon消息中的NextExpectedMsgseqNur(79）即可。会话接受方不需要检查任何缺口，会话接受方也不会向发起方请求重传任何消息。如果会发起没有提供NextExpectedMsgSeqNum字段，则会话接受方的NxtOut设置为1
4.3.3重传请求消息处理
LFIXT参与方不会主动发送重传请求，但可能收到FIXT参与方发送的重传请求当LFIXT参与方收到重传请求时，会使用SeqReset-Reset消息重置发送方序号，而不会提供历史消息的重传。4.3.4序号重设消息处理
LFIXT参与方收到序号重设消息时，会根据序号重设消息中的NewSeqNo来重置本方NxtIn。5消息规范
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。