一、从一次设备掉线说起
你家里装了一个智能温湿度计，每天通过Wi-Fi把数据发到云端。刚开始用得很顺畅，可过了一两天，你突然发现手机App上不再更新温湿度了。打开后台一看，设备显示“未连接”。你走过去把设备断电再通电，它又好了。可没过多久，又掉线了。
这种问题不少人遇到过，尤其是自己用开发板做物联网项目的时候。根子往往不在网络，也不在硬件，而在于设备访问云平台的“通行证”——令牌过期了。今天我们就用大白话聊聊，怎么设计一套机制，让设备在令牌过期时能自己“续命”，而不是隔三差五需要你手动重启。
二、令牌到底是什么
在Azure IoT Hub里，设备要发数据，得先证明自己的身份。这个证明过程常见的方式是使用SAS令牌。SAS的全称是Shared Access Signature，翻译过来叫共享访问签名。你可以把它想象成一张景区门票，门票上写明了你是谁、你能去哪、什么时候失效。
一张典型的SAS令牌长这样：
SharedAccessSignature sr=hub-name.azure-devices.net%2Fdevices%2Fmy-device&sig=xxxx&se=1710000000&skn=registration
各参数含义如下：
sr：资源路径，表示这个令牌给哪个设备用。sig：签名，由设备密钥结合资源路径和过期时间计算出来，用来防伪造。se：过期时间，是一个Unix时间戳，表示令牌到什么时候作废。skn：策略名，可选项，一般用不到。
一张令牌生成之后，在有效期内可以反复使用。过期之后，服务器就不再认它了。就好比门票上写着“当日有效”，第二天你再拿着它进去，检票员一定拦你。
三、为什么令牌要设置过期时间
也许你会问，既然过期的麻烦，那干脆把令牌有效期设成一百年不就行了？不行的。
令牌就像家门钥匙。如果钥匙永远不换，一旦被人复制了一把，那你的家就永远处于风险中。IoT设备常常部署在外面，很多还暴露在公共网络上，被攻击者盯上的概率并不低。定期换钥匙，就算钥匙泄露了，攻击者能用它的时间也很有限。
另外，设备密钥可能会轮换。比如你主动重置了设备密钥，那么基于旧密钥生成的令牌就必须全部作废。如果令牌的有效期无限长，那旧密钥仍然能通过旧令牌访问云平台，这就失去了轮换的意义。
所以说，令牌设置过期时间是一种必要的安全措施。我们要做的不是取消过期，而是让设备在过期前或过期后能自动处理好。
四、过期之后设备端会发生什么
当设备拿着一个已过期的令牌去连接IoT Hub时，服务器会返回一个401错误，表示“未授权”。如果用这个令牌发送消息，服务器会拒绝，设备会看到类似Unauthorized的提示。
在设备SDK内部，一般会抛出异常或者触发连接断开。如果你的代码没有处理这种情况，设备就会一直处于断开状态，直到你主动干预。很多连接看起来“神秘掉线”的案例，其实就是令牌过期后没人管。
五、处理机制设计
设计一套好的令牌过期处理机制，核心思路就两条：一是尽量别让它过期，二是万一过期了也能快速恢复。下面分几个小节展开。
5.1 提前续期
最简单的思路：既然令牌有有效期，那我们就别等到它失效再去换。可以在令牌有效期内设一个“提醒闹钟”，比如令牌有效期是24小时，那我们每12小时就重新生成一张新令牌，然后用新令牌去更新连接。
这样做的好处是连接不会中断。在MQTT等长连接协议里，更新令牌一般不需要断开现有连接——SDK会在底层重新认证。提前续期可以有效避免因令牌过期导致的闪断。
5.2 过期后重连
如果真的没能提前发现，连接已经断了，那也不用慌。我们需要在代码里捕获连接错误，然后做三件事：
- 重新生成新的令牌（用当前时间、新的过期时间）。
- 用新令牌重新创建设备客户端。
- 重新连接，并恢复之前的订阅或发送逻辑。
这就像你拿着过期的门票被拒之门外，然后去售票处换一张新票再进去，完全行得通。
5.3 服务器端允许时钟偏移
有一种特殊情况：设备本地时间和服务器时间不一致。比如设备的时钟走得慢，它以为自己生成的令牌还有一分钟才过期，但服务器一看，过期时间已经过了。
为了应对这种时钟偏差，IoT Hub在验证令牌时通常允许一定的宽松窗口。但作为设备端，我们最好也不要卡着点续期。提前几分钟续期是比较稳妥的做法。假设令牌有效期是T，我们可以设一个“安全提前量”为5%或者固定300秒，在剩余时间小于这个值时就触发刷新。
5.4 使用设备SDK自动处理
好消息是，Azure IoT Hub官方提供的设备SDK已经内置了令牌刷新机制。比如在C# SDK中，你只需要在连接时传入认证方式，SDK会在后台自动管理令牌的生命周期。前提是你得使用支持自动刷新的认证方式，比如DeviceAuthenticationWithTokenRefresh。
这种方式省心，但也别完全黑盒依赖。理解底层机制，才能在出问题时知道去哪排查。
六、完整示例：一个带自动续期的设备客户端
下面我们用C#写一个模拟设备。它不仅能发送遥测数据，还能在令牌过期前自动续期，并且在连接断开后自动重连。请确保你的项目里安装了NuGet包：
# 安装Azure IoT设备SDK
dotnet add package Microsoft.Azure.Devices.Client --version 1.41.3
示例代码技术栈：.NET 8 + C#，使用官方物联网设备SDK。
using Microsoft.Azure.Devices.Client;
using System.Text;
using System.Text.Json;
// 模拟设备客户端，演示令牌自动续期与断线重连
class Program
{
// 1. 请替换成你在Azure门户复制的IoT Hub主机名
private static readonly string HostName = "my-iot-hub.azure-devices.net";
// 2. 设备ID，比如"dev01"
private static readonly string DeviceId = "dev01";
// 3. 设备主密钥，在Azure门户的设备详情页可以找到
private static readonly string DeviceKey = "你的设备密钥==";
// 保存当前设备客户端实例，供重连时使用
private static DeviceClient? deviceClient;
static async Task Main(string[] args)
{
Console.WriteLine("物联网设备启动，开始执行令牌自动续期演示");
// 使用SDK提供的自动令牌刷新认证方式
// 注意：这里不直接生成SAS令牌，而是让SDK底层负责生成和刷新
var auth = new DeviceAuthenticationWithTokenRefresh(
DeviceId,
DeviceKey,
TimeSpan.FromMinutes(30) // 令牌有效期为30分钟
);
deviceClient = DeviceClient.Create(
HostName,
auth,
TransportType.Mqtt
);
// 注册断线重连事件
deviceClient.SetConnectionStatusChangedHandler(OnConnectionStatusChanged);
// 开始连接
await deviceClient.OpenAsync();
Console.WriteLine("设备已连接，开始发送数据");
// 每10秒发送一次模拟温湿度数据
var timer = new PeriodicTimer(TimeSpan.FromSeconds(10));
int messageCount = 0;
while (await timer.WaitForNextTickAsync())
{
messageCount++;
await SendTelemetryAsync(messageCount);
// 连续发送一段时间后退出，方便演示
if (messageCount >= 30)
{
Console.WriteLine("模拟30条消息发送完成，程序退出");
break;
}
}
await deviceClient.CloseAsync();
}
// 发送一条遥测消息到IoT Hub
private static async Task SendTelemetryAsync(int counter)
{
var payload = new
{
temperature = 23.5 + Random.Shared.NextDouble() * 5,
humidity = 50 + Random.Shared.NextDouble() * 10,
seq = counter
};
var messageBody = JsonSerializer.Serialize(payload);
using var message = new Message(Encoding.UTF8.GetBytes(messageBody));
// 设置消息属性：可以让IoT Hub路由直接识别
message.Properties.Add("contentType", "application/json");
try
{
await deviceClient!.SendEventAsync(message);
Console.WriteLine($"第{counter}条消息发送成功 - {DateTime.Now:HH:mm:ss}，内容：{messageBody}");
}
catch (OperationCanceledException)
{
// 程序退出时可能出现取消操作，这里正常忽略
Console.WriteLine("发送请求被取消，可能正在关闭连接");
}
catch (Exception ex)
{
Console.WriteLine($"发送消息失败：{ex.Message}");
Console.WriteLine("触发重连流程...");
await ReconnectAsync();
}
}
// 处理连接状态变化事件
private static async void OnConnectionStatusChanged(ConnectionStatus status, ConnectionStatusChangeReason reason)
{
Console.WriteLine($"连接状态变化：{status}，原因：{reason}");
// 如果连接断开且不是有意关闭，则自动重连
if (status == ConnectionStatus.Disconnected &&
reason != ConnectionStatusChangeReason.ClientClose)
{
Console.WriteLine("检测到异常断开，尝试自动重连...");
await ReconnectAsync();
}
}
// 重连逻辑：创建一个新的DeviceClient并重新打开连接
private static async Task ReconnectAsync()
{
for (int attempt = 1; attempt <= 5; attempt++)
{
try
{
Console.WriteLine($"第{attempt}次尝试重连...");
// 使用新的令牌刷新对象重新创建设备客户端
var auth = new DeviceAuthenticationWithTokenRefresh(
DeviceId,
DeviceKey,
TimeSpan.FromMinutes(30)
);
var newClient = DeviceClient.Create(
HostName,
auth,
TransportType.Mqtt
);
newClient.SetConnectionStatusChangedHandler(OnConnectionStatusChanged);
await newClient.OpenAsync();
// 重连成功后替换旧客户端，并发送一条“上线”消息
deviceClient?.Dispose();
deviceClient = newClient;
Console.WriteLine("重连成功");
break;
}
catch (Exception ex)
{
Console.WriteLine($"重连失败：{ex.Message}");
// 等待指数退避时间后继续尝试：2秒、4秒、8秒...
int delaySeconds = (int)Math.Pow(2, attempt);
Console.WriteLine($"等待{delaySeconds}秒后重试");
await Task.Delay(TimeSpan.FromSeconds(delaySeconds));
}
}
}
}
这段代码里有一个关键点：DeviceAuthenticationWithTokenRefresh不是直接接受完整令牌，而是接收设备密钥。SDK拿着密钥，在连接时自动生成一张带过期时间的令牌。当令牌接近过期时，SDK会在后台静默刷新，无需我们干预。我们只需要保证程序不退出，SDK就会一直维护令牌的有效性。
如果你用的是不支持自动刷新的旧版本SDK，或者你手动构造SAS令牌，那就需要在代码里自己写一个“刷新器”，每隔一段时间重新生成令牌。伪逻辑如下：
// 手动刷新令牌的伪代码示例（技术栈：C#）
private static string GenerateSasToken(string resourceUri, string key, int expiryInSeconds)
{
// 1. 计算过期时间戳
// 2. 对 resourceUri 和过期时间做 HMAC-SHA256 签名
// 3. 拼接成完整令牌字符串
// 返回结果
return token;
}
示例里只展示了思路，实际实现需要引用加密库。如果你用官方SDK，推荐第一种方式，既安全又省心。
七、关联技术：设备预配服务DPS
处理令牌过期还可以结合另一个重要服务——Azure IoT Hub设备预配服务（DPS）。它的作用是让设备在第一次启动时自动注册和获取连接信息，而不是把连接字符串烧死在固件里。
DPS和令牌刷新有什么关系？当你使用DPS时，设备先拿到的是“注册范围”的凭证，比如设备证书或DPS专属的SAS令牌。DPS会返回该设备对应的IoT Hub连接信息。然后设备再按照本文第六节的方式，用IoT Hub的设备密钥去创建连接。DPS本身也会涉及令牌过期，但它和IoT Hub的令牌机制类似，都是基于SAS或证书。
用DPS的好处是，当你把设备从测试环境迁移到生产环境时，不需要挨个改固件里的连接字符串。设备只需知道DPS端点，就能自己找到“新家”。这个机制和令牌刷新搭配起来，可以做到设备全生命周期不用人工干预。
下面是一个简单的DPS注册流程示意图（文字描述）：
- 设备上电后，先向DPS服务器发送“我要注册”的请求。
- DPS根据预设的分配策略（比如按区域、按硬件ID）决定该设备归哪个IoT Hub管。
- DPS返回该IoT Hub的地址和临时令牌。
- 设备用临时令牌连接到IoT Hub，并获取设备密钥或证书。
- 之后设备使用IoT Hub的设备身份正常通信，开始SDK自动令牌刷新流程。
DPS本身也是一门大课，这里不展开。你只需要知道，令牌过期处理的核心机制在任何连接场景下都适用，DPS不过是一种更灵活的设备接入方式。
八、应用场景
令牌过期处理机制在不同场景下都有实际需求：
- 智能家居设备：比如上文提到的温湿度计，它可能几个月不重启，如果令牌过期而不处理，设备就会悄悄“失联”。
- 工业传感器：工厂里有成百上千个传感器，分布在各个角落。如果每个设备都需要定期人工重启，维护成本会非常巨大。
- 移动设备：比如手持扫码枪，它们会频繁移动，连接网络经常切换。每次切换都可能触发重新认证，如果令牌过期处理不好，扫码枪就会无法上传数据。
- 边缘网关：网关下面挂载很多子设备。网关本身极不容易重启，因此它的连接必须非常健壮，令牌自动续期是必选项。
九、技术优缺点
任何技术方案都有两面性，令牌自动处理也不例外。
先说优点：
- 可靠性高：设备不会因为令牌过期而长期掉线。
- 安全性好：令牌有效期可以设得比较短，降低泄露风险。
- 维护成本低：设备自愈，不需要人工干预。
再说缺点：
- 实现复杂度高：如果不用SDK，自己实现刷新逻辑要考虑重试、时钟偏移、并发等问题。
- 可能导致频繁连接：如果设计不当，令牌刷新失败会触发无限重连，反而消耗资源。
- 依赖正确的时间：设备时钟不准，令牌刷新就会出错。
所以，在实际项目中，我会优先推荐使用官方SDK的自动刷新能力。这样既能享受成熟方案的稳定性，又不必重复造轮子。
十、注意事项
设计和运行时需要注意以下几点：
- 不要设置过长的令牌有效期。虽然长有效期能减少刷新频率，但也会放大安全风险。建议默认24小时以内，根据场景灵活调整。
- 加入随机抖动。如果成千上万台设备同时启动，并且都在同一时间点刷新令牌，会给IoT Hub造成瞬时压力。可以在每台设备的刷新周期里加入几秒到几分钟的随机偏移。
- 处理时钟同步。设备上电时最好通过NTP协议同步一次时间。如果无法同步，可以把令牌过期时间设置为设备本地时间加一个较大的余量，比如多给300秒。
- 合理设置重试退避。重连失败时不要疯狂重试。使用指数退避，比如第一次等2秒，第二次等4秒，第三次等8秒，最多重试5次。
- 日志要详细。记录每次令牌刷新时间、刷新结果、连接状态变化。这样一旦出现问题，你可以通过日志快速定位。
- 不要硬编码密钥。在演示代码里为了简洁我直接写了密钥，实际生产中应该放到安全存储里，比如环境变量、凭据管理器或硬件安全模块。
十一、文章总结
令牌过期是Azure IoT Hub设备连接中非常常见的一个问题，但处理起来并不复杂。核心思想很简单：要么在令牌过期前主动换新票，要么发现票过期后马上补办。要做到这两点，你需要理解SAS令牌的构成，熟悉官方SDK提供的自动刷新接口，并设计好重连和重试策略。
如果你自己实现刷新逻辑，记得要处理时钟偏移、随机抖动和指数退避。如果你使用官方SDK，也别忘了设置合理的初始过期时间，并注册好连接状态变化回调。再结合DPS服务，设备就可以做到从首次上电到长期运行都不需要人工干预，真正实现“连接自愈”。
希望这篇文章能帮你解决设备掉线的烦恼。下次你的智能家居设备再“失联”，你可能第一时间就会想到，是不是令牌又过期了？
评论
围绕“Azure IoT Hub设备认证令牌过期的处理机制设计”参与讨论