一文读懂金融行业中的 FIX 协议

引言

• FIX协议是金融行业常用的电子交易协议，全称为“Financial Information eXchange”，意为金融信息交换。该协议最初由美国证券交易商协会（SIA）于1992年开发，旨在为证券业务提供标准化的电子通信协议，以提高交易效率和降低成本。目前，该协议已成为全球金融市场最常用的电子交易协议之一，被广泛应用于证券、期货、外汇等金融领域。

重要版本

FIX 4.x

• FIX 4.x系列是最早发布的FIX协议版本，包括FIX 4.0、FIX 4.1、FIX 4.2、FIX 4.3和FIX 4.4。这些版本为金融机构提供了一种标准化的交流方式，支持订单传递、市场数据传输和交易确认等功能。

FIX 5.0

• FIX 5.0版本引入了许多新特性和功能改进，以适应金融市场的发展需求。其中一些重要的特性包括：
  • 灵活性增强：引入了自定义字段、组合订单和多标的物等灵活性增强功能，使协议更适用于各种复杂的交易策略和产品。
  • 扩展性：支持更多的消息类型和业务领域，如衍生品、固定收益产品等。
  • 监控和调试：提供了更详细的错误处理和状态报告，帮助监控和调试通信问题。

消息格式

• FIX协议结构有两种，一种是基于“标记=值”，一种是XML结构（可读性较好，但冗余信息较多），实际使用中一般在构建&展示中使用XML,传输使用“标记=值”格式。
• FIX协议基于文本格式。每个FIX消息都由消息头（Header）、消息体（Body）和消息尾（Trailer）三部分组成。消息头和消息尾包含了一些必要的标识信息，比如发送方、接收方、消息序列号等。消息体则包含了具体的业务数据，比如订单信息、成交信息等。FIX消息的每个字段都有唯一的标识符（Tag）和对应的取值（Value），标识符和取值之间用等号（=）连接，取值之间用竖线（|）分隔。例如，下面是一条简单的FIX消息：
• 0-5000: Fix协议定义标记; 5000-9999：用于信息交换，通过Fix网站进行注册; 10000以上用于企业内部使用，不需要注册。

8=FIX.4.2|9=59|35=A|49=SENDER|56=TARGET|34=1|52=20230508-10:15:30.123|10=054|

8=FIX.4.2：这是FIX协议版本号，表示使用的是FIX 4.2版本。
9=59：这是消息的长度字段，表示消息内容的长度为59个字符（包括长度字段本身）。
35=A：这是消息类型字段，表示该消息是一个登录请求消息（Logon）。
49=SENDER：这是发送方标识符字段，表示发送方的标识符为"SENDER"。
56=TARGET：这是目标方标识符字段，表示目标方的标识符为"TARGET"。
34=1：这是消息序列号字段，表示该消息的序列号为1。
52=20230508-10:15:30.123：这是时间戳字段，表示消息的时间戳为"2023-05-08 10:15:30.123"。
10=054：这是校验和字段，表示校验和为54。

通信过程

1、连接建立：

客户端向服务器发起连接请求，建立TCP连接。
连接建立后，客户端和服务器可以进行后续的通信。

2、登录认证：

客户端发送登录请求消息（Logon），包含了登录所需的信息，如发送方标识符（SenderCompID）、目标方标识符（TargetCompID）等。
服务器接收并验证登录请求，返回登录响应消息（Logon）作为认证结果。
登录响应消息中可能包含了会话标识符（SessionID），用于后续消息的关联。

3、业务交互：

客户端和服务器通过交换FIX消息来进行具体的业务操作，如下单、撤单、查询等。
业务消息中包含了不同的消息类型（MsgType），如新订单单条（New Order Single）、订单取消请求（Order Cancel Request）等，以及相应的字段和取值。

4、连接关闭：

当业务交互完成或需要断开连接时，客户端或服务器可以发送连接关闭消息（Logout）。
连接关闭消息用于正常终止FIX会话，并释放相关资源。
发送连接关闭消息后，客户端和服务器断开TCP连接。

通信报文示例：

8=FIX.4.2|9=178|35=A|34=1|49=CLIENT1|52=20230508-10:15:30.123|56=SERVER1|98=0|108=30|10=064|
8=FIX.4.2|9=128|35=A|34=2|49=SERVER1|52=20230508-10:15:30.456|56=CLIENT1|98=0|108=30|10=088|
8=FIX.4.2|9=120|35=0|34=3|49=CLIENT1|52=20230508-10:15:31.789|56=SERVER1|10=123|
8=FIX.4.2|9=120|35=1|34=4|49=CLIENT1|52=20230508-10:15:32.345|56=SERVER1|11=ORDER1|55=AAPL|38=100|40=1|54=1|59=0|10=200|
8=FIX.4.2|9=120|35=8|34=5|49=CLIENT1|52=20230508-10:15:33.567|56=SERVER1|37=ORDER1|10=194|

第一条消息是客户端发送的登录请求消息（Logon）：

35=A 表示消息类型为登录请求。
49=CLIENT1 表示发送方标识符为"CLIENT1"。
56=SERVER1 表示目标方标识符为"SERVER1"。
34=1 表示消息序列号为1。
52=20230508-10:15:30.123 表示消息的时间戳。
98=0 表示心跳间隔为0秒。
108=30 表示最大消息长度为30字节。
10=064 表示校验和。

第二条消息是服务器返回的登录响应消息（Logon）：

35=A 表示消息类型为登录响应。
49=SERVER1 表示发送方标识符为"SERVER1"。
56=CLIENT1 表示目标方标识符为"CLIENT1"。
34=2 表示消息序列号为2。
52=20230508-10:15:30.456 表示消息的时间戳。
98=0 表示心跳间隔为0秒。
108=30 表示最大消息长度为30字节。
10=088 表示校验和。

第三条消息是客户端发送的心跳消息（Heartbeat）：

35=0 表示消息类型为心跳。
34=3 表示消息序列号为3。
49=CLIENT1 表示发送方标识符为"CLIENT1"。
52=20230508-10:15:31.789 表示消息的时间戳。
56=SERVER1 表示目标方标识符为"SERVER1"。
10=123 表示校验和。

第四条消息是客户端发送的下单消息（New Order Single）：

35=1 表示消息类型为下单消息。
34=4 表示消息序列号为4。
49=CLIENT1 表示发送方标识符为"CLIENT1"。
52=20230508-10:15:32.345 表示消息的时间戳。
56=SERVER1 表示目标方标识符为"SERVER1"。
11=ORDER1 表示订单的唯一标识符为"ORDER1"。
55=AAPL 表示订单的标的物为"AAPL"。
38=100 表示订单数量为100。
40=1 表示订单类型为市价单。
54=1 表示订单方向为买入。
59=0 表示不是即时取消订单。
10=200 表示校验和。

第五条消息是服务器返回的下单执行消息（Execution Report）：

35=8 表示消息类型为下单执行消息。
34=5 表示消息序列号为5。
49=CLIENT1 表示发送方标识符为"CLIENT1"。
52=20230508-10:15:33.567 表示消息的时间戳。
56=SERVER1 表示目标方标识符为"SERVER1"。
37=ORDER1 表示订单的唯一标识符为"ORDER1"。
10=194 表示校验和。

核心概念

Initiator和Acceptor

• FIX有Initiator和Acceptor两种应用类型，规定Initiator是通信发起者，Acceptor为接受者，Initiator通过发送初始Logon消息发起Session；Acceptor负责执行第一次认证和通过传输Logon消息响应确认正式连接请求被接受。

FIX Connection

• 发送方和接受的一次物理连接。

Fix Session

• 一个FIX Session定义为一个在连接双方间的带有连续序列号的有序消息双向传输流（点对点）。单个FIX Session能够跨越多个连续的物理连接（非并行，如断开后重新连接，一个Session同一时刻只会持有一个物理连接）。在一个FIX Session中，参与方能够多次连接和断开连接。连接的参与方必须根据单个系统及时间区域需求，公共协商Session的开始和结束。
• 每个FIX参与方必须为FIX Session维护两个序列号，一个是接收序列号，一个是发送序列号，两者都在建立FIX Session开始时初始化为1。每个消息被赋予一个唯一的序列号值，并在消息发送后递增。此外，每个收到的消息都有一个唯一的序列号，接收序列号计数器在收到每个消息后将会被递增。当接收序列号与所希望得到的的正确序列号不必配时，必须采取纠错处理。

心跳

• 在发送方和接收方建立 Session 后，发送方和接受方都可以通过定时心跳检测来检测连接的有效性，从而采取相应的处理方案，如告警、重连等，从而保证连接的稳定性。当双方都检测到连接失效时，需要一定的机制来保证避免重复连接建立。

当接收方和发送方同时检测到连接失效并尝试重新建立连接时，可以采取一些机制来避免重复建立连接的情况。下面是可能的处理方式：

握手协议：在重新建立连接之前，发送方和接收方可以使用握手协议来协商建立连接的条件和规则。这可以包括使用一个共享的握手标识符或生成一个唯一的会话ID，以确保双方在重连过程中可以识别和匹配彼此。

连接状态标记：在重新建立连接过程中，可以使用连接状态标记或变量来指示连接状态。发送方和接收方可以在重连之前检查连接状态标记，以确定是否已经在尝试建立连接。如果连接状态标记已被设置为建立中，另一方可以等待或跳过建立连接的步骤。

连接超时处理：当发送方和接收方同时检测到连接失效并尝试重新建立连接时，可以使用连接超时机制来避免重复建立连接。每一方可以设置一个合理的连接超时时间，在此时间内等待对方建立连接。如果超过超时时间仍未建立连接，可以继续执行重新建立连接的操作。

异常处理和通知：如果发送方和接收方同时尝试重新建立连接，并由于某些原因导致重复建立连接，可以在系统中添加异常处理机制。这样可以检测到重复连接的情况，并采取相应的处理措施，例如关闭冗余的连接或发送通知以警示相关人员。

数据完整性校验

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

校验码的生成步骤如下：

将消息中除校验码字段（Tag 10）外的所有字符（包括标签和值）的ASCII码相加。

将上述总和除以256，并取余数。

将余数转换为两位的十六进制数表示。

例如，假设要生成的校验码为CheckSum字段（Tag 10），消息中的字符总和为275。按照步骤2，275除以256的余数为19。将19转换为十六进制表示，
即为13（十进制值19对应的十六进制表示）。

因此，生成的校验码为13（十六进制表示），作为消息的CheckSum字段值。

序列号 & 消息确认 & 重复消息 & 消息重发

• 序列号：每个Session发送方和接收方都有一个序列号（SeqNum），它代表了消息的顺序。每个发送方和接收方在发送和接收消息时都必须递增序列号。接收方只接受序列号比上次接收到的消息的序列号大1的消息，如果接收到的消息序列号比上次接收到的消息序列号小，则会丢弃该消息。

• 消息确认：FIX协议中使用消息确认机制来保证消息传递的可靠性。接收方收到消息后必须向发送方发送一条消息确认消息。消息确认消息包含了已经接收到的最后一条消息的序列号。发送方接收到消息确认消息后，会将所有小于或等于接收到的最后一条消息序列号的消息标记为已接收，并从消息队列中删除这些消息。

• 重复消息：如果发送方没有收到接收方的消息确认消息，它会认为该消息未被接收到，会重发该消息。接收方在接收到重复的消息时，会发送一条消息确认消息，并在消息中指定最后一条已经接收到的消息的序列号，从而让发送方知道接收方已经接收到了这条消息。

• 消息重发：如果发送方在规定的时间内没有收到接收方的消息确认消息，则会重发该消息。接收方在接收到重复的消息时，会发送一条消息确认消息，并在消息中指定最后一条已经接收到的消息的序列号，从而让发送方知道接收方已经接收到了这条消息。接收方不会对重复的消息做出任何操作，因为它已经接收到该消息并发送了确认消息。如果接收方没有接收到该消息，则会将其视为新的消息，并进行处理。

加密

自定义域

FIX 协议中的消息队列

• 消息排序：消息队列可以按照消息的序列号（SeqNum）对待发送的消息进行排序。这样可以确保消息按照正确的顺序发送，避免消息乱序导致的问题。
• 消息重发：如果发送方在规定的时间内没有收到接收方的消息确认消息，它可以从消息队列中重新发送相应的消息。消息队列允许发送方跟踪需要重发的消息，并确保消息的可靠传输。

相关协议

FIXT

• FIXT（FIX Trading Community Technical Committee）是FIX协议的传输层协议扩展，为FIX协议提供了与不同传输协议（如TCP、HTTP、AMQP等）进行交互的能力。

FAST

• FAST（FIX Adapted for STreaming）是一种基于FIX协议的高性能消息编码格式。它通过使用二进制编码和压缩技术来提高消息传输效率和处理速度，特别适用于高频交易和大规模数据传输的场景。

FIX Orchestra

• FIX Orchestra是FIX协议的模型定义语言和工具集，用于描述FIX协议消息结构和业务语义。它提供了一种标准化的方式来定义和验证FIX协议消息，有助于提高FIX实现的互操作性和准确性。