协议设计
协议设计就像编写一首交响乐 🎵，需要优雅的结构、和谐的组合，更重要的是要让所有乐器（设备）都能顺畅地演奏出相同的旋律。
# 分析
# ✨ 优点
结构清晰，层次分明 表格里把字段名、字节数、大小端、内容说明都列得明明白白，开发的时候一看就懂，不会抓瞎。比如“STX”是起始标志，“CTRL”是控制字段，功能划分得很清楚。
功能覆盖全面 从起始标志（STX）到校验（CRC16），基本涵盖了通信协议的核心要素：
- 起始和结束：STX 和 CRC16 明确了数据包的边界。
- 控制和状态：CTRL 字段可以控制和反馈状态。
- 数据和标识：DATA 和 CMD_ID 用来承载具体内容和指令。
- 校验：CRC16 用来确保数据完整性，避免传输出错。
大小端明确 大小端标注得很清楚，比如 STX 是 2 字节，大端格式。这对跨平台通信特别重要，避免了字节序混乱的问题。
长度灵活 Data_Len 字段专门用来标记数据长度，支持可变长的数据包，灵活性很强，适合不同场景。
# 字段分析
STX（起始标志，0x5556，2字节，大端）
- 作用：标记数据包的开头，告诉接收方“嘿，我开始发数据了”。
- 如果 STX 设计不唯一（比如和数据内容冲突），可能会导致接收方找不到包的开头，数据解析直接崩。比如你以为是 STX，结果是数据里的 0x5556，那就乱套了。
- 评价：0x5556 是个固定值，2 字节大端，挺标准的，没啥大问题。
CTRL（控制字段，2字节，1字节内容）
- 内容解析：
- 0：need_ack（是否需要应答）
- 1：ack_pack（是否为应答包）
- 2-7：预留
- 作用：控制通信逻辑，比如需不需要对方回个消息，或者这是不是一个应答包。
- 目前只有 2 位用了，剩下 6 位预留。如果未来功能扩展不够用，可能会导致字段不够，或者得重新设计协议。
- 内容解析：
评价：功能明确，但预留位有点多，6 位感觉有点浪费，可以考虑用 1 字节就够了，节省空间。
Data_Len（数据长度，3字节，2字节内容）
- 作用：告诉接收方 DATA 字段有多长，方便解析。
- 2 字节可以表示 0-65535 的长度，范围很大，但如果实际场景中数据都很短（比如只有几十字节），用 2 字节有点浪费。如果数据超长（大于 65535），又会溢出，协议就得改。
- 评价：长度设计合理，但可以根据实际需求优化，比如数据长度通常小于 256 字节的话，1 字节就够了。
SEQ（序列号，5字节，2字节内容，0-65535）
- 作用：给数据包编号，避免乱序或者丢包。比如发了 10 个包，接收方可以用 SEQ 确认有没有漏。
- 2 字节的 SEQ 最大是 65535，循环使用时如果发包频率太高，可能会重复，导致接收方误判。还占了 5 字节，实际内容才 2 字节，浪费了 3 字节。
- 评价：功能必要，但空间分配不合理，2 字节内容就够了，没必要占 5 字节。
CMD_ID（命令ID，7字节，1字节内容）
- 作用：标识这是啥指令，比如“开灯”还是“关门”。
- 1 字节只能表示 256 种指令，如果系统复杂，指令种类多，可能会不够用。占了 7 字节也太夸张，6 字节浪费了。
- 评价：功能没问题，但空间分配太夸张，1 字节内容就够了。
DATA（数据，8字节，长度由 Data_Len 决定）
- 作用：承载实际的数据，比如传感器数值、文本啥的。
- 长度可变，设计上没啥问题，但如果 Data_Len 出错（比如传错了），DATA 解析就会乱套。
- 评价：设计合理，长度灵活，挺好。
CRC16（校验，2字节）
- 作用：校验数据完整性，确保传输过程中没出错。
- CRC16 是标准校验算法，误检率很低，没啥大问题。但如果数据包超长，CRC16 可能会不够强，建议大包用 CRC32。
- 评价：校验功能到位，小数据量够用了。
# 思考
场景：利用单次传输存在字节上限的方式（北斗短报文，二代单次只能上传< 80字节）进行电表信息的采集。
集中器汇集电表的数据，通过电磁波/485线的方式采集到每户电表的数据。统一由集中器进行上报传输。单个电表不具有联网的能力，只有集中器才有联网的能力。
一般这种场景，都是使用4G的方式进行传输。但是在一些偏远地区（如新疆边缘地带），不具备稳定的4G信号的这种场景。所以得有一些其他的传输方式。
北斗短报文即是这种的解决方案。通过卫星的方式传输数据。
优势 劣势 4G等主流的传输途径不可触及的场景，非常适合北斗短报文进行信息传输 单次的传输存在上限，< 80字节；民用传输极不稳定，非常容易丢包；指挥机虽然支持通播，但最快传输速度 > 60s 集中器传输数据，也不是一股脑进行采集传输。一般会按照二十个电表这样字符，大于2k字节数据这样为一帧。
使用短报文设计协议时，就得非常注意单次传输的大小，以及丢包如何进行补偿。且短报文还存在延时下发的硬性限制。
问题：大数据量；传输丢包情况；延时下发的限制
- 大数据量：使用压缩算法，终端获取到数据后，使用压缩算法先进行处理。压缩比能达到7 ~ 8 成
- 传输丢包情况：协议商定；上传的报文中涵盖主帧头（包含一共多少数量帧信息），分帧头（由分帧编号 + 剩余数据组成）；每一帧获取的时间设定超时限制，总超时时间一到，即开始组包，如果发现存在不完整的情况，下发请求丢包报文。获取丢包数据。重复这个流程，一直直到数据采集完成。
- 延时下发限制：由于北斗民用卡的限制，每次发送间隔 > 60s，所以得给下发的报文区分类型。不同类型的报文下发的优先级有区别。大约可分为：下发请求报文 > 超时获取主帧报文 > 超时获取分帧报文。
# 要点
设计物联网交互协议时，以下是需要考虑的关键要点：
低功耗：物联网设备通常具有有限的电池寿命，因此交互协议需要在通信过程中尽可能地减少功耗，从而延长设备寿命。
数据格式：数据格式应该能够满足设备之间的数据交换需要，并且易于解析和处理。可以采用JSON、XML、二进制等格式
安全性：物联网设备通常包含重要的数据和控制信息，因此交互协议需要确保这些信息在传输过程中得到保护。协议应该包括数据加密和身份验证等安全特性。
网络拓扑：物联网设备可以是分散的，且组成的网络可以采用各种不同的拓扑结构。交互协议应该考虑到这些因素，并能够适应不同的拓扑结构，如星形、网状、总线等。
互操作性：物联网设备通常来自不同的制造商，使用不同的通信协议和数据格式。因此，交互协议应该具有良好的互操作性，以便不同类型的设备可以相互通信。
带宽效率：物联网设备的网络带宽通常非常有限，因此交互协议需要设计为高效的数据传输方式，以确保数据传输的速度和效率。
灵活性：物联网设备和应用程序通常需要进行不同类型的交互。因此，交互协议应该是灵活的，并支持不同类型的交互，例如请求-响应、发布-订阅等。
可扩展性：物联网设备数量和种类可能会随着时间的推移而增加，因此交互协议应该设计为可扩展的，以便能够适应未来的增长。
以上是设计物联网交互协议时需要考虑的关键要点。这些因素需要根据具体的应用场景进行权衡和优化，以达到最佳的协议设计。