通信协议是通信双方进行交互时所约定的标准语言，部标808协议和809协议、796和794标准虽然都是交通部主持设计的，但是单从这个数字代码，让人迷惑，理解这两个协议和两个标准，对于掌握整套部标标准，起着至关重要的作用。
1.通信场景：
他们是基于不同的通信场景，不同的通信对象，不同的设计目的和目标而制定出来的。首先要知道这些标准的全称是什么意思，Jt808标准的全称是《道路运输车辆卫星定位系统终端通讯协议及数据格式》,jt809标准的全称是《道路运输车辆卫星定位系统平台数据交换》，796标准的全称是《道路运输车辆卫星定位系统平台技术要求》，794标准的全称是《道路运输车辆卫星定位系统车载终端技术要求》，从字面意思就很容易理解到：808协议适用于GPS定位车载终端和监控平台之间的通信。通信协议采用 TCP或 UDP，平台作为服务器端，终端作为客户端，而809协议则是适用于企业的GPS监控平台与政府运管平台之间的交互通信，通信协议限定为TCP协议，企业监控平台明确为协议中的下级平台，政府运管平台明确为上级平台。交通部796标准是软件平台的功能标准，794则是终端的功能标准。
2.应用场景：
如果你获取GPS定位数据，是从终端接入获取的，就使用或者开发808Gps服务器，参见:基于Java Netty框架构建高性能的部标808协议的GPS服务器
如果你需要从第三方平台获取GPS定位数据，即接入第三方平台，就需要使用或者开发809Gps服务器。参见:基于部标Jt/T809协议和Java Netty框架构建Gps位置监控平台
如果需要给其他平台转发数据，则可以根据双方约定，可以使用809协议转发，也可以用808协议转发，协议本来就是双方约定遵守的规则，只要双方同意，即使不用808809，自己设计协议也可以。
如果你是开发终端，需要阅读794标准和808协议文档。
如果你是开发平台的，需要阅读796功能标准和808协议、809协议文档，通常一个标准的796平台，包含808服务器，809服务器和web平台，参见：交通部796部标平台开发索引
3.包含关系：
既然796是平台的全面综合功能标准，则其中的一项要求必然是符合808协议标准，能够接入符合808协议的车载终端，所以796标准是包含808协议标准，符合796标准的平台必然能够接入符合808协议的车载终端，但反过来能接入部标终端的平台不一定是符合796的功能标准，特别是web平台的功能标准，需要经过部标平台检测后，才能认定为796平台。
794是终端硬件设备的全面综合功能标准，必然也是包含808协议标准，必须能够接入部标平台当中。
由于现在终端设备都是GPS和行车记录仪是一体化的一体机，所以在808协议中，对记录仪协议的标准进行了封装，即消息体用的是记录仪标准19056. 也就是说部标终端必然是符合GB/T 19056 汽车行驶记录仪 标准的终端。
部标协议和北斗标准的区别，参见文章：北斗和交通部部标808的关系
4.通信链路的区别：
部标808协议是一个链路全双工通信，连接的维持，靠心跳包，实际上都是这么设计的也没有什么可说的。
唯独809协议的设计者估计是个纸上谈兵的家伙，设计一个变态的双链路机制，设计了主链路和从链路，设计比较复杂，实现难度也比较大，部标检测中这一环节耗时多，也容易失败。
实际开发过程中，主从链路的建立、维持、管理以及那些命令从主链路下发，那些命令从从链路下发，都容易把开发者搞的七荤八素的，耗费了不少的时间。如果是开发上级平台，更加麻烦，一个上级平台对应多个下级平台，每个交互都要构建两个连接。809的缺点是设计太过于复杂，前戏太多，很多政府运管平台都特别的不稳定，三天两头的重启，坑苦了下级的企业平台接入。
双链路的设计也是非常滑稽的，一个链路本来就是全双工通信，两个链路并不能增加平台的通信连接稳定。因为如果两侧无论那一侧挂机，再多的链路设计也是白扯，都会断掉。
