工程思想——关于串口通讯协议帧数据的一些想法

前言：之前在学校上计算机网络这门课程时候，被里面的各种协议绕的头晕眼花，总以为这些协议都已经被前辈固定，后生们只要按照之前的协议老老实实收发数据就能解决一切，直到自己也有做东西时要自己编写通讯协议时，遇到了一大堆问题，也踩了不少坑，在这里写下来一些自己的思考。

1. 数据帧的起始

对于一个完整数据帧，在处理时候必须清楚知道每一帧数据的起始位置，这就是帧头/帧尾所起的作用。以下是两种常见的判定一个数据帧起始的方法：

1.1 帧头 + 长度

举一个串口屏通信的协议的例子，串口屏的通信协议被设计为：2个字节帧头+1个字节长度。并且串口通信缓冲区的数据接收方式是每收到一帧数据不管之前的数据是否被处理，总是完成新接收到的数据对旧数据的覆盖。这相当于，不管什么时候去缓冲区取数据，缓冲区的数据格式总是：
∣帧头1∣帧头2∣长度∣数据1∣数据2∣数据⋅⋅⋅∣|帧头1|帧头2|长度|数据1|数据2|数据···| ∣帧头1∣帧头2∣长度∣数据1∣数据2∣数据⋅⋅⋅∣
这样覆盖缓冲区数据的方式，适合的场景是：

状态数据变化缓慢的场景，比如：串口屏触摸按键时，触摸按下时电平变化时间>500ms。
在相邻两次数据变化间，能实现多次数据传送的场景，即数据传送速度很快的场景。这样可以保证对于一种相同的数据，能够在变化前被传送多次，确保接收方能够正确收到。

1.2 帧头 + 长度 + 帧尾

还有一种数据帧的采用了这样的设计：1个字节帧头+1个字节+1个字节帧尾。（之前考虑过为什么不采用1个字节帧头+1个字节帧尾方式，采用这种方式最大的弊端是如传输的数据中出现和帧头帧尾字节相同的数据时，会发生误判；如果加上长度，那么对于帧尾位置 = 帧头位置 + 长度，又多了一重判断，更为保险。）
∣帧头∣长度∣数据1∣数据2∣数据⋅⋅⋅∣帧尾∣|帧头|长度|数据1|数据2|数据···|帧尾| ∣帧头∣长度∣数据1∣数据2∣数据⋅⋅⋅∣帧尾∣
这种方式多用一个长度字节确定数据帧的起始，定位更加精确。它有的优点是：

它除了适合覆盖缓冲区的场景外，还适合新接收数据接在缓冲区后不覆盖旧数据的方式。对于程序来说，通过帧头和长度检查获取数据帧的起始位置很容易，但是在调试时人为观察数据缓冲区位置时(特别在不覆盖旧数据时)，帧头帧尾方式会更容易观察数据，降低调试难度。
很多场景中，数据都是块发送的。比如：VB程序中的MSComm有一个缓冲区，发送数据被放入发送缓冲区中，当满足一定条件时，整个缓冲区的数据一起被发送出去。如接收端想要提取出一帧数据，那么在帧头+长度的情况下，若出现数据字节和帧头字节相同情况下，则后一个数据字节被认为是长度字节，则取出的整一帧数据都是错误的；在帧头+长度+帧尾情况下，会多一重检验，降低错误率。

2. 校验

实际场景中传输数据时，周围环境总会产生很多干扰噪声，对于一些重要的数据，比如：控制高压继电器开关的控制位，在干扰情况下可能会产生重大事故。因此，数据校验必不可少。

2.1 字节校验 —— 以比特为单位

字节校验指的是对比特流(一个字节8个比特)进行校验，这种以比特为校验单位的校验都是由硬件电路完成的，常见的通信字节校验方法是奇偶校验。

2.2 数据帧校验 —— 以字节为单位

数据帧由一个个字节组成，因此在以字节划分的单元等级上再次进行校验得到的是一个校验码字节。最常见的校验方法是累加和校验，它将数据帧中所有的数据字节相加，取它的低字节数作为校验。每次接收方接收数据时，以同样的方式检验数据，若校验出错则丢弃数据，等待重传。

3. 故障代码

系统就和人一样，我们不能保证每个系统都不会有出错的时候，对于一些基础的错误，系统最好能自检，并且向通信的其他端发送信息，便于检错和纠错。所以一般通信协议中添加一个故障代码的保留位总是能很好的兼顾这一点。

4. 帧序列

对于接收数据有顺序性的数据，一定要增加帧序列字节。比如：发送一些实时绘点的数据，但因为数据量巨大，分多次发送，要求接收端接收后，还原原来的数据信息，并绘图。在有干扰、数据丢失情况下，帧序列能够帮助接收端很好的判断当前数据的顺序，若丢失数据还可以给发送端发送数据要求重传。

总结：

在自己设计通信协议时，选择 帧头 + 长度 + 帧尾方式，适应的场景方式更广
考虑到系统干扰性和容错性问题，校验字节和故障代码必不可少
若收到的数据字节在接收端有顺序性要求，一定要加帧序列字节