| 导语 物联网支持中, 设备的连接问题检查是个很麻烦的事情。其它的领域无论前端还是后台开发, 一些疑难问题都有很多的工具辅助判断问题, 比如抓包就是很方便的方式。但是物联网设备特别是单片机, 本身资源有限, 一般来说, 很难进行抓包(特别是走蜂窝网络的设备) , 日志也很受限。
主要的麻烦
物联网支持中, 设备的连接问题检查是个很麻烦的事情. 无论前端还是后台开发, 一些疑难问题都有很多的工具辅助判断问题, 比如抓包就是很方便的方式, 但是物联网设备特别是单片机, 本身资源有限, 一般来说, 很难进行抓包, 日志也很受限.
腾讯物联网开发平台本身为物联网开发准备了很多的措施来帮助设备开发者来定位问题, 比如通信日志等, 但是一切都需要一个前提, 就是设备正常连接了腾讯云 物联网的 MQTT 服务, 没有连接上的话, 大部分的手段都难以使用. 而设备大部分都很难抓包, 所以定位问题变得很困难.
用户连接失败, 可能的原因非常多, 在实际支持的案例中, 碰到过:
- 网络问题, 比如运营商屏蔽了IP的访问, 比如流量受限
- 设备的软件问题, 比如客户端的连接参数不正确等 , 比如客户端因为C代码缓存溢出, 导致有时候连接的上, 有时候失败
- 设备的通信模组故障或者bug等
解决的办法
这些问题很多情况下需要tcpdump抓包才能知道 问题所在, 但是实际场景中, 设备就一个开发板 模组, 走的是蜂窝(2G/3G/4G) 线路, 想抓包都没有办法抓, 假如在服务端抓包的话, 现网几百万设备, 生产环境抓包本身就不是一个靠谱的事情.
在实践中, 我们一般推荐采用TCP代理连接服务的方式, 在代理服务器上抓包来帮助诊断问题:
具体步骤
- 找一台公有云CVM, 安装 nginx 服务
- listen 1883 端口并 代理到腾讯云的服务
配置代理 MQTT 1883 端口 , 腾讯的物联网开发平台和物联网通信的域名都是 <产品ID>.iotcloud.tencentdevices.com
然后CNAME 到 iothub.msf.tencent-cloud.com , 我们代理这个即可
- 客户设置连接到 该 CVM 的 IP地址 , 固件其它的逻辑都不需要改动 然后该 CVM 上 针对 1883 端口抓包, 就可以判断连接问题了
MQTT是TCP长连接服务, proxy_timeout 设置不要太小了, 否则会断开
代码语言：javascript复制 vi /etc/nginx/nginx.conf
stream {
upstream hub_host_1883 {
hash $remote_addr consistent;
server iothub.msf.tencent-cloud.com:1883 weight=5 max_fails=1 fail_timeout=10s;
}
upstream hub_host_8883 {
hash $remote_addr consistent;
server iothub.msf.tencent-cloud.com:8883 weight=5 max_fails=1 fail_timeout=10s;
}
server {
listen 1883;
proxy_connect_timeout 3s;
proxy_timeout 600s;
proxy_pass hub_host_1883;
}
}
}其它的检查手段
只需要设备本身能够连接物联网开发平台发送消息, 物联网开发平台(https://console.cloud.tencent.com/iotexplorer/)本身提供了很多方法来检查设备通信
比如通信日志
比如实时调试
