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

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

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

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

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

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

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

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

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

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

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

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