交易系統開發（十）——FIX協議

交易系統開發（十）——FIX協議

1、FIX協議簡介

一、FIX協議簡介

FIX（Financial Information eXchange Protocol，金融信息交換協議）是由國際FIX協會組織提供的一個開放式協議，目的是推進國際貿易電子化進程，在各種參與者之間，包括投資經理、經紀人、買方、賣方創建起實時的電子化通信協議。
FIX協議的目標是把各種證券金融業務需求流程格式化，成爲一個可用計算機語言描述的功能流程，並在每一個業務功能接口上統一交換格式，方便各個功能模塊的鏈接。
 2006年10月，FPL（FIX Protocol Ltd）發佈了FIX5.0，FIX5.0引入TI（the transport independence ）傳輸無關框架。TI將FIX會話層從應用層協議中分離出來。在TI框架下，應用層協議消息能夠經過任意合適的傳輸技術進行傳送，FIX會話層協議是FIX應用層消息的可選傳輸傳輸協議之一。兩個協議層的版本標註將會有所不一樣，FIX X.Y爲FIX應用層協議版本，應用層協議定義金融活動相關的業務數據結構；FIXT X.Y 爲FIX會話層協議版本編號，會話層協議定義數據通訊相關的協議。

二、FAST協議

爲了解決FIX協議傳輸市場數據存在的冗餘度高，帶寬需求大的問題，芝加哥商品交易所（CME）在2003年向FPL（FIX Protocol Ltd）提交了一個解決方案，FPL在2004年成立了市場數據優化工做組(MDOWG)，2005年MDOWG開始根據一些POC(Prove of Concept)的結果進行協議標準制定，並於2006年初完成了FAST(FIX Adapted for Streaming) V1.0，2006年12月完成了FAST V1.1。 
FAST協議核心是一個壓縮算法，將按照FIX規範定義的數據通過壓縮後，能夠在很大程度上下降發送、接收雙方的帶寬。
FAST協議的優勢是高壓縮比，低資源消耗，算法簡單高效，每秒百萬級別的消息處理能力。

三、STEP協議

STEP（Securities trading exchange protocol，證券交易數據交換協議）是基於FIX4.4版本FIX協議制定出來的中國本地化FIX協議版本，是中國國家金融行業標準，已成爲事實上的證券數據標準，其語法簡單定義靈活易擴展，數據相對冗餘。

四、Binary協議

Binary即二進制協議，定義了各類報文的字段、編解碼規則等。在深交所的Binary協議中，全部的消息都有3部分組成：消息頭，消息體和消息尾。消息頭有8個字節，包括整數MsgType和整數BodyLen，MsgType表示消息的類型，BodyLen表示消息體的長度；消息體根據BodyLen大小進行讀取；消息尾是4個字節的 checksum。

五、FIX協議的優缺點

FIX協議優勢是使用key-value對，能夠很方便地查看報文內容以及擴展新字段，國際通用，適應力強。
FIX協議缺點是速度慢。

2、FIX協議工做原理

一、FIX應用模式

FIX有Initiator和Acceptor兩種應用類型，Initiator是通訊發起者，經過發送初始Logon消息發起Session；Acceptor是FIX Session的接收方，負責執行第一層次認證和經過傳輸Logon消息響應確認正式鏈接請求被接受。
FIX協議規定Initiator是通訊發起者，Acceptor爲接受者。FIX標準應用模式以網關爲Acceptor，客戶端爲Initiator。

二、FIX Connection

FIX Connection由3部分組成：logon登陸，message exchange消息傳輸，logout註銷。

三、Fix Session

FIX Session由一個或多個FIX Connection組成，一個FIX Session能夠有屢次登陸。
一個FIX Session定義爲一個在鏈接雙方間的的帶有連續序列號的有序消息雙向傳輸流。單個FIX Session可以跨越多個連續（不是並行的）的物理鏈接。在一個FIX Session中，參與方可以屢次鏈接和斷開鏈接。鏈接的參與方必須根據單個系統及時間區域需求，公共協商Session的開始和結束。
建議一個新的FIX會話在每24小時期間創建一次，能夠維持24小時的鏈接和經過設置在Logon消息中的ResetSeqNumFlag創建一套新的序列號。
每一個FIX參與方必須爲FIX Session維護兩個序列號，一個是接收序列號，一個是發送序列號，二者都在創建FIX Session開始時初始化爲1。每一個消息被賦予一個惟一的序列號值，並在消息發送後遞增。此外，每一個收到的消息都有一個惟一的序列號，接收序列號計數器在收到每一個消息後將會被遞增。
當接收序列號與所但願獲得的的正確序列號沒必要配時，必須採起糾錯處理。

四、序列號

每條FIX消息都由一個惟一的序列號進行標識，序列號在每個FIX Session開始時被初始化爲1，並在整個Session期間遞增。監控序列號可使Session參與者識別和處理丟失的消息，當在一個FIX Session中從新鏈接時可以快速進行應用程序同步。
每一個Session將創建一組互不依賴的接收和發送序列。Session參與者將維護一個賦予發送消息的序列和一個監控接收消息的消息塊間隙序列號。

五、心跳

在消息交互期間，FIX應用程序將週期性產生Heartbeat心跳消息。心跳消息能夠監控通訊鏈路狀態及識別接收序列號間隙。Heartbeat消息的週期間隔由Session發起者使用在Logon消息中HeartBtInt域進行定義。
Heartbeat心跳消息的時間間隔應當在每個消息發送後復位，即發送一個消息後，在間隔給定的時間內無其它消息發送則發送一個Heartbeat心跳消息。HeartBtInt值應當被Session雙方認同，由Session發起方定義並由Session接收者經過Logon消息進行確認。同一個HeartBtInt被Session雙方——登陸的發起者和登陸的接受者共同使用。

六、數據完整校驗

消息數據內容的完整性能夠參用兩種方式來驗證：消息長度和校驗碼檢查。
程序經過計算BodyLength域到CheckSum標記（「10=」）分界符的字符數，域BodyLength標識的消息長度進行比較來完成完整性效驗。
ChekSum完整性檢查，經過計算從域「8=」 中「8」開始，包括緊跟在CheckSum標記域的分界符每一個字符的2進制和同CheckSum進行比較獲得。
一個FIX消息校驗和經過計算到ChechSum域（不包括）的消息的每一個字節和獲得。而後，校驗和被轉換爲模256的數字用於傳送和比較。校驗和在全部加密操做後被計算。
FIX消息示例以下：
8=FIX.4.29=7335=A34=149=CLIENT52=20181119-10:42:48.76856=SERVER98=0108=30141=Y10=208
消息長度：9=73，標識的消息體以下：
35=A34=149=CLIENT52=20181119-10:42:48.76856=SERVER98=0108=30141=Y

七、消息確認

FIX協議不支持單個消息的確認，採用監控消息時隙的方法來進行消息恢復和驗證。
普通的數據傳送（無單個消息確認）經過消息序列間隙進行錯誤識別。每一個消息由一個惟一的序列號進行標識。接收端應用程序負責監控接收消息序列號以識別消息間隙併產生重傳請求。

八、加密

加密算法由鏈接雙方共同協商。
一個消息的任何一個Field能夠被加密並放在SecureData Field中。然而，一些顯示的標誌域必須採用明文進行傳輸。爲確保完整性，明文域能夠在SecureData域中重複。
當使用加密時，建議全部的消息體都進行加密。若是一個消息中的循環組數據中的部分數據要加密，循環組必須所有進行加密。
預先協商好的加密算法在Logon消息中進行聲明。

九、自定義域

FIX協議爲給用戶提供最大的靈活性，其容許用戶自定義域。自定義域在認同的參與者之間實現、應用，所以須要注意避免衝突。
FIX協議規定，Tag在5000 到9999保留用於用戶自定義域，用於企業聯盟的信息交換，能夠經過FIX網站進行註冊；Tag在10000以上保留用於單一企業內部使用，不用註冊。

十、有序消息處理

FIX協議假設消息在全部參與者間徹底按照順序進行傳輸。協議的實現者在設計消息間隙填充處理時應當考慮順序傳輸假設。有兩種方式處理消息間隙。第一種是，要求接收的消息是最後一個接收消息的後續消息或在維護一個全部新消息有序序列時，請求特定丟失消息。好比：接收方丟失了5個消息塊中的第二個，程序能忽略第3到第5個消息，產生一個對消息2到消息5的重傳請求，或者從消息2到無窮大消息編號的重傳請求。第二種方式是，暫時存儲消息3到消息5，僅要求重傳消息2。

十一、重複消息

當一個FIX引擎對一個消息是否成功地被指定的目標接收或者當對一個重傳請求進行響應時，將會產生一個可能的消息複製。複製消息將用一樣的序列號進行從新傳送，此時在頭部的PossDupFlag域將會被設置爲‘Y’。接收端程序負責處理重發消息，能夠做爲一個新消息進行處理，或者根據實際狀況忽略該消息。
全部重傳請求的響應消息都將包含其值爲‘Y’的PossDupFlag域。沒有PossDupFlag域或者PossDupFlag域爲‘N’的消息應被看成初始傳送消息。PossDupFlag值爲‘Y’的重傳消息須要從新計算其CheckSum值。複製消息中發生變化的域包括：CheckSum，OrigSendingTime，SendingTime，BodyLength和PossDupFlag，加密相關域（SecureDataLen和SecureData）也必須被從新構造。

十二、消息重發

模糊的應用層消息可能隨同Po***esend標誌被重傳。當一個指令沒有在規定時間長度內進行確認或者終端用戶掛起該指令沒有進行傳送時這種方法很是有用。接收程序必須識別此標誌，並質疑其內部域以肯定該指令是否在以前已經被接收過。重傳消息將包含與原始消息相同的數據體，但包含Po***esend標誌和一個新的序列號。此外，CheckSum和與加密相關的域值須要重構。

3、消息類型

一、管理消息

管理消息（Adminitrative Message）是爲了信息交換過程更加順暢一致而使用的控制，包括登陸、心跳、檢驗請求、從新發送請求、拒絕(交換過程)順序重設及註銷等。

二、應用消息

應用消息（Application Messages）是交易的數據，包括以下數據：
公告：宣佈已完成的交易信息。
重要提示：告知由經紀人買賣的證券是由私人股份有限公司全部，仍是由代理持有，以及持有量。
消息：是經紀人和機構之間傳送的通常自由格式信息，帶有識別信息緊急性和商號主題詞分類標誌。
電子郵件：其格式和用途與消息信息相同，但更傾向於雙方非公開的用途。
報價請求：有些市場要求經紀人在每次訂單前提出報價。
報價與多宗報價：迴應報價請求的信息並用於發表主動的報價。
請求對多宗報價的確認：使用報價迴應水平標記，有選擇地支持對報價的確認。
報價撤銷：報價發起人用於撤銷報價。
報價情況請求：機構用來生成執行報告。
報價確認：針對報價、多宗報價、報價撤銷和報價請求，做出迴應。
行情數據請求：經過此請求獲得所指定的證券和外匯交易報價的行情數據。
行情數據—快照、徹底刷新：用於發送雙方的訂單登記簿、報價清單、交易清單、指數值、開盤價、收盤價、成交單價、最高價、最低價和變更加權平均價等。
行情數據—添加刷新：用於添加刷新請求。
行情數據請求拒絕：用於經紀人因交易或技術上的緣由不承兌行情數據請求的狀況。
證券定義請求：用於某一指定證券與第二方交易。
證券定義：接受或拒絕證券定義信息中請求的證券，發回證券及類型清單。
證券情況請求：用於提出有關證券情況的請求。
證券情況：提供有關證券情況改變的報告。
交易盤情況請求：請求有關市面情況的信息。
交易盤情況：提供有關市場情況的信息。
新訂單：機構向經紀人提供有關證券或外匯的訂單。
執行報告：確認收到訂單或訂單改變信息，傳遞訂單情況或訂單成交信息，報告交易的費用。
未知交易：通知交易方，收到的訂單已被執行。
訂單撤銷、替換請求：改變訂單的參數。
訂單撤銷拒絕：經紀人在不能承兌所收到的撤銷請求信息時發出的信息。
訂單情況請求：機構要求經紀人生成併發揮有關訂單情況的信息。
劃撥：指定如何將一個訂單或一組訂單細分爲一個或多個帳戶。
劃撥確認：確認收到機構發送的劃撥信息及狀態。
結算指令：經紀人或機構交易結算的指令。
出價請求：在非公開市場與公開市場，因市場規則不一樣用法也不一樣。
出價迴應：因兩個市場規則不一樣，有不一樣的用法。
新訂單—清單：因兩種市場規則的不一樣而不一樣。
敲訂價：交換本金交易的敲訂價。
情況清單：賣方以主動方式發送迴應情況清單請求信息。
清單執行：機構用於指示經紀人開始執行已被提交的證券訂單信息。
清單撤銷執請求：用於機構但願在執行交易盤以前或之中，撤銷已被提交的證券訂單消息。
情況清單請求：用於機構指示經紀人生成有關某一情況清單的信息。
清單訂單信息的分解：使用與其它FIX信息相同的方法，支持程序交易中的信息分解。
交易信息拒絕：拒絕因遵循了交易盤規則而不能以其它方式進行拒絕的應用層面的信息。

4、FIX協議

一、數據類型

FIX協議的數據類型包括整數int，浮點數float，字符char，布爾Boolean，字符串String，數據data。

二、Field

Field由Tag、Value和Delimeter組成，Delimeter用於分隔不一樣Field，如8=FIX4.1SOH，tag爲8，value爲FIX4.1，Delimeter爲SOH（0x01）。
常見Field以下：
Tag FieldName Description
8 BeginString 起始串，FIX協議版本
9 BodyLength 消息長度
35 MsgType 消息類型：例如F=Order Cancel Request，取消訂單
11 ClOrdID 客戶端訂單ID
37 OrderID 服務端訂單ID
41 OrigClOrdID 原始客戶端訂單ID
54 Side 買賣類型。例如：1 = Buy，2 = Sell
55 Symbol 股票代碼。例如：YRD
10 CheckSum 校驗碼

三、消息

FIX消息由多個Field組成，包括消息頭、消息體、消息尾三部分。
消息頭的前3個Field的次序不能改變，起始串(Tag=8)、消息體長度(Tag=9)、消息類型(Tag=35)。
消息尾的最後一個Field必須是校驗和Field(Tag=10)。
8=FIX.4.49=6335=034=115849=SAMPLESENDER52=20150201-00:22:34.99556=SAMPLETARGET10=114
循環組中，Field出現的順序應遵循循環組在消息或組件中定義時的次序；在一條FIX消息中，除循環組Field外任何其它Field不能重複出現。
因爲FIX消息有可能在公網或不安全的網絡上傳輸交換，所以須要對相關的敏感數據加密處理，具體加密的方法由鏈接雙方達成的協議而定。
FIX消息內除某些須要公開識別的Field以明文傳輸外，其它任何Field均可以加密放置密文數據域 (SecureData)內，被加密的Field也能夠同時保留明文的表示方式。
當決定使用加密方案時，能夠對FIX消息正文內全部的Field加密。若是消息的循環組內有部分須要加密的，那麼要求對整個循環組加密。
FIX協議還提供的一些Field用以支持數字簽名、密鑰交換和正文加密等安全技術。

四、消息頭

每個會話或應用消息有一個消息頭，消息頭指明消息類型、消息體長度、發送目的地、消息序號、發送起始點和發送時間。
Tag 域名 必需 說明
8 BeginString Y 起始串，取值:FIX.4.2(不可加密，消息的第一個域)
9 BodyLength Y 消息體長度(不可加密，消息的第二個域)
35 MsgType Y 消息類型(不可加密，消息的第三個域)
49 SenderCompID Y 發送方代碼(不可加密，發送方標識符)
59 TargetCompID Y 接收方代碼(不可加密，接收方標識符)
115 OnBehalfOfCompID N 最初發送方標識符(可加密)，用於經第三方發送。
128 DeliverToCompID N 最終接收方標識符(可加密)，用於經第三方發送。
90 SecureDataLen N 密文數據長度
91 SecureData N 密文數據(緊跟密文數據長度域)
34 MsgSeqNum Y 消息序號(可加密)，若是交易雙方不採用 FIX 會話 機制，可將該 tag 置爲一個固定的值，例如 0。
50 SenderSubID N 發送方子標識符(可加密)
142 SenderLocationID N 發送方方位標識符(可加密)
57 TargetSubID N 接收方子標識符(可加密)
143 TargetLocationID N 接收方方位標識符(可加密)
116 OnBehalfOfSubID N 最初發送方子標識符(可加密)
144 OnBehalfOfLocationID N 最初發送方方位標識符(可加密)
129 DeliverToSubID N 最終接收方子標識符(可加密)
145 DeliverToLocationID N 最終接收方方位標識符(可加密)
43 PossDupFlag N 可能重複標誌，重複發送時，做此標記。(可加密)
97 Po***esend N 可能重發標誌。(可加密)
52 SendingTime Y 發送時間(可加密)
122 OrigSendingTime N 原始發送時間(可加密)
347 MessageEncoding N 消息中 Encoded 域的字符編碼類型(非 ASCII 碼)
369 LastMsgSeqNumProcesse d N 最後處理消息序號(可加密)
370 OnBehalfOfSendingTime N 最初發送時間(用 UTC 表示時間)

五、消息尾

每個消息(會話或應用消息)有一個消息尾，並以此終止。消息尾可用於分隔多個消息，包含有3位數的校驗和值。
Tag 域名 必需 說明
93 SignatureLength N 數字簽名長度(不可加密)
89 Signature N 數字簽名(不可加密)
10 CheckSum Y 校驗和，消息的最末域。(不可加密)

六、新訂單消息

對於在消息頭中設置了Po***esend標誌的訂單消息，應當使用交易客戶方訂單編號(ClOrdID)覈實是否已收到該訂單，具體實現時還應檢查訂單參數(買賣方向、證券代碼、數量等)進行覈實。若是以前收到該訂單，應以執行報告消息迴應訂單狀態。若是以前未收到，則以執行報告消息迴應訂單確認。

七、執行報告消息

訂單回執包括訂單確認、訂單狀態變化確認(如撤單確認)、成交回報、
訂單拒絕。

八、訂單狀態請求消息

訂單狀態請求用於向交易服務方請求某訂單的狀態，交易服務方經過執行報告消息返回訂單狀態。

九、撤單消息

撤單消息用以撤消訂單的所有訂單剩餘數量。
撤單消息也被賦予一個ClOrdID，若是被拒絕，撤單拒絕消息的ClOrdID放置撤單消息的ClOrdID，而原始訂單的ClOrdID則放入OrigClOrdID域。ClOrdID要保證惟一。

十、撤單拒絕消息

本消息用於撤單消息的拒絕。交易服務方接收到撤單發現沒法執行(已成交訂單不可更改等)，將發送撤單拒絕。拒絕撤單時，撤單拒絕消息應用 ClOrdID 指示撤單的 ClOrdID，用 OrigClOrdID 指示以前最後接受的訂單(除非拒絕緣由是「未知訂單」)。Tag 域名 必需 說明標準消息頭 Y MsgType=937 OrderID Y 期貨公司委託號，同個交易日必需保證惟一11 ClOrdID Y 交易客戶方訂單編號41 OrigClOrdID Y 原始交易客戶方訂單編號，指示被撤消訂單的ClOrdID39 OrdStatus Y 訂單狀態109 ClientID Y 客戶資金賬號1 Account Y 客戶交易編碼60 TransactTime N 訂單發起時間434 CxlRejResponseTo N 撤單拒絕迴應類型102 CxlRejReason N 撤單拒絕緣由58 Text N 10 標準消息尾 Y