【百问网7天物联网智能家居】训练营学习笔记（五）

最新推荐文章于 2024-06-08 17:09:56 发布

Piu~362

最新推荐文章于 2024-06-08 17:09:56 发布

阅读量1k

点赞数

文章标签：物联网学习 udp

本文链接：https://blog.csdn.net/weixin_56302933/article/details/125065934

版权

第五天

基础部分

ESP8266

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FebgBgFC-1653980574468)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220520171937583.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CzOEgBOK-1653980574469)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220520171951758.png)]$

TCP传输分服务端和接收端，需要提前建立连接，后续才能传输。
UDP传输不区分服务端和接收端，不需要提前建立连接。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zpdRNEpD-1653980574469)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220520172354107.png)]$

透传模式

就是在作为TCP客户端传输或UDP传输的情况下，

进入这个透传模式，就收发的都是原始数据
不会加数据封装，接收数据就不是IPD开头那种。 $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N3Q0rhzy-1653980574470)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220520172510338.png)]$

先创建TCP/UDP连接，再进入透传模式

之后手机用TCP/UDP发数据，发什么，模块转发给我们MCU就是什么。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0lKNMNBU-1653980574470)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220520172720731.png)]$

除非发送+++退出

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tBordSgf-1653980574470)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220520172751059.png)]$

提高部分

对于通信或者数据传输，有三个要素：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9OdEN9JT-1653980574471)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220520172859079.png)]$

在网络通信里面，我们是如何确定源和目的的？
是通过IP和端口，仅有IP是不足以确定一个源或者目的的。
两个浏览器访问同一个域名（域名是绑定到一个服务器上的）
这两个浏览器是在一个电脑上打开的，也就是说向服务器发出数据包的时候，用的是同一个IP
那么服务器怎么知道数据是从哪个浏览器发过来的？
这时候就是依靠分配给两个浏览器不同的端口port来区分的。
因而需要ip+port来确定一个源。对于确定目的地也是一样的，还是要ip+port来确定
私网设备想要访问外网设备，那么这个私网设备就必须要有一个公网IP
公网IP是优先的，且还是要前的，分配方式是先到先得
但是对于普通用户而言，真的每个设备都要去弄一个IP么
明显是不可能的
所以用到了路由器
我们已经知道没有公网ip是访问不了外网的设备或者服务器的
我们路由器访问外网用的公网IP就是运营商的工作人员来帮我们设置的。
我们手机连接了路由器，可以看到一个ip，192.168.x.x，这是个内网/私网IP
我们手机连接路由器之后，打开浏览器，去访问百度
是会将手机的ip+浏览器的port+数据包，发送给路由器
路由器再将这个数据包中的手机的ip，改为路由器的公网ip再打包发出去

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xvi8F6BR-1653980574471)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521150355112.png)]$

MQTT的基本概念就一句话：MQTT的是基于发布/订阅的方式进行的网络通信协议

其中发布和订阅是基于主题topic来发送消息的

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cjbpWMh8-1653980574471)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521150423847.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6CPoDyed-1653980574471)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521150654667.png)]$

从这里我们就可以看到MQTT协议的基础协议是TCP，还可以看到源IP，就是我们自己电脑上的IP，是一个私网IP，而目标IP，是建立了TCP的服务器的公网IP

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NK8c5RGO-1653980574472)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521160605491.png)]$

这些抓包信息还能反应一点：
客户端在连接阿里云物联网设备的时候，不是要写一个mqtthosturl嘛，我们设备MQTTX和这个url建立tcp连接，实际上是先连接了阿里云的服务器，然后服务器解析这个url域名找到绑定在服务器上的这个url对应的ip进行连接
我们这次连接的阿里云服务器的IP是47.103.184.100，这个和我们常见的是192.168.*.不一样，就是阿里云某个服务器的公网ip
我们之前说确定一个目标或者源除了ip外，还需要一个port
我们连接阿里云服务器设备的时候已经规定了一个port，就是1883
为什么我们抓包的时候，我们自己这边作为源或者目的，ip还是192.168..*这样的内网ip呢
这是因为我们的这个抓包软件能抓的只能是路由器转发过后的，它是无法抓到路由器的输入数据的。
在MQTT的通信过程中的两个动作：订阅和发布，是由客户端和服务器来参与完成的。一个客户端既可以是订阅者，也可以是发布者。
就像我们在视频里举的例子，一个B站up主，他既可以发布视频呗别的up主关注收看，也能关注别的up主，收看别人发布的视频。
客户端可以向MQTT服务器上传很多个topic的消息，也能订阅MQTT服务器支持转发的多个topic
MQTT服务器负责对所有topic消息的暂存、转发和清除。
MQTT的客户端想要长期和服务器保持连接，需要设置一个呼吸时间或者叫心跳周期keepalive，每隔一段时间向服务器发送心跳包来保持活跃。
如果服务器在隔了客户端在连接它的时候设置的keepalive这么长事件后，没有收到下一次心跳包，就会将设备踢下线
这个keepalive是在MQTT协议中的connect packet中设置并且告诉服务器的
也就是说MQTT客户端在向MQTT服务器发送连接请求的时候，就会将keepalive打包告诉服务器
keepalve只是连接请求包中的数据之一。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7levEF1a-1653980574472)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521161505846.png)]$

如果抓包软件一直开着，那个MQTTX客户端即便我们自己没有发布任何topic的数据给服务器，但是MQTTX本身继承的MQTT协议也会在后台每隔keepalive这么长时间发送一个ping request
也就是说这个心跳包，其实就是客户端ping了一次服务器
关于客户端和服务器的连接和断开：
连接和断开连接请求都是由客户端发起的
服务器不可以主动连接客户端
就像我们在浏览器访问![img](www.baidu.com
我们关掉了浏览器
百度服务器还能主动来连接我们的电脑打开浏览器吗？显然是不能的。
MQTT客户端要订阅和发布topic的payload（消息载体），必须要先连接一个服务器，才可以向服务器发布消息。客户端对服务器创建连接、订阅和发布等，设计方法： $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wnQNmACV-1653980574472)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521164855282.png)]$

我们在视频中解释了客户端和服务器在MQTT协议中扮演的角色以及各自担当的职责： $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g0EaJjoW-1653980574472)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521164927588.png)]$

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HvP6Vt6h-1653980574473)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521165057410.png)]$

在MQTT协议中，不同的控制包可能还会要求发送payload，注意，不是所有的请求都需要payload，比如心跳包，就不需要发送payload
下图中标注颜色的packet就是需要客户端发送或者服务器响应的payload $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h0VjjJXH-1653980574473)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521171242389.png)]$

对于客户端连接服务器的请求控制包，其payload的要求是： $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9VqiuzZW-1653980574473)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521171252966.png)]$

遗嘱、用户名和密码不是必须的但是客户端ID必须要有且是服务器能识别的ID遗嘱topic和遗嘱消息的作用是，当客户端因为某种原因导致和服务器断开连接的时候，服务器将会发布一个topic为遗嘱topic的消息
其它订阅了这个遗嘱topic的客户端就能接收到下线的那个客户端发出来的最后一条消息：遗嘱消息
一般遗嘱消息就是提示订阅者：我发布者离线了发布、订阅和取消订阅的payload： $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Bh5wCOvL-1653980574473)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220521171755041.png)]$

这张图里面提高了QoS，消息服务质量
这个机制在很多网络通信中都有
MQTT中的QoS有三种：

服务质量还要和另一个MQTT参数搭配，才能让服务器决定：对这条QoS的消息，是暂存还是丢弃
那个参数是retain，意思就是保留的意思
如果服务器收到一个QoS=0，retain=1的消息，那么服务器就必须清空之前这个topic所暂存的所有消息，保存当前这条retain的消息
如果retain=0，那么在客户端发送给服务器的数据包中，服务器就不会保存这个topic的payload，也不会删除已经保存下来的历史payload，直接将这条retain=0的数据包进行转发然后丢弃

当有个订阅者订阅了QoS=1的topic后，发布者的publish包的payload也必须是QoS=1
[QoS=2]：精确分发一次。这是最搞的服务质量，用在丢失和重复的消息都不能再被发送或者接收的场景。
这种服务质量在那些对数据安全性要求非常高的场景下经常应用
这种服务质量，发布者的publish包也必须是QoS=2
用哪种服务质量是根据不同的应用场景来决定的。
假设有个设备是专门作环境参数监测的，只是负责参数的上报，那么偶尔丢失一次两次也不打紧，那就可以用QoS=0的服务质量，来降低资源消耗
MQTT协议中还有很多概念定义，比如固定包头、可变包头、会话这些
如果一周的时间全拿来将MQTT的机制协议的话，应该是足够的，但是我们的训练营不是只为了讲MQTT，所以不会深入讲
我们在视频里简单的用MQTTx，将PC作为一个客户端连接了阿里云的物联网平台上的设备
看了下阿里云物联网是如何下发和订阅消息的
体验了下MQTT的发布和订阅
后面我们就是将mini开发板开发成一个也有MQTT订阅和发布功能的客户端
还是去连接阿里云服务器，让开发板和阿里云服务器进行MQTT的订阅和发布
然后还剧透下，我们在最后天将需求升级了下，利用阿里云物联网平台的云流转规则，实现不同设备通过阿里云服务器进行相互之间的订阅和发布
也就是说，我们可以用两个开发板，连接阿里云服务器，让开发板1发布消息给开发板2
也可以让开发板2发布消息给开发板1
这样来模拟远在天南地北的两个设备，通过连接一个服务器，进行相互之间的消息通信来相互控制
比如发散下，我在北京用手机控制深圳办公室的空调温度，就可以利用MQTT来做