在我们的IoT解决方案中，在服务器端使用Azure IoT Hub，在设备端使用Azure IoT Client SDK，我们看到设备通过MQTT发送状态消息和IoT Hub收到消息之间的间歇性延迟。
在某些情况下，我们看到IoT Hub将消息排队62秒。
例如，下面的消息ID：5cfbe0ac-d987-3317-bda6-f63ec5fe562a
T1-T0 = 62秒
设备时间戳（T0）= 2017-12-13T12：31：12
物联网中心时间戳（T1）= 2017-12-13T12：32：14.3600000Z
问题：
消息传递到IoT Hub的原因可能是什么原因？
我们如何进一步挖掘（在内部组件中添加日志以确定延迟的确切位置）？
有什么建议吗？
示例物联网中心排队消息：{
“数据”：{
“属性”：[
{
“代码”：“STS”
“价值”：“1”，}
]
“类型”：“状态”
}，
“邮件ID”： “5cfbe0ac-d987-3317-bda6-f63ec5fe562a”
“协议”： “MQTT”，
“的 DeviceTimestamp ”： “1513168272”，
“EventProcessedUtcTime”： “2017-12-13T12：32：14.0683721Z”，
“的partitionid”：5，
“EventEnqueuedUtcTime”： “2017-12-13T12：32：14.3010000Z”，
“IoTHub”：{
“的MessageId”：空，
“的correlationID”：空，
“的 EnqueuedTime ”： “2017-12-13T12：32：14.3600000Z”，
“流ID”：空
}
}
更新：设备正在使用Azure Client SDK 1.1.27版。设备代码使用C语言编写。该设备不在防火墙后面或使用任何特殊的网络拓扑，它通过MQTT连接到IoT Hub。通过MQTT发送状态消息时会观察到延迟。
更新2：设备在使用Azure客户端SDK方法发送消息之前将时间戳添加到消息中。在大多数情况下，时间戳匹配，除非我们看到尖峰，例如以上信息。它使用NTP时间服务器计算时间戳并作为EPOCH发送。物联网中心位于更高层（10个单位）。
根据我们今天的分析，我们怀疑Azure客户端SDK。我们的假设是，我们认为SDK在尝试与IoT Hub建立连接时在内部（在列表或队列中）存储消息。如果它没有连接到IoT Hub，它会在几秒钟后重试。当它恢复连接时，它会传递存储在其队列中的消息（再次当消息被延迟时，我们看到一堆消息以相同的延迟组合在一起，这证明了这一假设）。