基本介绍
比如UART传输过程中,数据被从A设备发送到B设备时,一般的都做这样的协议简单封装数据:“包头0xAA+两字节包长度LEN+1字节的LRC+数据内容”,此时B设备收到数据包就进行解析。
这一过程就是应用层面的协议。
类似的,MQTT也有报文格式,应用程序将数据填入报文包中,后通过TCP进行发送。
为了查看其报文格式,可以利用MQTT客户端工具MQTT.fx,尝试向TCP服务器发起一个连接请求。
交互过程如下:
TCP服务器开启,并侦听;
MQTT.fx作为客户端,向TCP服务器发起请求,发出的CONNECT报文(Hex):10 1A 00 044D 51 54 54 04 02 00 3C 00 0E 77 77 77 2E 64 69 67 63 6F 72 65 2E 63 6E;
TCP服务器接收到该请求,TCP服务器此刻该回复(Hex):20 02 00 00;
完成连接请求。
以下为交互过程截图:
配置TCPServer和MQTT.fx客户端,需要填写一致的IP地址和端口号
MQTT.fx发起连接时,TCPServer接收到的完整数据包内容
TCPServer通过发送栏,回复数据(Hex):2002 00 00
至此,MQTT的连接流程完成,并且MQTT.fx客户端显示已连接的状态。通过这一模拟的过程,我们能够清晰认识到MQTT文档中的报文格式定义已经协议规范的定义。
对以上的数据分析,我们很容易就和MQTT-3.1.1版本规范进行对应:
客户端发的数据是10 1A 00 04 4D 51 54 54 04 02 00 3C 00 0E 77 77 77 2E 64 69 67 63 6F 72 65 2E 63 6E
解析如下:
固定报头:0x10 1A,即报文类型是1,长度是26个字节(0x1A)
可变报头:
0x00 04 4D 51 54 54,此处定义了协议名,长度是4,协议名是”MQTT”;
0x04,协议级别;
0x02,连接标志;
0x00 3C,保持连接,以秒为单位的时间间隔;
有效载荷:
0x00 0E,有效载荷内容的长度
TCPServer回复的数据是20 0200 00
解析如下:
固定报头:0x20 02,即报文类型是2,长度是2个字节(0x02)
可变报头:0x00 00,即连接确认标志和连接返回码
在实际开发过程中,可以利用SSCOM工具作为服务器式验证自己编写的MQTT客户端程序是否正确发出数据,另外也可以作为客户端验证与MQTT服务器的正确交互。
既然TCP连接后就已经实现了数据收发的功能,为什么应用层还有这么多的通信协议:HTTP、FTP、MQTT等。
这就有区别于串口,毕竟串口在通信时是有着导线直接相连,而基于TCP连接的通信,在复杂的计算机网络中,准确找对一个终端并与之交互数据,这中间需要做的是靠应用层的协议进行握手、确认等交互,有着“一回生二回熟三回四回热炕头”这么一个啰嗦的过程。
协议框架
MQTT框架模型非常清晰看到,服务器实现了该协议的最主要功能,对数据和指令进行“转发”。
领取专属 10元无门槛券
私享最新 技术干货