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

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

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

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

1). 讓服務(wù)器知道密鑰變更獲得了客戶端的響應(yīng)；

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

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

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

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

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

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

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