通信协议设计分析

68 阅读 0 评论 45 点赞

我是靠谱客的博主高兴月饼，最近开发中收集的这篇文章主要介绍通信协议设计分析，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

几乎任何项目都会涉及到通信，那么通信协议的设计就显得十分关键，目前就我个人来说串口网口为从字节流中取到正确的数据必须要开始通信协议的设计。

以下转载自原文转自：http://www.360doc.com/content/14/0915/11/1073512_409611008.shtml

转义字符几乎能保证99%的传输正确，除非硬件丢包太严重。

对于很多设备之间的通信，经常需要自己设计一套通信协议。当然此处的通信协议一般都是建立在TCPIP协议等协议基础之上的协议，也就是在已有协议的基础之上，在定义一套协议。例如：有一套检测降雨量的设备（一般为简单的嵌入式设备）需要把采集到的的数据上报给中心服务器（一般为一台性能特别好的计算机）。就需要一套通信协议。以保证，嵌入式设备上发的数据，可以被中心服务器正确的理解和处理。再例如：在桥梁检测的项目中，会检测很多桥梁的数据，应力，索力，温度等，这些检测设备一般都是由简单的传感器组成的嵌入式设备，需要通过各种方式把采集到的的数据上报给中心服务器，中心服务器经过分析处理后，再进一步判断桥梁的各种状态。这些都涉及到自定义通信协议。

但这些自定义通信协议如何设计？有设计到那些方面？

协议的设计，是为了保证双方能够正常的通信，由于上位设备和下位设备一般是不同的设备，处理能力有很大差异，这些都是设计协议必须考虑的问题。

一套完整的协议，通常包含很多命令，每一个命令都会规定一个完整的命令（也就是一个完整的数据帧）包含哪些部分，一般包含以下几部分：

1、数据帧的组成的形式

一般形式有字节流（有的地方也叫做二进制协议）和字符流。字节流一般会规定每一个字节表示的含义，而字符流由于都是可见的字符，一般会规定，字符的含义。

2、数据帧头和尾

数据帧头和尾其实是为了解析数据而设计的，主要是为了获取一个完整的帧。由于网络的不确定性，无法保证一条完整的数据帧的一次性就发送给对方。一般选择用很少出现的字节或者字符作为数据帧头和尾。

例如我曾经解析过得MODE 04 PROTOCOL的一套协议，就是以0x03，0x14开头的，由于MODE 04 PROTOCOL是字节流协议，因此规定了命令的开头两个字节是0x03，0x14，还曾经解析过字符流的协议，命令是以##开头。数据帧尾有时会有，有时没有，例如MODE 04 PROTOCOL就没有协议尾，因为它有两个字节表示本条数据帧的长度，所以没必要规定数据帧尾。相反，如果无法判断一条命令的长度，就会规定数据帧如何结束。如果数据帧长度都是一样的，也没有必要规定，但实际中很少遇到数据帧长度是固定的情况。

3、数据帧的验证部分

对于字节流的协议，一般会规定验证数据帧的验证部分，例如MODE 04 PROTOCOL就规定了数据帧最后两个字节是crc验证部分。

对于字符流的也可以加验证字段，但因为每一部分都都是可视的字符，也可以不加。

4、转义字符

再少出现的字符由于数据帧内容的不确定性，也有可能在数据帧内部出现，例如：MODE 04 PROTOCOL协议当数据帧内部出现了0x03，0x14，也就是数据帧规定的开始部分，就必须转义，否则就会解析出错。导致一个数据帧变成两部分不完整无法理解的数据帧。

5、命令字及其他

命令字就是标示此数据帧，需要完成的命令，例如：读取时间命令数据帧，就有一部分标示此数据帧是读取时间，设置时间命令数据帧就有一部分标示此数据帧是用来设置时间的，当然会有命令内容例如把时间调整到多少。

6、心跳包

心跳包作为一条很特殊的数据帧，作用其实和人的心跳类似。每隔一段时间，就会发送一条很特殊的数据帧心跳包。作用就是表明此设备还在工作。

例如QQ的在上状态应该就是通过类似心跳包的设计来完成的。但在无线领域还有其他作用，避免已经建立的链接断开。尤其数据是通过GPRS发送时，如果长时间不发送数据，网络运营商就会回收链接，下次发送数据时，就必须重新建立链接，这对于需要永远在线的设备或者是需要随时唤醒的设备来说，显然是不行的。

对比：

字节流协议难度显然比字符流大很多，解析过程也更复杂，如果没有协议文档，几乎不能解析，因为收到的就是一串毫无意思的数字，一个字节处理错误就完全可能导致整条数据解析错误，此外字节流还需要规定大端模式和小端模式等。当然好处就是，传输同样的信息，数据量明显少很多。