網(wǎng)絡(luò)的最大好處就是節(jié)省了時(shí)間。尤其是在商業(yè)活動(dòng)方面，更是有著突出的優(yōu)勢(shì)。隨著網(wǎng)絡(luò)的不斷演化，我們要求網(wǎng)絡(luò)的也就更多，慢慢地構(gòu)建網(wǎng)絡(luò)的協(xié)議也就越發(fā)復(fù)雜?，F(xiàn)在我們就來介紹一下Fix協(xié)議。Fix協(xié)議可以分兩大部分，會(huì)話層協(xié)議和業(yè)務(wù)層協(xié)議。

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

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

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

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

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

在 logon 階段完成后必須馬上檢查序列號(hào)，同步收發(fā)的消息，比如一端發(fā)送了消息但另一端沒收到，這時(shí)候需要重傳?？梢酝ㄟ^對(duì)比 logon 消息中的序列號(hào)和通信一方的期望收到的消息序列號(hào)來檢測(cè)消息漏收發(fā)。

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

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

possResend 和 possDupFlag 區(qū)別就是前者使用了新序列號(hào)發(fā)送老的消息，可以通過檢查消息中的域來確定是否已經(jīng)收到過改消息，比如 order 的 ID 等；后者是用老的序列號(hào)重發(fā)消息，可以直接檢查序列號(hào)來確定是否已經(jīng)收到過該消息，若已收到過了就丟棄該消息。logon 消息中有兩個(gè)字段 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委員會(huì)也留給了實(shí)施者相當(dāng)大的回旋空間，在這個(gè)空間內(nèi)實(shí)施者可以定義特殊的應(yīng)用需求。 在FIX協(xié)議包含兩個(gè)層面（會(huì)話層和應(yīng)用層）中，會(huì)話層主要任務(wù)是信息交換雙方的連接建立及保持、信息交換過程中的安全性、完整性和一致性，具體實(shí)施中，由于會(huì)話層對(duì)如何實(shí)現(xiàn)已經(jīng)有了明確描述，實(shí)現(xiàn)起來相對(duì)容易。

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

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