MQTT

MQTT（消息队列遥测传输）是一种广泛采用的轻型消息传递协议，专为受限制的设备而设计。 Amazon IoT Core 对 MQTT 的支持基于 MQTT v3.1.1 规范和 MQTT v5.0 规范，但如 Amazon IoT 与 MQTT 规格的区别 中所述，有一些差异。作为此标准的最新版本，MQTT 5 引入了多项使基于 MQTT 的系统更强大的关键特征，包括新的可扩展性增强、通过原因代码响应改进的错误报告、消息和会话到期计时器，以及自定义用户消息标头。有关 Amazon IoT Core 支持的 MQTT 5 功能的更多信息，请参阅 MQTT 5 支持的功能。 Amazon IoT Core 还支持跨版本 MQTT（MQTT 3 和 MQTT 5）通信。MQTT 3 发布者可以向将接收 MQTT 5 发布消息的 MQTT 5 订阅者发送 MQTT 3 消息，反之亦然。

Amazon IoT Core 支持使用 MQTT 协议和基于 WSS 协议的 MQTT 且由客户端 ID 标识的设备连接。Amazon IoT 设备 SDKs 支持这两种协议，并且是将设备连接到 Amazon IoT Core的推荐方法。 Amazon IoT 设备 SDKs 支持设备和客户端连接和访问 Amazon IoT 服务所需的功能。设备 SDKs 支持 Amazon IoT 服务所需的身份验证协议以及 MQTT 协议和 MQTT over WSS 协议要求的连接 ID 要求。有关如何 Amazon IoT 使用 Amazon 设备连接的信息 SDKs以及支持的语言示例 Amazon IoT 的链接，请参阅使用设备与 MQTT 连接 Amazon IoT SDKs。有关 MQTT 消息的身份验证方法和端口映射的更多信息，请参阅协议、端口映射和身份验证。

虽然我们建议使用 Amazon IoT 设备 SDKs 进行连接 Amazon IoT，但这不是必需的。但是 SDKs，如果您不使用 Amazon IoT 设备，则必须提供必要的连接和通信安全。客户端必须在连接请求中发送服务器名称指示 (SNI) TLS 扩展。不包括 SNI 的连接尝试将被拒绝。有关更多信息，请参阅中的传输安全 Amazon IoT。使用 IAM 用户和 Amazon 证书对客户端进行身份验证的客户端必须提供正确的签名版本 4 身份验证。

在您的客户端连接之后，您可以使用监控和管理其 MQTT 客户端连接。 APIs有关更多信息，请参阅 管理 MQTT 连接。

使用设备与 MQTT 连接 Amazon IoT SDKs

本节包含指向 Amazon IoT 设备的链接 SDKs 和示例程序源代码的链接，这些程序说明了如何将设备连接到 Amazon IoT。此处链接的示例应用程序显示了如何 Amazon IoT 使用 MQTT 协议和通过 WSS 的 MQTT 进行连接。

MQTT 服务质量 (QoS) 选项

Amazon IoT 并且 Amazon IoT 设备 SDKs 支持 MQTT 服务质量 (QoS) 0 级别和。1MQTT 协议定义了第三级 QoS，即2级别， Amazon IoT 但不支持。只有 MQTT 协议支持 QoS 特征。HTTPS 通过传递查询字符串参数 ?qos=qos 来支持 QoS，其值可以是 0 或 1。

下表描述了每个 QoS 级别如何影响发布到消息代理和由消息代理发布的消息。

MQTT 持久性会话

持久性会话存储客户端尚未确认的服务质量（QoS）为 1 的客户端的订阅和消息。当设备重新连接到持久性会话时，该会话恢复，订阅恢复，并将在重新连接之前接收和存储的未确认的订阅消息发送到客户端。

存储消息的处理记录在 CloudWatch 指标和 CloudWatch 日志中。有关写入 CloudWatch 和 CloudWatch 日志的条目的信息，请参见消息代理指标和排队的日志条目。

创建持久性会话

在 MQTT 3 中，您可以通过发送 CONNECT 消息并将 cleanSession 标记设置为 0 来创建 MQTT 持久性会话。如果发送 CONNECT 消息的客户端不存在会话，则会创建一个新的持久性会话。如果客户端已存在会话，则客户端会恢复现有会话。要创建干净会话，您需要发送一条 CONNECT 消息，并将 cleanSession 标志设置为 1，当客户端断开连接时，代理将不存储任何会话状态。

在 MQTT 5 中，您可以通过设置 Clean Start 标志和 Session Expiry Interval 来处理永久性会话。干净启动控制连接会话的开始和上一会话的结束。当您设置 Clean Start = 1 时，会创建一个新会话，如果之前的会话存在，将终止之前的会话。当您设置 Clean Start = 0 时，连接会话将恢复之前的会话（如果存在之前的会话）。会话过期间隔控制连接会话的结束。会话过期间隔指定断开连接后会话将持续的时间（以秒为单位，4 字节整数）。设置 Session Expiry interval=0 可使会话在断开连接后立即终止。如果未在 CONNECT 消息中指定会话过期间隔，默认值为 0。

在 MQTT 5 中，如果设置 Clean Start = 1 和 Session Expiry Interval = 0，这相当于 MQTT 3 清理会话。如果设置 Clean Start = 0 和 Session Expiry Interval > 0，这相当于 MQTT 3 永久会话。

持久性会话期间的操作

客户端使用连接已确认 (CONNACK) 消息中的 sessionPresent 属性确定是否存在持久性会话。如果 sessionPresent 为 1，则存在持久性会话，并且在客户端收到 CONNACK 后将为客户端存储的所有消息传送给客户端，如重新连接到持久性会话后的消息流量中所述。如果 sessionPresent 是 1，则客户端无需重新订阅。但是，如果 sessionPresent 为 0，则不存在持久性会话，并且客户端必须重新订阅主题筛选条件。

客户端加入持久性会话后，它可以发布消息并订阅主题筛选条件，而无需在每个操作上附加任何标记。

重新连接到持久性会话后的消息流量

持久性会话表示客户端与 MQTT 消息代理之间的持续连接。当客户端使用持久性会话连接到消息代理时，消息代理会保存客户端在连接期间所做的所有订阅。当客户端断开连接时，消息代理将未确认的 QoS 1 消息和发布的新 QoS 1 消息存储到客户端订阅的主题。根据账户限制存储消息。超过限制的消息将被删除。有关持久消息限制的更多信息，请参阅 Amazon IoT Core 终端节点和配额。当客户端重新连接到其持久性会话时，将恢复所有订阅，并以每秒 10 条消息的最大速率将所有已存储消息发送到客户端。在 MQTT 5 中，如果具有消息到期间隔的出站 QoS 1 在客户端离线时过期，则在连接恢复后，客户端将不会收到过期的消息。

重新连接后，以每秒限制为 10 条已存储消息的速率将已存储消息与任何当前消息流量一起发送到客户端，直到达到 Publish requests per second per connection 限制。由于已存储消息的传递速率受到限制，如果会话在重新连接后有超过 10 条已存储消息要传递，传递所有已存储的消息将需要几秒钟的时间。

对于共享订阅者，如果群组中至少有一个订阅者使用持续会话，并且没有订阅者在线接收 QoS 1 消息，则消息将排队。消息的出队速度为群组中每个活跃订阅者每秒 20 条消息。有关更多信息，请参阅共享订阅消息队列。

结束持久性会话

持久性会话可通过以下方式结束：

在 MQTT 3 中，持久性会话过期时间的默认值为一小时，此设置适用于账户中的所有会话。

在 MQTT 5 中，您可以为 CONNECT 和 DISCONNECT 数据包上的每个会话设置会话过期间隔。

对于 DISCONNECT 数据包上的会话过期间隔：

持久性会话到期后重新连接

如果客户端在其持久性会话到期之前未重新连接到该会话，则该会话结束并丢弃其存储的消息。当客户端在会话到期后重新连接并将 cleanSession 标记设置为 0 时，服务会创建一个新的持久性会话。上一个会话中的任何订阅或消息都不可用于此会话，因为它们在上一个会话到期时被丢弃。

持久性会话消息费用

Amazon Web Services 账户 当消息代理向客户端或离线持续会话发送消息时，将向您收取消息费用。当具有持久会话的离线设备重新连接并恢复其会话时，存储的消息将传递到设备并再次向您的账户收费。有关消息定价的更多信息，请参阅 Amazon IoT Core 定价 - 消息收发。

通过使用标准限制增加过程，可以将默认的持久性会话到期时间延长 1 小时。请注意，增加会话过期时间可能会增加消息费用，因为额外的时间可能允许离线设备存储更多消息，而这些额外的消息费用将按标准消息收发费率计入您的账户。会话到期时间为大约时间，会话的持续时间最多可能比账户限制长 30 分钟；但是，会话时间不会短于账户限制。有关会话限制的更多信息，请参阅 Amazon Service Quotas。

MQTT 保留消息

Amazon IoT Core 支持 MQTT 协议中描述的RETAIN标志。当客户端在其发布的 MQTT 消息上设置RETAIN标志时， Amazon IoT Core 会保存该消息。然后可以将其发送给新的订阅者，通过调用 GetRetainedMessage 操作进行检索，并在 Amazon IoT 控制台中查看。

将 MQTT 保留消息存储在 Amazon IoT Core中的常见任务

Amazon IoT Core 保存设置了RETAIN标志的 MQTT 消息。这些 保留消息 被作为普通的 MQTT 消息发送给已订阅该主题的所有客户端，同时也被存储起来发送给该主题的新订阅者。

客户端需要特定的策略操作授权才能访问 MQTT 保留消息。获取有关使用保留消息策略的示例，请参阅 保留的消息策略示例。

本节介绍了涉及保留消息的常见操作。

账单和保留消息

从客户端、使用 Amazon IoT 控制台或通过调用发布带有RETAIN标记的消息会Publish产生Amazon IoT Core 定价-消息传送中所述的额外消息费用。

客户端、使用 Amazon IoT 控制台或通过调用检索保留的消息除了需要支付正常的 API 使用费外，还会GetRetainedMessage产生消息收费。Amazon IoT Core 定价-消息收发 中说明了此类额外费用。

在设备意外断开连接时发布的 MQTT Will消息 会产生 Amazon IoT Core 定价-消息收发 中说明的消息收发费用。

有关消息传递定价的更多信息，请参阅 Amazon IoT Core 定价 - 消息传递。

比较 MQTT 保留消息和 MQTT 持久会话

保留消息和持久性会话是 MQTT 的标准特征，使设备能够接收离线时发布的消息。持久会话中可以发布保留消息。本节介绍这些特征的主要方面及其如何协作。

有关持久性存储的信息，请参阅 MQTT 持久性会话。

使用保留消息，发布客户端可确定是否应在连接后保留消息并将其传送到设备，是否有上一个会话。存储消息的选择由发布者决定，存储的消息将传递给订阅 QoS 0 或 QoS 1 订阅的所有当前和将来的客户端。保留消息一次只保存一条给定主题的消息。

当帐户存储了最大数量的保留消息时， Amazon IoT Core 将对使用 RETAIN 集和大于 0 字节的有效负载发布的消息返回限制响应，直到删除一些保留消息且保留消息数不超过限制。

MQTT 保留了消息和 Amazon IoT 设备影子

保留消息和 Device Shadows 都保留来自设备的数据，但它们的行为不同，用途也不同。本节介绍它们的相似之处和不同之处。

MQTT Last Will and Testament（LWT）消息

Last Will and Testament（LWT）是 MQTT 中的一项特征。借助 LWT，客户端可以指定一条消息，当出现未启动的断开连接时，代理将该消息发布到客户定义的主题，并发送给订阅该主题的所有客户端。客户端指定的消息称为 LWT 消息或 Will 消息，客户端定义的主题称为 Will 主题。您可以指定当设备连接到代理时的 LWT 消息。通过在连接期间在 Connect Flag bits 字段中设置 Will Retain 标志，可以保留这些消息。例如，如果 Will Retain 标志设置为 1，则 Will 消息将存储在代理中的关联 Will 主题中。有关更多信息，请参阅 Will 消息。

管理客户端连接时，您可以控制在断开客户端连接时是否发布 LWT 消息。有关更多信息，请参阅 管理 MQTT 连接。

代理将存储 Will 消息，直到出现未启动的断开连接。发生这种情况时，代理将向所有订阅 Will 主题的客户端发布消息以通知断开连接。如果客户端使用 MQTT DISCONNECT 消息通过客户端启动的断开连接来断开与代理的连接，则代理不会发布存储的 LWT 消息。在所有其它情况下，将分派 LWT 消息。有关代理发送 LWT 消息时的断开连接场景的完整列表，请参阅连接/断开连接事件。

使用 ConnectAttributes

ConnectAttributes 允许您在 IAM policy 中指定要在连接消息中使用的属性，如 PersistentConnect 和 LastWill。借助 ConnectAttributes，您可以构建默认情况下不允许设备访问新特征的策略，这在设备受到威胁时很有帮助。

connectAttributes 支持以下特征：

默认情况下，您的策略具有非持久性连接，并且没有为此连接传递任何属性。如果您想要具有持久连接，则必须在 IAM 策略中指定持久连接。

管理客户端连接时，您可以查看已连接客户端的连接属性和会话配置。有关更多信息，请参阅 管理 MQTT 连接。

有关 ConnectAttributes 示例，请参阅连接策略示例。

MQTT 5 支持的特征

Amazon IoT Core 对 MQTT 5 的支持基于 MQTT v5.0 规范，但有一些区别，如中所述。Amazon IoT 与 MQTT 规格的区别

共享订阅

Amazon IoT Core 支持 MQTT 3.1.1 和 MQTT 5 的共享订阅。共享订阅允许多个客户端共享一个主题的订阅，并且只有一个客户端会收到使用随机分布发布到该主题的消息。共享订阅可以有效地在多个订阅者之间对 MQTT 消息进行负载平衡。例如，假设您有 1000 台设备发布到同一个主题，有 10 个后端应用程序正在处理这些消息。在这种情况下，后端应用程序可以订阅同一个主题，并且每个应用程序都将随机接收设备向共享主题发布的消息。这实际上是“共享”这些消息的负载。共享订阅还可以提高弹性。当任何后端应用程序断开连接时，代理会将负载分配给组中剩余的订阅用户。当所有订阅者断开连接时，消息将排队。

消息队列功能可用于 MQTT 3.1.1 和 MQTT 5 连接上的共享订阅，以增强消息传输的可靠性。

要使用共享订阅，客户需要按如下方式订阅共享订阅的主题过滤器：

$share/{ShareName}/{TopicFilter}

具有相同内容的订阅{ShareName}/{TopicFilter}属于同一个共享订阅组。您可以创建多个共享订阅组，并且不要超过每个群组的共享订阅限制。有关更多信息，请参阅 Amazon 一般参考中的 Amazon IoT Core 端点和配额。

下表比较了非共享订阅和共享订阅：

sports/tennis
sports/#

$share/consumer/sports/tennis
$share/consumer/sports/#

非共享订阅流程	共享订阅流程

使用共享订阅的重要注意事项

有关共享订阅限制的更多信息，请参阅《Amazon 一般参考》中的Amazon IoT Core 终端节点和配额。要在Amazon IoT 控制台中使用 Amazon IoT MQTT 客户端测试共享订阅，请参阅在 MQTT 客户端中测试共享订阅。您还可以使用客户端连接管理功能查看已连接的客户端订阅了哪些主题，包括共享订阅。有关更多信息，请参阅 管理 MQTT 连接。有关共享订阅的更多信息，请参阅 MQTTv5 .0 规范中的共享订阅。

共享订阅消息队列

为了增强消息传送的可靠性，共享订阅包括消息队列功能，可在没有在线订阅者可用时存储消息。当共享订阅组中至少包含一个具有持续会话的成员时，将为该群组启用队列功能。分发邮件时，会选择在线成员作为收件人。当找不到在线成员或订阅者超过限制时，QoS 1 消息将排队。Publish requests per second per connection当现有成员恢复其持续会话或新成员加入群组时，就会传送排队的消息。每个活跃的群组订阅者以每秒最多 20 条排队消息的速度传送排队的消息，以及根据订阅向订阅者传送的任何其他消息。

默认情况下，排队的消息保留遵循Persistent Session expiry period配额。但是，如果在入站发布消息中设置了消息到期间隔 (MEI)，则 MEI 优先。如果存在 MEI，则无论持续会话的到期时间长短，它都会确定消息的保留期。

消息队列速率受Queued messages per second per account配额限制，消息数量受Maximum number of queued messages per shared subscription group配额限制。

当超过这些限制时，仅保留在达到限制之前已经排队的消息。超过限制的新传入消息将被丢弃。系统不会将较旧的队列消息替换为较新的消息。

消息队列记录在 CloudWatch 指标和 CloudWatch 日志中。有关写入 CloudWatch 和 CloudWatch 日志的条目的信息，请参见消息代理指标和排队的日志条目。排队的消息仍按标准消息费率计费。有关消息定价的更多信息，请参阅 Amazon IoT Core 定价。

共享订阅组中的会话生命周期

当一个干净的会话订阅群组时，它就会成为该群组的在线成员。当它取消订阅或断开连接时，干净的会话就会离开群组。

当持续会话订阅群组时，它就会成为该群组的在线成员。断开连接后，它仍保留在群组中，但会成为群组的脱机成员。当它重新连接时，它会再次成为在线会员。永久会话在群组明确取消订阅或断开连接后过期时会离开群组。

干净启动和会话过期

您可以使用“干净启动”和“会话过期”来更灵活地处理持久性会话。干净启动标志指示是否应在不使用现有会话的情况下启动会话。会话过期间隔指示断开连接后会话保持多长时间。可以在断开连接后修改会话过期间隔。有关更多信息，请参阅 MQTT 持久性会话。

全部显示原因代码 ACKs

您可以使用原因代码更轻松地调试或处理错误消息。消息代理根据与代理的交互类型（订阅、发布、确认）返回原因代码。有关更多信息，请参阅 MQTT 原因代码。有关 MQTT 原因代码的完整列表，请参阅 MQTT v5 规范。

话题别名

您可以将主题名称替换为主题别名，主题别名是一个双字节整数。使用主题别名可以优化主题名称的传输，从而有可能降低计量数据服务的数据成本。 Amazon IoT Core 默认限制为 8 个主题别名。有关更多信息，请参阅 Amazon 一般参考中的 Amazon IoT Core 端点和配额。

消息到期

您可以向已发布的消息添加消息过期值。这些值表示以秒为单位的消息到期间隔 (MEI)。如果未在该间隔内将消息发送给订阅者，该消息将过期并被删除。如果不设置消息过期值，消息会过期。

在出站时，订阅者将收到一条消息，其中包含到期间隔内的剩余时间。例如，如果入站发布消息的消息过期间隔为 30 秒，并且在 20 秒后路由到订阅者，则消息过期字段将更新为 10。订阅者收到的消息的更新后的 MEI 可能为 0。这是因为只要剩余时间为 999 毫秒或更短，它就会更新为 0。

在中 Amazon IoT Core，最小 MEI 为 1。如果从客户端将间隔设置为 0，则间隔将调整为 1。最长消息过期间隔为 604800（7 天）。高于此值的任何值都将调整为最大值。

在跨版本通信中，消息过期的行为由入站发布消息的 MQTT 版本决定。例如，对于订阅会话的设备，通过连接的会话发送的带有 MQTT3消息到期的消息 MQTT5 可能会过期。下表列出了消息过期如何支持以下类型的发布消息：

其它 MQTT 5 特征

服务器断开连接

断开连接时，服务器可以主动向客户端发送 DISCONNECT，以通知连接关闭，同时发送断开连接的原因代码。

请求/响应

发布者可以请求接收方在收到时向发布者指定的主题发送响应。

最大数据包大小

客户端和服务器可以独立指定它们支持的最大数据包大小。

负载格式和内容类型

发布消息时，您可以指定负载格式（二进制、文本）和内容类型。这些消息将被转发给消息的接收者。

MQTT 5 属性

MQTT 5 属性是 MQTT 标准的重要补充，用于支持 MQTT 5 的新功能，例如会话到期和模式。 Request/Response 在中 Amazon IoT Core，您可以创建可以转发出站消息中的属性的规则，或者使用 HTTP Publis h 发布带有某些新属性的 MQTT 消息。

下表列出了所有 Amazon IoT Core 支持的 MQTT 5 属性。

MQTT 原因代码

MQTT 5 引入了改进的错误报告和原因代码响应。 Amazon IoT Core 可以返回原因代码，包括但不限于以下按数据包分组的内容。有关 MQTT 支持的原因代码的完整列表，请参阅 MQTT 5 规范。

Amazon IoT 与 MQTT 规格的区别

尽管消息代理的实施基于 MQTT v3.1.1 规范和 MQTT v5.0 规范，但与这些规范有如下区别：

管理 MQTT 连接

Amazon IoT Core APIs 提供帮助您管理 MQTT 连接，包括断开客户端连接和管理其会话的功能。这些功能使您可以更好地控制 Amazon IoT 客户机群，并帮助解决连接问题。

DeleteConnection API

使用 DeleteConnection API Amazon IoT Core 通过指定 MQTT 设备的客户端 IDs，将其与 MQTT 设备断开连接。断开客户端 Amazon IoT Core 连接时，会断开客户端与 Amazon IoT Core 消息代理的连接，并且可以选择清理会话状态并隐藏 “遗嘱” (LWT) 消息。

当您调用 DeleteConnection API 时， Amazon IoT Core 会执行多项操作以确保断开连接。 Amazon IoT Core 首先向客户端发送 MQTT 断开连接消息以终止 MQTT 会话。然后，该服务会关闭底层 TCP/TLS 套接字。

消息代理向设备发送DISCONNECT数据包，并发布带有断开连接原因的生命周期事件API_INITIATED_DISCONNECT。这可以帮助您确定何时断开连接是通过 API 发起的，而不是由客户端发起的，或者是由于网络问题引起的。您可以监控这些事件，以实现可见性、故障排除和审计目的。例如，您可以使用 Amazon IoT 规则来处理这些事件，以跟踪客户端断开连接的时间和原因。

如果将cleanSession参数设置为true，则会 Amazon IoT Core 移除客户端的会话状态，包括所有订阅和排队消息。如果您清理会话，则永久会话将终止。如果客户端是持久会话并且preventWillMessage参数设置为false，则服务会调度 LWT 消息（如果有），这在计划的维护操作中很有用。

当您调用 DeleteConnection API 时，断开连接过程会立即开始，但是客户端识别断开连接的确切时间可能会因网络条件和客户端实现而异。大多数客户端会在几秒钟内检测到断开连接，但在某些情况下，如果网络连接不佳，客户端可能需要更长的时间才能识别出已断开连接。

有关定价的信息，请参阅 Amazon IoT Core 定价。

使用案例

该 DeleteConnection API 可用于管理表现出问题行为或消耗过多资源的行为不端的客户端。通过强制断开连接，可以确保客户端通过适当的身份验证和授权重新建立连接，这有助于解决资源消耗问题。

客户端重定向场景也受益于此 API。当你需要将客户端重定向到不同的终端节点时 Amazon Web Services 区域，你可以通过编程方式断开它们的连接，然后通过更改 DNS 设置让它们重新连接到不同的 Amazon IoT Core 终端节点。此 API 可以帮助解决连接卡住问题或清除可能阻碍正常操作的有问题的会话状态。

API 参数

DeleteConnectionAPI 接受以下参数：

API 语法

该 DeleteConnection API 使用以下 HTTP 请求格式：

DELETE /connections/<clientId>?cleanSession=<cleanSession>&preventWillMessage=<preventWillMessage> HTTP/1.1

请求示例：

// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1

// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1

// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1

成功的请求会返回 HTTP 200 OK，但没有响应正文。

所需的权限

要使用该 DeleteConnection API，您需要获得以下 IAM 权限：

iot:DeleteConnection

您可以使用基于资源的策略将此权限范围限定到特定的客户端 IDs 。例如：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:DeleteConnection",
            "Resource": "arn:aws:iot:region:account:client/myDevice*"
        }
    ]
}

重要注意事项

除非您已实现其他逻辑来防止重新连接，否则已断开连接的客户端可以立即尝试重新连接。断开连接操作仅终止当前连接，不会阻止连接重新连接。如果您需要防止重新连接，请考虑实现客户端逻辑或禁用设备的凭证。

作为标准 API 速率限制的一部分，速率限制适用于 Amazon IoT Core API。在计划批量断开连接操作时，请确保考虑这些限制，并实施适当的重试逻辑和批处理策略以避免限制。有关更多信息，请参阅 Amazon IoT Core 终端节点和限额。

错误响应

DeleteConnectionAPI 可以返回以下错误响应：