使用Event订阅Azure IoT Hub设备上下线，如果不发送消息，每隔一段时间会收到一次上下线通知：
所有的SDK的令牌有效期为默认60分钟，令牌续订有效期约为 85%，即 60*0.85= 50分钟左右， 在默认的SAS令牌到期后，如果没有任何流量来刷新token，则会遇到IoT Hub断开设备，设备再重连的情况。
如果要调试该状态，可以在IoT hub中配置 诊断设置 到Log Analytics工作区：
输出到Log Analytics工作区中：
在日志中输入如下指令，可以查询到 404104 和401003的设备 deviceDisconnect 和deviceConnect的事件，事件每50分钟左右出现一次。
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DEVICES" and ResourceType == "IOTHUBS"
| where Category == "Connections"
| extend parsed_json = parse_json(properties_s)
| extend SDKVersion = tostring(parsed_json.sdkVersion) , DeviceId = tostring(parsed_json.deviceId) , Protocol = tostring(parsed_json.protocol)
| distinct TimeGenerated, OperationName, Level, ResultType, ResultDescription, DeviceId, Protocol, SDKVersion
关于此现象官网的解释：
关于设备SDK 和云端如何保持连接的解释：
为了确保客户端/IoT 中心连接保持活动状态，服务和客户端会定期向对方发送一个 keep-alive ping。 使用 IoT SDK 的客户端按下表中定义的时间间隔发送 keep-alive：
按照 MQTT 规范，IoT 中心的 keep-alive ping 时间间隔是客户端 keep-alive 值的 1.5 倍。 但是，IoT 中心将服务器端最大超时限制为 29.45 分钟（1767 秒），因为所有 Azure 服务都绑定到了 Azure 负载均衡器 TCP 空闲超时（29.45 分钟）。
例如，使用 Java SDK 的设备会发送 keep-alive ping，然后失去网络连接。 230 秒后，设备会由于处于脱机状态而错过 keep-alive ping。 但是，IoT 中心不会立即关闭连接 - 它会再等待 (230 * 1.5) - 230 = 115 秒，然后再断开设备的连接，并显示错误 404104 DeviceConnectionClosedRemotely。
可设置的客户端最大 keep-alive 值为 1767 / 1.5 = 1177 秒。 任何流量都将重置 keep-alive。 例如，成功的 SAS 令牌刷新会重置 keep-alive。
参照官网：
关于设备连接/保持连接是否计费的问题：
使用 AMQP 或 MQTT 协议时，为建立连接而交换的消息和协商中交换的消息不收费。
参见：
https://docs.microsoft.com/zh-cn/azure/iot-hub/iot-hub-devguide-pricing?WT.mc_id=AZ-MVP-5003757
关于IoT Hub 能连接的最大设备数量
| 设备 | 可注册到单个 IoT 中心的设备和模块的总数上限为 1,000,000。 只能联系 Microsoft 支持部门来提高此限制。 |
但请注意，100万设备连接到云中，是需要一定时间的，这个受限于连接速率：
“设备连接” 限制控制与 IoT 中心建立新设备连接的速率。 “设备连接” 限制不控制同时连接的最大设备数。 设备连接 速率限制取决于为 IoT 中心预配的单位数。
例如，如果购买的是单一 S1 单位，则限制为每秒 100 个连接。 因此，若要连接 100,000 台设备，至少需要花费 1,000 秒（大约 16 分钟）。 但是，同时连接的设备数可与用户在标识注册表中注册的设备数相同。
具体的连接速率参考：
| 限制 | 免费、B1 和 S1 | B2 和 S2 | B3 和 S3 |
|---|---|---|---|
| 新设备连接（此限制适用于建立 新连接 的速率，而不是连接总数） |
高于 100/秒或 12/秒/单位 底线是100个连接/秒，两个 S1 单位是 2*12 = 24 个新连接/秒，该值< 100，则按100进行限制。 如果有 9 个 S1 单位，则你的单位就有 108 个新连接/秒 (9*12)。 |
120 个新连接/秒/单位 | 6,000 个新连接/秒/单位 |
此外，设备到云的消息发送也是有速率限制的：
在设计物联网系统时，要充分考虑这些限制条件，才能决定是将 S1 升级到S2 或者增加S1 的单元数。
| 限制 | 免费、B1 和 S1 | B2 和 S2 | B3 和 S3 |
|---|---|---|---|
| 设备到云的发送 | 100 个发送操作/秒或 12 个发送操作/秒/单位，具体取决于哪一个更高 例如，两个 S1 单位是 2*12 = 24/秒，但是在所有单位中至少有 100 个发送操作/秒。 如果有 9 个 S1 单位，则你的单位就有 108 个发送操作/秒 (9*12)。 |
120 个发送操作/秒/单位 | 6,000 个发送操作/秒/单位 |
| 云到设备的发送1 | 1.67 个发送操作/秒/单位（100 条消息/分钟/单位） | 1.67 个发送操作/秒/单位（100 个发送操作/分钟/单位） | 83.33 个发送操作/秒/单位（5,000 个发送操作/分钟/单位） |
| 云到设备的接收1 （仅当设备使用 HTTPS 时） |
16.67 个接收操作/秒/单位（1,000 个接收操作/分钟/单位） | 16.67 个接收操作/秒/单位（1,000 个接收操作/分钟/单位） | 833.33 个接收操作/秒/单位（50,000 个接收操作/分钟/单位） |
流量整形
为了应对突发流量，IoT 中心可在有限的一段时间内接受超出限制的请求。 其中的前几个请求会立即得到处理。 但是，如果请求数持续违反限制，IoT 中心会开始将请求放入队列，并以限制速率对请求进行处理。 此效应称为“流量整形”。 此外，此队列的大小受到限制。 如果违反限制的情况持续出现，队列最终将会填满，而 IoT 中心会开始拒绝请求并引发 429 ThrottlingException。
例如，如果你使用模拟设备每秒将 200 条设备到云的消息发送到 S1 IoT 中心（它限制为每秒发送 100 条 D2C 消息）。 在前一两分钟，消息会立即得到处理。 但是，由于设备发送的消息数持续超过限制，IoT 中心随后将每秒处理 100 条消息，并将剩余的消息放入队列。 此时你会注意到延迟增大。 最终，在队列填满后，你会开始收到 429 ThrottlingException，并且“限制错误数”IoT 中心指标会开始增加。 若要了解如何基于指标创建警报和图表，请参阅监视 IoT 中心。
参考：
