Bluetooth 蓝牙串口通信（SPP）

我们正在开发一个通过蓝牙使用SPP（串行端口配置文件）的应用程序，开发人员正在讨论使用某种类型的协议和数据包传输，而不是只传输没有任何形式的ACK、序列或大小信息的数据

---

蓝牙是否提供了有保证的传输和数据完整性，因此我们不需要数据包协议设计的开销？我们可以仅仅依靠蓝牙来确保数据的传输吗？

本质上，英国电信有自己的传输安全机制。然而，这一点同样重要——为了让您知道数据何时开始和结束，您应该使用数据包类型的传输，例如STX和ETX来界定每个数据包。有些加密狗有一个坏习惯，即在传输过程中出现时间延迟时重复最后发送的字节，但当遇到ETX或EOT时，它们将停止。

---

而且，为了您的系统安全，您还可以在数据包的末尾包含一个校验和。那你就很确定了

是否保证交货

交货的顺序是有保证的。这是由于蓝牙协议较低层内置了确认/序列编号方案。因此，在较低的一层，一个包被重新发送，直到它被确认。注意，这相当于停止和等待ARQ方案。如果超过超时时间，则认为连接已丢失（通常为30秒）

数据完整性有保证吗

蓝牙4.2引入了BT安全连接。这包括对每个传输的数据包进行消息完整性检查（MIC），接收端的MIC不匹配将触发重新传输，许多MIC不匹配可能会断开连接

所以，若您并没有使用安全连接功能，那个么完整性就并没有保证。有一种用于保护数据的16位CRC方案，但众所周知，在很长一段时间内会出现CRC转义（位翻转的方式使CRC保持正确）。但这种情况相对少见，而且发生在嘈杂的环境中。如果您的应用程序需要非常高的数据完整性，请使用SecureConnection或引入应用程序级完整性检查

请注意，SPP配置文件本身没有任何错误/序列检查，RFCOMM有一个8位FCS（帧检查序列），用于检查报头损坏。L2CAP流/重传模式有一个可选的16位FCS，涵盖L2CAP头和数据，请注意，基本L2CAP模式根本没有FCS

---

如果您有启用L2CAP FCS的选项，则在较低级别上有一个16位CRC+L2CAP层上有一个16位FCS+RFCOMM级别上有一个8位FCS将提供数据完整性，这对于大多数应用程序来说都足够好。但是，如前所述，如果它真的很关键，那么您需要引入额外的应用程序级完整性检查。

适用于Android环境，但更普遍地适用于SPP。谢谢！这很有帮助！：）