基于MQTT的物联网系统文件传输方法的实现

张玉杰， 刘 丽, 冯春倩, 张婷婷

(陕西科技大学 电气与信息工程学院， 陕西 西安 710021)

0 引言

MQTT(Message Queue Telemetry Transport,消息队列遥测传输)协议以其开销小、及时性好和可靠性高等优势在物联网系统中得到广泛的应用[1]，其基于主题的发布订阅模型，可方便实现物联网系统中节点设备一对一，一对多的消息通信[2].在物联网系统中，常存在设备节点参数配置、设备与设备之间需要共享信息量较大的数据的场合[3]，而这类文件数据大小仅为几十kB的等级.因此，提供一种开销小、可靠性高、简单灵活的文件传输方案就显得尤为必要.

TFTP协议常被用于解决资源有限的嵌入式系统中的文件传输[4]，将通信双方一方设置为客户端模式，另一方为服务器模式，即可实现设备到设备之间的文件传输.由于物联网系统中终端节点设备大都分散在不同区域的局域网内，使用该种方式，难以避免通信过程中设备IP动态分配和内网穿透的问题.若采取在公网中建立文件服务器，设备做客户端的方式实现设备与设备的文件传输[5]，需要系统额外增加文件服务器和文件消息通知功能，增加了系统的复杂程度.

针对传统文件传输方法难以适应物联网系统设备到设备之间文件传输的场合的问题，本文利用MQTT协议在物联网系统中设备与设备间消息通信的优势，在MQTT通信的基础上，通过文件拆分传输的方式，能够快速实现物联网系统中设备到设备间的小文件传输，具有实际应用价值.

1 文件传输方案的设计

1.1 文件传输问题分析

MQTT是基于TCP/IP的即时通讯协议，采用轻量级基于代理的发布/订阅式消息传输模式.其结构如图1所示，由MQTT客户端和服务器组成[6].本文提出的基于MQTT协议的文件传输系统中，通信的双方既可以是数据的发送方也可以是数据的接收方，均属于MQTT客户端，而MQTT代理服务器作为文件传输过程中的中转站，不作为文件传输的对象进行考虑.

图1 MQTT协议基于主题发布/订阅通信结构图

MQTT协议是一种针对小数据量消息传输的轻量级协议，消息体主要由三部分组成：固定报头，可变报头和有效载荷，固定报头是每个命令消息都必须要包含的部分，长度固定为2bytes，最大可表示的消息长度范围为0～256 Mbyte[7].虽然协议规定MQTT消息体中最大可以发送的字节数为256 Mbyte，但是若直接以最大长度进行文件传输，会存在以下问题：

(1)设备端在实现文件传输过程中，需要开辟缓冲区存放所要发送的数据，当传输的数据较大时，相应的缓冲区的容量将会增大，而工作在物联网底层的小型嵌入式硬件设备的资源是有限的[8]，其内存资源很难满足需求；

(2)由于文件传输系统中用于MQTT通信的通道是单一的，若以最大长度进行文件传输，当文件较大传输时间较长时，传输通道将会被长时间占用，从而无法保证系统中其它使用MQTT协议传输的业务消息的及时传输.

(3)MQTT协议适应于工作在带宽低、网络环境不稳定的物联网环境中.一旦出现网络故障等原因造成的文件传输出错现象，由于MQTT协议本身不具备断点续传等功能[9]，在恢复新一次文件传输时，之前已经传输的文件数据将会丢弃，造成了流量的浪费，也降低了整个文件传输的效率.

因此，需要综合考虑设备的硬件存储资源、传输通道占用情况、文件传输效率等多个因素，设计基于MQTT协议的文件传输方法.

1.2 文件传输方案设计

针对上面的分析，基于MQTT协议的文件传输方法，以MQTT通信为基础[10]，使用文件拆分传输方式进行文件传输，在此基础上增加应答、重传等机制，目的在于弥补文件拆分传输过程中可能会出现的丢包现象，从而增强文件传输的可靠性.

文件拆分传输包含以下几个环节：提取信息-拆分-传输-接收-组装-检查.为确保文件传输的可靠性，通信过程中，一方传输数据并接收应答，另一方接收数据并给出应答.并且通信双方各自实现超时重传，若发送方超时将重新发送上次的数据包，若接收方超时，则将重传应答数据包.图2为基于MQTT协议的文件传输方法的实现过程.该文件传输方案描述了发送设备端向接收设备端传送文件的基本过程，主要包括文件传输请求阶段、文件数据传输阶段、文件传输结束阶段三个阶段.

图2 基于MQTT协议的文件传输方法的实现过程

文件传输请求阶段：发送方提取有关发送文件的大小属性，优先向接收方发送文件属性消息作为发起文件传输的请求，接收方接收并保存文件属性消息，读取文件大小，判断硬件资源是否满足，若满足则回复应答包，表示文件传输过程建立，进入文件数据传输阶段.文件数据传输阶段：发送方向接收方发送文件数据，等待接收方回复的应答包，超时后重发未被确认的数据包；接收方接收到数据后，回复文件数据包正确或者错误；当数据长度小于定义的最大数据包长度，则表示传输结束，接收方成功接收到最后一帧文件数据包后，进入文件传输结束阶段.

文件传输结束阶段：发送方向接收方发送最后一帧文件数据包，收到来自接收方的应答包之后，回复一个确认信号，表示整个文件传输操作已经结束.

2 文件传输的软件实现

2.1 系统软件架构

根据系统文件传输的设计需求，软件部分不仅包括MQTT通信的实现，还包括文件数据处理，文件传输，文件存储功能的实现.系统软件设计采用分层设计的思想，软件架构如图3所示，由硬件驱动层、系统层、应用层三部分组成[11].

硬件驱动层主要包含以太网收发器LAN8720A驱动[12]、串口驱动、SD卡驱动等硬件驱动程序.系统层为上层应用层文件传输服务等功能的实现提供支持，包含操作系统，网络协议栈，文件编码数据格式等.其中FreeRTOS操作系统实现对整个系统的任务调度和管理；LWIP协议栈是轻量级的TCP/IP协议栈[13]，适应于底层资源有限的嵌入式设备，是网络通信的基础；FatFs文件系统提供对文件进行读写[14]，删除等操作的标准接口，方便实现对SD卡中的文件进行管理；Base64编码、Json库为文件数据格式的统一规范提供支持，使文件传输方法适用于不同场合的系统.应用层为功能的实现，主要包含MQTT通信实现、文件传输服务实现及其它相关的应用程序.

图3 系统软件架构图

2.2 文件传输数据格式

根据文件传输的需求，将文件传输过程中数据帧主要分为以下几类：文件请求命令帧，请求应答帧，文件数据帧，数据接收应答帧，文件结束请求命令帧，结束应答帧.数据帧格式如表1～6所示.

表1 文件请求命令帧格式

表2 文件请求应答帧格式

表3 文件数据帧格式

表4 文件数据应答帧格式

表5 文件结束请求命令帧格式

表6 文件结束请求应答帧格式

在本设计中，当进行文件传输时，采用JSON键值对“属性，值”的形式[15]，来对文件传输的数据帧进行封装.为避免二进制文件直接嵌入在JSON 字符串流中传输而破坏JSON字符串原有格式的问题，系统采用Base64编码对源文件进行编码[16]，将二进制文件数据转换为Base64字符后再以JSON的形式进行传输.

2.3 文件传输功能实现

由于文件传输过程中请求、响应过程等具有时间的不确定性，采取了“事件驱动+状态转移”的编程思想，对设备端的文件上传功能、文件下载功能进行实现.采用该方法进行程序设计时，关键的是需要对文件上传、文件下载的状态以及驱动各状态之间跳转的事件进行划分.

2.3.1 文件上传的实现

文件上传的实现过程划分为以下状态，包含空闲、上传请求、等待请求响应、发送数据、等待回复、发送结束请求、等待结束回复、上传成功、发送错误等九个状态.具体的状态转换过程如图4所示.

图4 文件上传状态转换图

(1)发送端执行文件上传初始化操作后，进入空闲状态.

(2)启动文件传输事件触发状态进行跳转，进入上传请求状态.

(3)发布文件请求消息之后，进入到等待请求响应状态.

(4)若接收到拒绝请求回复，则返回至上传请求状态，若请求成功，发送文件数据命令，进入发送数据状态.

(5)发送数据状态作为文件上传实现过程中的核心状态，通过与等待回复状态的配合，确保文件上传时确认应答以及超时重传机制的完整实现.该状态下，实现数据帧的打包、上传工作.

(6)超时时间内，接收到数据回复后，继续返回发送数据状态；当超时时间到达，仍未接收到回复时，返回数据发送状态，重新发送上一帧数据；当数据都上传结束后，进入发送结束请求状态.

(7)发布上传结束请求后，进入等待结束回复状态.

(8)回复成功，进入上传成功状态.

(9)上传成功状态中，置发送成功标志位，释放相关内存空间，返回至空闲状态.

2.3.2 文件下载的实现

文件下载的实现包含空闲、等待请求、准备接收、接收数据、等待文件传输结束、下载成功、下载错误等状态，具体的转换过程如图5所示.

(1)接收端执行文件下载初始化操作后，进入空闲状态；

(2)在空闲状态中，接收到发送端发来的文件传输请求时，启动文件下载，进入等待请求状态；

(3)若响应请求成功，则跳转至准备接收状态，若请求响应失败，则返回至等待请求状态；

(4)当接收到文件数据命令时，进入接收数据状态；

(5)接收数据状态作为文件下载实现过程中的关键，实现文件数据的接收、保存工作，并对已接收的数据进行回复，若超时时间到达，仍未接收到数据，则重发上一帧回复应答帧.当接收到发送端的发送结束请求后，跳转至等待文件传输结束状态.

(6)回复文件结束的请求成功后，进入下载成功状态；

(7)文件下载状态中，置文件接收成功标志位，释放相关内存空间，返回至空闲状态.

图5 文件下载状态转换图

3 系统测试

3.1 测试平台的搭建

搭建一个完整的测试平台，对文件传输的性能进行测试.该系统包括两个MQTT设备端(均属于MQTT客户端，设备A发布消息的主题号为“deviceAout”，设备B发布消息的主题号为“deviceBout”)，一个MQTT服务器.MQTT服务器采用Apache Apollo服务器；MQTT设备端硬件设计框图如图6所示，采用STM32F407VET6作为主控制器，选用LAN8720A作为以太网收发器，通过RJ45接口接入网络，此外还包括打印输出信息的串口调试电路、LED状态指示电路、SD卡存储电路、电源电路等，硬件实物如图7所示.

图6 MQTT设备端硬件框图

图7 MQTT设备端硬件实物图

3.2 文件传输性能测试

系统性能测试主要包含文件传输功能测试和文件传输可靠性测试.功能测试以一个固定大小的文件为例，利用MQTT测试工具监测设备A与设备B之间的文件传输过程.测试时选用的文件大小为22 494 byte.首先设备A向设备B发送文件传输请求，在接收到设备B的请求应答后，开始传送文件数据，出现丢包情况时，等待超时时间到后设备A会再次发送数据，当文件传输结束时，设备A发送结束请求，设备B回复结束请求应答，整个文件传输结束.测试结果如图8所示.

(a) 文件传输请求

(b) 文件数据传输

(c) 超时重发

(d) 请求结束文件传输图8 文件传输测试截图

可靠性测试通过选择3个不同大小的源文件在两个MQTT设备端之间进行传输，实验组数为50组，多次重复试验，统计文件传输时的丢包重传组数、成功组数，计算成功率.测试结果如表7所示.

表7 文件传输测试结果

由于文件传输工作相对比较耗时，进行文件传输时不可避免的会出现网络环境不稳定的状况.当网络环境较差，导致传输过程中出现丢包现象，系统会进入超时重传，考虑到嵌入式设备不能长时间陷入某个固定状态，导致其他任务无法响应，故在超时重传机制中进行了阈值设置，当某一组重传次数超过3次时，系统会自动中断此次文件传输.

在表7中，丢包超时重传组数表示文件传输过程中出现网络丢包进入超时重传的组数，前两个文件传输实验的超时重传组数10组和9组，进入超时重传的组中的每一组的重传次数都没有超过3次，所以文件传输成功率为100%.第三个实验的超时重传组数为11组，并且有一组实验的超时重传实验次数超过设定阈值的3次，系统自动中断了此次传输，故最终的成功率是98%.

实验结果表明，当网络环境不稳定时，文件传输过程中会出现丢包的情况，超时重传机制的增加，有效提高了系统文件传输的可靠性.

4 结束语

针对物联网系统中设备之间存在的文件传输需求，以MQTT发布/订阅模型为基础，采用拆分传输方式，增加确保文件可靠传输的确认应答、超时重传机制，实现了物联网系统中小型嵌入式设备节点之间的文件传输.通过软件设计对文件传输方法进行实现，并搭建硬件平台进行功能测试.测试结果表明，系统功能完整，可以实现物联网系统中设备端到设备端之间可靠的文件传输.目前，已经在实验室远程情感交互产品中得到应用.

[1] 许金喜,张新有.Android平台基于MQTT协议的推送机制[J].计算机系统应用,2015,24(1):185-190.

[2] 姜 妮,张 宇.基于MQTT物联网消息推送系统[J].网络新媒体技术,2014,31(2):47-51.

[3] 楼亮亮,金彦亮.物联网设备无线固件升级技术的研究[J].单片机与嵌入式系统应用,2015,54(6):34-38.

[4] 李小波.基于ARM的TFTP协议的实现[J].工业仪表与自动化装置,2016,18(6):4-9.

[5] 周兰凤,孟 驰,彭俊杰.一种基于云环境的文件存储策略的研究[J].计算机工程与科学,2016,38(2):262-268.

[6] 陈 旖,许 力,张美平.适用于大规模无线传感器网的流量优化系统设计[J].计算机应用,2015,35(4):905-909.

[7] 温彬民.一种基于自适应心跳机制的MQTT通信协议的研究与应用[D].广州：华南理工大学,2015.

[8] Lee S,Kim H,Hong D,et al.Correlation analysis of MQTT loss and delay according to QoS level[C]//Information Networking.Washington: IEEE Computer Society Washington,2013:714-717.

[9] Custura D.System for multicast file transfer[J].Journal of Mobile Embedded & Distributed Systems,2012,4(1):31-37.

[10] D Thangavel,X Ma,A Valera,et al.Performance evaluation of MQTT and CoAP via a common middleware[J].IEEE,2014,11(2):79-86.

[11] 张玉杰,郑 培.KNX-TCP/IP 协议转换网关的设计与实现[J].自动化仪表,2014,35(12):49-52.

[12] 陈绍炜,魏 刚.TMS320C6416程序以太网远程更新技术研究[J].现代电子技术,2014,37(12):125-128.

[13] 孙棣华,陆 旭,廖孝勇,等.面向设备监控的LwIP协议栈扩展设计[J].电子技术应用,2013,39(6):10-13.

[14] 高兆强,王绍举,徐 伟,等,FATFS在嵌入式操作系统FreeRTOS中的移植与应用[J].现代电子技术,2017,40(6):65-67.

[15] 张为金.资源共享与移动学习平台中若干JSON问题研究[D].西安:西安电子科技大学,2014.

[16] 罗江华.基于MD5与Base64的混合加密算法[J].计算机应用,2012,32(S1):47-49.