不少協(xié)議的使用都給我們帶來了巨大的便利。這個我想也是互聯(lián)網(wǎng)的最大的特點了。那么我們現(xiàn)在要介紹的就是FIX協(xié)議。那么這個協(xié)議的具體應用特點我們就來詳細說一下。Fix協(xié)議可以分兩大部分，會話層協(xié)議和業(yè)務層協(xié)議。

會話層定義了數(shù)據(jù)通信相關的協(xié)議，業(yè)務層定義了金融活動相關的業(yè)務數(shù)據(jù)結構。 Fix的會話層設計時候充分考慮了穩(wěn)定性，安全性，健壯性，高效性。穩(wěn)定性指會話協(xié)議中定義了心跳消息來維護會話連接，安全性指協(xié)議從消息結構上支持數(shù)據(jù)加密，出錯重傳指每個會話在兩個端點各自維護一套消息序列號，防止消息丟失，漏發(fā)漏收，出現(xiàn)這種情況只要檢查兩邊序列號的連續(xù)性就可以確定需要重傳哪些消息。

session的通信各方維護一個incomming和 一個outgoing 序列號。 Incomming 序列號用來檢測序列號是否亂序或跨越。心跳在 initiator 發(fā)送 logon 消息時候設置在心跳域上， acceptor 和 initiator 的心跳間隔時間一致。

Fix消息要按序列號從小到大順序處理，若收發(fā)過程中出現(xiàn)丟包則有兩種策略：重傳序列號出錯的包及以后所有收到得包；另一種是只重傳出錯的包； Fix協(xié)議沒有定義應答消息，使用序列號不連貫來檢測消息丟失，用 checksum，簽名或消息體長度來檢測消息錯誤；Logon階段，客戶端選擇了了一個加密密鑰，但服務器選擇了不同的密鑰放在返回的logon消息中，這時候客戶端還得發(fā)一個logon消息應答服務器端，兩個作用：

1). 讓服務器知道密鑰變更獲得了客戶端的響應；

2). 下面的消息開始要加密了

在 logon 階段完成后必須馬上檢查序列號，同步收發(fā)的消息，比如一端發(fā)送了消息但另一端沒收到，這時候需要重傳。可以通過對比 logon 消息中的序列號和通信一方的期望收到的消息序列號來檢測消息漏收發(fā)。

序列號最好每隔24小時重置一次，重置前要商量好哪一方來首先發(fā)送重置請求及發(fā)重置請求的時間。重置之前要一方首先發(fā)送 testrequest 消息，等待收 heartbeat 消息來確認連接是否正常，然后才發(fā)送 logon 消息，并把消息中的序列號重置域設為Y，并且序列號置為 1 ，接收方回復同樣消息，重置成功；Logout 之前需要發(fā)送 testrequest 消息強制心跳，檢測消息序列號是否連續(xù)， logout 消息發(fā)送出去之后，需要等待一段時間接收 logout 回應消息，這段時間讓雙方來處理序列號不一致的問題，一旦序列號同步之后 logout 接收者馬上發(fā)送回應的 Logout 消息， Logout 發(fā)起方收到回應后負責來關閉會話。

Fix4.4中在logon消息中加入了 NextExceptedSeqNumb 域，用來表示本方期望對方發(fā)過來的下一個序列號，這樣 logon 階段完成后直接就是漏發(fā)消息的重發(fā)，不需要再發(fā)送 testrequest, heartbeat和ResendRequest消息了。

possResend 和 possDupFlag 區(qū)別就是前者使用了新序列號發(fā)送老的消息，可以通過檢查消息中的域來確定是否已經收到過改消息，比如 order 的 ID 等；后者是用老的序列號重發(fā)消息，可以直接檢查序列號來確定是否已經收到過該消息，若已收到過了就丟棄該消息。logon 消息中有兩個字段 RAW Data Length 和 RAW data 用來存放認證需要的數(shù)據(jù)；FIX協(xié)議在具體的實施中已經就一些業(yè)務流程進行了規(guī)范，考慮到世界各地業(yè)務模式的差異和應用環(huán)境等不同，F(xiàn)IX委員會也留給了實施者相當大的回旋空間，在這個空間內實施者可以定義特殊的應用需求。 在FIX協(xié)議包含兩個層面（會話層和應用層）中，會話層主要任務是信息交換雙方的連接建立及保持、信息交換過程中的安全性、完整性和一致性，具體實施中，由于會話層對如何實現(xiàn)已經有了明確描述，實現(xiàn)起來相對容易。

應用層定義了具體的業(yè)務接口，同時也包含了在這些業(yè)務接口中的業(yè)務邏輯。所以，對應用層業(yè)界有多種看法。首先FIX協(xié)議應用層是一個標準的接口，這個接口可以用來定義機構之間（券商與券商、券商與交易所等）或機構內部的應用業(yè)務接口。其次它又不僅僅是一個接口。在這些應用層信息之間，包含著很明確的業(yè)務邏輯。我們可以這樣認為，F(xiàn)IX協(xié)議是一個帶有一個會話層應用接口。所以，F(xiàn)IX協(xié)議的實施，不僅是接口的統(tǒng)一規(guī)范，同時需要將業(yè)務邏輯延伸到信息交換的過程當中。通常，F(xiàn)IX協(xié)議的業(yè)務邏輯是通過FIX引擎（FIX Engine）來實現(xiàn)的。FIX引擎的主要功能是根據(jù)業(yè)務需求，生成相應的業(yè)務請求（信息），以點對點（可以經由第三方）的方式，最終將交換信息送達目標 FIX引擎；同時FIX引擎對接受的信息進行解析，在此基礎上，生成相應的應答信息。信息的解析過程，實際上是業(yè)務邏輯的實現(xiàn)過程。

它的任務是將FIX協(xié)議應用層接口所需的域信息從信息庫中取出，按FIX協(xié)議所要求的信息格式打成數(shù)據(jù)包，然后提交。首先，撇開FIX引擎會話層屬性，在應用層，F(xiàn)IX引擎具有上述特性；其次，F(xiàn)IX引擎在處理信息過程中是一個交互的過程，除原始的請求和廣播信息外，F(xiàn)IX協(xié)議的應答信息按照信息之間的業(yè)務邏輯生成數(shù)據(jù)包，在數(shù)據(jù)包生成過程中，同時會伴隨其他相關的信息交換，如一個訂單信息（Order-Single），它是在證券信息/行情信息/報價信息（IOI信息）等信息交互過程中而生成的；再次，在信息交換過程中，F(xiàn)IX引擎會遵循FIX協(xié)議的域、信息類型定義、數(shù)據(jù)字典約定以及相應的信息定格；最后，F(xiàn)IX引擎還會對信息交換雙方的自定義域和信息類型進行約定，這些約定會完整地貫穿于整個信息交換過程中。