支持方
JavaScript
SGC 默认协议和 MQTT 实现了消息投递的 QoS（服务质量）。共有 3 种类型：
Level 0："至多一次"，消息按底层 TCP/IP 网络的最大努力投递。可能发生消息丢失或重复。该级别可用于例如环境传感器数据的场景，因为单次读数的丢失无关紧要，下一次读数很快会被发布。
级别 1："至少一次"，消息保证到达，但可能出现重复。
第 2 级："精确一次"，消息保证恰好到达一次。例如，在计费系统中可使用此级别，因为重复或丢失的消息可能导致错误的收费。
消息根据底层 TCP/IP 网络的尽力传输原则投递。协议中未定义响应期望和重试语义。消息到达服务器时，要么仅一次，要么根本不到达。
下表显示 QoS 级别 0 的协议流程。
| Client | 消息和方向 | 服务器 |
|---|---|---|
| QoS = 0 | PUBLISH ----------> |
操作： 向订阅者发布消息 |
服务器通过 ACKNOWLEDGEMENT 消息确认收到消息。如果通信链路或发送设备发生已识别的故障，或在指定时间内未收到确认消息，则发送方将重新发送消息。消息将至少到达服务器一次。
QoS 级别 1 的消息在消息中有消息 ID。
下表显示了 QoS 级别 1 的协议流程。
| Client | 消息和方向 | 服务器 |
|---|---|---|
| QoS
= 1 Message ID = x 操作： 存储消息 |
PUBLISH ----------> |
操作：
|
| 动作： 丢弃消息 | ACKNOWLEDGEMENT<---------- |
若客户端未收到确认消息（在应用程序定义的时间段内，或检测到故障且通信会话被重启），客户端可重新发送 PUBLISH 消息。
QoS 级别 1 以上的附加协议流程确保不会向接收应用程序传递重复消息。这是最高级别的交付，适用于不能接受重复消息的情况。虽然网络流量会增加，但由于消息内容的重要性，这通常是可以接受的。
QoS 级别为 2 的消息在消息中包含消息 ID。
下表展示了 QoS 级别 2 的协议流程。对于接收方应如何处理 PUBLISH 流，有两种可用的语义。
| Client | 消息和方向 | 服务器 |
|---|---|---|
| QoS
= 2 消息 ID = x 操作： 存储消息 |
PUBLISH ----------> |
Action： 存储消息 |
PUBREC <---------- |
消息 ID = x | |
| 消息 ID = x | PUBREL ----------> |
操作：
|
| 动作： 丢弃消息 | 确认应答 <---------- |
消息 ID = x |
如果检测到失败，或在定义的时间段之后，将从最后一条未确认的协议消息重新尝试协议流。额外的协议流确保消息只被投递给订阅者一次。