会话层定义了数据通信相关的协议，业务层定义了金融活动相关的业务数据结构。 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引擎对接受的信息进行解析，在此基础上，生成相应的应答信息。信息的解析过程，实际上是业务逻辑的实现过程。