基于無線通信的可靠文件傳輸設計

張 智

(無錫職業技術學院人事處 江蘇 無錫 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.