基于无线通信的可靠文件传输设计

张 智

(无锡职业技术学院人事处 江苏 无锡 214121)

0 引 言

随着网络和通信技术的发展，信息传输和交互使得万物互联。在工业控制中，常见的上位机和下位机通信是有线通信传输，可靠而稳定。由于近年来无线通信技术的发展，在某些情况(如布线有困难等)下广泛地利用了无线传输技术，实现上位机和下位机之间的通信或数据传输。无线通信进行数据传输克服了空间和位置上的不便性，在另一方面又对数据传输的稳定性、速度和安全性提出了更高的要求。

当前，使用比较广泛的无线数据传输协议有:ZigBee、红外线、WLAN、蓝牙、GPRS、3/4G等[1]，其中基于移动网络的通信使用得非常多，特别是通过通信模块实现远距离的数据通信和传输的方式，已经应用到气象、燃气、交通、物流等各行各业的通信和业务保障中。在文件传输上，现在比较主流的软件有各种网盘、磁力链软件、BT软件、迅雷等，这些软件具有很好的网络资源传输效率和稳定性。而对于处于下位机端的嵌入式设备和处于上位机的系统进行无线通信，经常遇到传输效率低下，传输的安全性、可靠性得不到保证的情况。

上下位机间比较常见的一种文件传输场景是上位机将升级程序发送给下位机。在气象行业，各种传感器前端设备的数目有万级以上，一旦发现重大bug需要升级程序的话需要对现场的所有设备都进行升级程序[2]。目前部署在外部的大部分气象设备都不具备远程升级的功能，即使部分具备传输的性能也不尽如人意。在没有远程升级功能的前提下，对现场所有设备的升级将是一场金钱、时间、精力上的灾难。除此之外，前端设备中也会存储一些运行日志信息和历史数据，上位机也需要这些文件做应用和分析。因此需要针对前端设备和上位机设备间设计出一种高效率的通信方案，保障文件在前端设备和上位机软件间的双向、可靠、稳定的传输。

1 系统交互

1.1 系统结构

在无线抄表、观测数据采集、远程状态监控等应用系统中，一般由发送方、接收方、中转方三个部分组成，其中模块为中转方、上位机和下位机的通信需要经由模块拨号上网建立通信链路才可以相互通信。根据业务应用需要，前端设备和上位机既可以做发送方又可以做接收方。基于这种组成结构，当上位机将嵌入式升级程序发送到前端设备中时，上位机为发送端，而前端设备为接收方。当上位机从前端设备请求日志文件或参数文件时，则上位机为接收方，前端设备为发送方。在不同的场景下上位机和下位机间可以选择UDP或TCP方式传输文件。系统结构如图1所示。

图1 文件传输结构

模块与上位机间的通信方式设置成UDP或TCP并拨号成功后，模块即可作为中介者的角色完成前端设备和上位机系统间的通信。

1.2 通信方式

Socket通信有两种方式:TCP和UDP。根据不同的应用场景，上位机和下位机间的通信也有两种方式。TCP是一种稳定、可靠的数据传输协议，通过三次握手建立连接并通过四次握手撤销连接，在数据的传输过程中有确认和重传机制并且可以对流量进行拥塞控制。因此在一些需要可靠传输、不能丢包的场景中需要用TCP进行通信。但是该种协议的缺点是效率较低、速度相对较慢，在下位机数目非常多的情况下通信压力较大。而UDP比TCP速度快，没有握手、确认和重传、拥塞控制机制，但是缺点是不可靠，可能在网络质量不好的情况下丢包。在不同的地区，不同的应用行业和不同的下位机数目的场景下用户可以针对性地选择TCP或UDP协议进行文件传输。

2 设计与实现

2.1 可靠性

由于许多前端设备安装在高山、海峡等信号很不稳定的地区，在传输文件的过程中传输经常中断。需要传输的文件越大出错的可能性就越高，一旦出错则需要耗费更多的流量和时间才能重新传输直到结束，甚至还有可能引起通信的崩溃[3]。虽然TCP是一种可靠的传输协议，但是在网络通信中断后还需要在应用层加入一些自定义的控制来实现断点续传。

UDP是不可靠的传输方式，更加需要自定义的方式来进行流量控制、失败重发和断点续传功能。因此无论模块采用什么样的传输方式，都需要一套自定义的通信方式来保证文件的可靠传输。

2.1.1分包确认

为了实现以上功能，需要将文件进行分包传输，并且每次接收端收到分包后发送回执给发送端，发送端在收不到回执的情况下重试发送，直到所有分包发送结束。如果有一个分包接收回执超过指定的次数后仍然无法发送成功则取消本次发送并给出错误结果[4]，同时对于重要的内容需要增加校验[5]。详细传输过程如图2所示。

图2 文件分包确认传输机制

该传输机制不但适用于TCP通信方式下的文件传输也适用于UDP通信方式下的远程文件传输。在网络不稳定原因造成的传输中断下可以实现断点续传的功能。

2.1.2分包类型

1) 握手包。在文件发送前需要与接收端握手，目的在于告知对方准备传输文件，提供接收端背景信息。比如将待发送文件的大小、crc值、文件名等信息告知接收方，接收发返回是否可以发送，发送的起始位置。

文件分包在发送端支持分包大小参数的设置，可以根据需要设置为2 KB、1 KB、512 B等大小。分包大小合理值的设置与几个因素有关：通信链路最大消息长度、设备前端的串口传输速率、Socket缓存大小等。

对于大的文件优先选择大包进行传输文件，若尝试多次后发现有回执超时情况，调小分包参数再次尝试。分包越大，需要进行重传的概率越大；分包越小需要确认的回执等待时间越长。

握手包结构设计如表1所示。

表1 握手包结构

Package Type：填0约定包为握手包类型。

FileName：约定本次要传输的文件名。

MD5：文件的MD5值。

CRC Value：待传输文件的CRC32值，以16进制值表示。

FileSize：待传输文件的大小。

subPackageSize：在传输过程中需要将文件拆分成多大的分包，以保证可靠性和断点续传。

2) 握手回执。在发送端发送出握手请求后，接收端根据发送端提供的请求信息并对比本地缓存的该文件内容及该文件的上一次传输结果信息告知对方下一步的动作。握手回执包的结构如表2所示。

表2 握手回执包结构

Package Type：填1约定包为握手回执包类型。

FileName：约定本次要传输的文件名。

Next SubPackage：接收端检查之前是否有发送中断的文件，并且返回下一个分包的号码(可能在顺序上某个分包上次没有收到，但是该分包后面的分包收到了，此时该分包作为下一次期望的分包号来发送)。

FlagID：0表示可以发送，1表示握手失败。

FlagDetail：握手失败的原因，握手成功也可以返回信息(如分包大小前后不一致)。

3) 数据包的结构(如表3所示)。

表3 数据包结构

Package Type：填2约定包为数据包类型。

Package ID：当前发送的是第几包(索引从0开始)。

Package Length：当前包的数据长度，最后一包可能少于分包的界限值。

crc：待传输文件的CRC32值，以16进制值表示。

data：待发送的数据。

4) 数据包回执(如表4所示)。

表4 数据包回执结构

Package Type：填3约定包为数据包回执类型。

Package ID：指明第N个包。

Receipt Type：收到的回执类型。0表示收到正确的分包；1表示校验失败；2表示其他。

Windows Left：窗口剩余大小。告知发送方还可以同时发送多少个分包，即使前面有部分分包还没有得到确认。

2.2 安全性

在上位机和下位机传输文件的过程中，有些是商业数据，有些是敏感数据，这些数据有着较高的保密性，在传输的过程中需要保证这些重要数据不能被截取并破译。因此需要保证文件的传输内容不能以明文的形式存在，需要对传输的文件内容进行加密，这样即使被非法用户截取，也无法获得其中真正的有效数据。而要实现报文的加密传输，就需要在传输前就约定好加密方式。一般来讲可供选择的方式有两种：使用非对称加密算法和对称加密算法。非对称加密算法的优势是加密密钥安全性高，不足之处是计算量较大比较耗费性能。对称加密算法使用起来简单快捷，密钥较短，且破译困难，而且对计算机功能要求也没有那么高[6]。因此在传输的过程中采用对称加密算法中的DES算法来保证数据的可靠传输。加密部分主要算法如下：

//计算向量iv增加加密算法强度

byte[] key = sKey.getBytes();

IvParameterSpec iv = new IvParameterSpec(key);

DESKeySpec desKey = new DESKeySpec(key);

SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(″S″);

SecretKey securekey=keyFactory.generateSecret(desKey);

Cipher cipher = Cipher.getInstance(″DES/CBC/PKCS5Padding″);

cipher.init(Cipher.ENCRYPT_MODE, securekey, iv);

//对data加密

return cipher.doFinal(data);

……

接收方收到密文后使用解密算法还原成明文即可，解密过程即是加密过程的逆过程。

2.3 顺序保证

由于通信的不可靠会导致在接收方收到的分包顺序不一致。有几种情况：一是先发出去的分包反而在后面收到;二是某些分包发出去后由于丢失需要重传，而此时有多个分包在并发传输，会导致该分包接收的时间排在其他分包的后面[7]。

接收方会对接收到的分包进行缓存，分别对各个分包的接收状态进行记录,如表5所示。

表5 各分包接收状态记录表

假如共有M个分包，每个已经接收到的分包分别存储在相应的位置，并且置上标记以区分出本端是否已经接收到，是否需要发送回执。即使4号分包由于时间或网络的原因没有到达接收方也不影响其他分包的接收。每个分包接收到后分别存储在各自的位置，与其他分包没有必然的因果关系。每个分包的发送和接收采用多线程的方式并发处理，不但提高了通信效率也保证了顺序的重排工作。

2.4 性 能

在传输过程中由于网络信号的问题经常需要重传，待发送的文件越大则重传的可能性也越大，因此发送方和接收方都期望尽快完成文件的收发工作。如果在发送前将文件进行压缩，之后再进行分包则会大大减轻网络传输的压力，提高传输的成功概率，特别是一些保存文本数据的文件在压缩后体积会成倍减小，从而网络传输的内容也会相应减少。

与加密解密算法类似，上位机提供gzip压缩功能，下位机解压缩功能实现数据的还原。

3 测试分析

本节将通过两个方面的测试数据来对比分析文件传输的效率。

现场测试环境为3G通信链路，下位机采用RG45接口与上位机进行通信。上位机采用4线程进行分包和缓存，分别从下位机获取日、周、月累积的日志文件。

压缩效果测试结果示意图如图3所示。

图3 压缩效果对比

可以看出，采用gzip压缩后能够达到3%的压缩率并且效果比较稳定，需要实际传输的内容得到了极大的精简。

传输时间测试结果的示意图如图4所示。

[8] Long J, Shelhamer E, Darrell T, et al. Fully convolutional networks for semantic segmentation[C]//Computer Vision and Pattern Recognition,2015.

[9] 李智超.基于神经网络车牌图像识别系统[D].长春:吉林大学,2018.

[10] 李倩,陈兴杰,彭乐乐,等.无砟轨道扣件快速匹配定位方法研究[J].计算机测量与控制,2019,27(1):267-270,279.

[11] 刘甲甲,李柏林,罗建桥,等.融合PHOG和MSLBP特征的铁路扣件检测算法[J].西南交通大学学报,2015,50(2):256-263.

[12] 代先星,阳恩慧,丁世海,等.基于三维图像的铁路扣件缺陷自动识别算法[J].铁道学报,2017,39(10):89-96.

[13] Feng H, Jiang Z, Xie F, et al. Automatic fastener classification and defect detection in vision-based railway inspection systems[J].IEEE Transactions on Instrumentation and Measurement,2014,63(4):877-888.