4. FIX连接建立
在FIX行情接入中，真正决定“能不能稳定收到行情”的，往往不是单条报文的解析，而是会话层是否被正确建立与维护。FIX协议把连接管理抽象为会话层（Session Layer），通过Logon、Logout、Heartbeat、TestRequest、ResendRequest、SequenceReset等管理报文，保证双方在有序、可恢复、可检测的状态下交换数据。理解这些流程，是行情网关稳定运行的基础。
一、核心原理：序号驱动的可靠会话
FIX会话的核心是双向独立的消息序号（MsgSeqNum）。每一方维护自己的发送序号和期望接收序号，任何一条应用消息或管理消息都会使发送序号递增。接收方若发现收到的序号大于期望值，说明中间有丢失，就会触发重传；若小于期望值，则可能是重复消息或严重错乱。正是这个机制，让FIX在TCP之上实现了“可检测丢失、可请求补发”的可靠语义。
会话建立的第一步是Logon。发起方发送Logon，携带HeartBtInt（心跳间隔）、ResetSeqNumFlag等字段；接收方校验通过后回复Logon，会话正式进入激活状态。此后双方按HeartBtInt周期互发Heartbeat，若在约定时间内未收到任何消息，则发送TestRequest探测对方，对方必须以Heartbeat（带TestReqID）响应，否则判定连接异常并断开。
二、方法流程：六类管理报文的协作
会话管理报文各司其职，下面按典型交互顺序梳理：
- Logon（35=A）：建立会话，协商HeartBtInt、加密方式、ResetSeqNumFlag。若ResetSeqNumFlag=Y，双方序号重置为1。
- Heartbeat（35=0）：空闲时按周期发送，维持连接活性；也可作为TestRequest的应答。
- TestRequest（35=1）：当超过HeartBtInt未收到对方消息时发送，强制对方立即回Heartbeat。
- ResendRequest（35=2）：发现序号缺口时，请求对方重发BeginSeqNo到EndSeqNo之间的消息。
- SequenceReset（35=4）：用于跳过已失效消息（GapFill）或强制重置序号（Reset），避免无限重传。
- Logout（35=5）：正常关闭会话，双方确认后断开。
| 报文 | MsgType | 触发条件 | 关键字段 |
|---|---|---|---|
| Logon | A | 连接建立后 | HeartBtInt、ResetSeqNumFlag |
| Heartbeat | 0 | 空闲周期或应答TestRequest | TestReqID（应答时） |
| TestRequest | 1 | 超时未收到消息 | TestReqID |
| ResendRequest | 2 | 序号缺口 | BeginSeqNo、EndSeqNo |
| SequenceReset | 4 | 补发跳过或强制重置 | NewSeqNo、GapFillFlag |
| Logout | 5 | 主动关闭 | Text |
三、案例场景：行情网关的补发实战
假设行情网关期望接收序号为105，但收到对方发来的序号为110的增量行情。此时网关立即发送ResendRequest，BeginSeqNo=105，EndSeqNo=109。对方收到后，将105至109的消息重新发送；若其中某些消息已过期（如快照已被覆盖），则用SequenceReset（GapFillFlag=Y）填充，NewSeqNo指向110，表示“这些序号请直接跳过”。网关收到后把期望序号推进到110，会话恢复正常。
8=FIX.4.4|9=...|35=2|34=50|49=GW|56=BROKER|
7=105|16=109|10=xxx|
# 对方响应
8=FIX.4.4|9=...|35=4|34=105|49=BROKER|56=GW|
123=Y|36=110|10=xxx|四、误区与复盘
- 误区一：把Heartbeat当成业务心跳。Heartbeat只证明链路和会话层存活，不代表行情数据在更新。行情停滞需另设业务级监控。
- 误区二：忽略ResetSeqNumFlag。若双方对是否重置序号理解不一致，会导致启动即大量ResendRequest，甚至死循环。
- 误区三：SequenceReset滥用。用Reset强制跳号会掩盖真实丢包，应优先使用GapFill，仅在确认消息永久丢失时重置。
- 误区四：Logout后立即重连。应等待对方Logout确认或超时，避免序号状态混乱。
掌握这些会话管理流程后，行情接入就不再是“连上就能收”，而是具备可观测、可恢复、可诊断的工程能力。后续解析应用层报文时，才能把精力集中在数据本身，而不是被会话异常反复打断。