长连接设备Session生命周期远长于Web请求，认证仅在connect和断线重连时进行，后续数据帧依托连接句柄天然可信，避免频繁验签以节省资源。
长连接设备的Session生命周期远长于Web请求
物联网硬件建立的是以小时、天甚至月为单位维持的TCP连接，而Web浏览器每次页面跳转或AJAX调用都可能触发新HTTP请求——协议本身无状态，Session必须靠Cookie或Authorization头反复携带。但MQTT或自定义长连接协议中，connect阶段完成一次认证（如设备三元组+TLS证书），后续所有PUBLISH、SUBSCRIBE报文都在同一连接上下文中流转，服务端靠连接句柄（fd）和已绑定的设备身份直接识别，无需再验。
设备身份固化，不像Web用户会切换终端或浏览器
一个温湿度传感器的device_id是烧录在Flash里的，MAC地址/序列号不可变，它不会像人一样在Chrome登出后又用Safari重登。所以服务端在CONNECT时校验过client_id、证书指纹或签名后，就可以把该连接与设备身份强绑定，后续所有数据帧天然可信。而Web场景下，Session ID可能被窃取、复用、跨设备共享，必须高频校验时效性与来源。
资源受限设备禁不起频繁握手开销
- 每次TLS重协商或JWT签名校验都要消耗毫秒级CPU和几十KB内存——对只有128KB RAM的MCU是致命负担
- 2G/NB-IoT网络下RTT常达1–3秒，频繁
POST /auth会导致指令延迟飙升 - 电池供电设备若每5分钟唤醒做一次Session刷新，寿命直接缩水30%以上
真正的验证发生在连接建立和异常恢复时
设备真正需要“验证”的节点其实就两个：connect时做完整认证（含证书链校验、签名验签、黑白名单检查），以及clean session = false断线重连时，Broker通过client_id查本地Session缓存并恢复QoS 1/2消息。中间所有数据交互都不走认证路径——这不是偷懒，而是协议栈设计上把“信任锚点”前移到连接层，避免在数据平面重复做重量级操作。
容易被忽略的是：一旦设备因固件缺陷或配置错误导致keepalive超时断连，重连时若未正确处理will message和session expiry interval，服务端可能误判设备离线状态，此时表面看是“没验证”，实则是Session管理逻辑没对齐。这比加几次验签更容易引发线上故障。
