熊啟龍

（水利部淮河水利委員會水文局（信息中心），安徽 蚌埠 233001）

0 引言

為實現(xiàn)水文全要素、全量程的自動監(jiān)測，水文自動測報系統(tǒng)要求具有的功能越來越豐富，自動采集傳輸?shù)臄?shù)據(jù)類型越來越多，遙測站拍攝現(xiàn)場高清圖片并傳輸至中心站作為測站簡單高效的可視化解決方案之一，應(yīng)用越來越廣泛。通過分析采集的數(shù)據(jù)和查看現(xiàn)場圖片，可以判斷和追溯測站的工作狀態(tài)，特別是近年來隨著人工智能識別技術(shù)的飛速發(fā)展，可以通過分析遙測站拍攝的水尺圖片識別測站水位，因此拍攝圖片并快速傳輸至中心站，成為遙測站一個重要的功能。

水文自動測報系統(tǒng)中傳輸?shù)臄?shù)據(jù)類型有水文數(shù)據(jù)、設(shè)備狀態(tài)信息、遙調(diào)命令、告警數(shù)據(jù)、運行日志數(shù)據(jù)、設(shè)備遠程升級固件包等，隨著新技術(shù)的發(fā)展，近年來還增加了高清圖片、短視頻多媒體數(shù)據(jù)，這些類型的數(shù)據(jù)都不大，遙測站可以在短時間內(nèi)傳輸完畢。水文自動測報系統(tǒng)遙測站運行在偏遠無人值守地區(qū)，通常采用太陽能、蓄電池供電系統(tǒng)提供電源，因此低功耗是其最重要的特征，為節(jié)省功耗，系統(tǒng)傳輸都是輕量級的數(shù)據(jù)，不適合大量數(shù)據(jù)傳輸。遙測通信數(shù)據(jù)量雖然較小，但是準(zhǔn)確性和實時性要求很高，是互聯(lián)網(wǎng)傳輸通用數(shù)據(jù)的一種類型。

目前，水文自動測報系統(tǒng)中遙測站傳輸圖片常用的行業(yè)規(guī)約有水利行業(yè)標(biāo)準(zhǔn) SL 651—2014《水文監(jiān)測數(shù)據(jù)傳輸規(guī)約》[1]和國家水資源監(jiān)控能力建設(shè)項目標(biāo)準(zhǔn) SZY 206—2016《水資源監(jiān)測數(shù)據(jù)傳輸規(guī)約》[2]2 種行業(yè)規(guī)約。 這 2 種水利行業(yè)規(guī)約都規(guī)定了一系列通信機制以保證數(shù)據(jù)傳輸?shù)目煽啃?，可以工作在有線 RS-232/485、超短波、2.5G/3G/4G 移動通信網(wǎng)絡(luò)、有線以太網(wǎng)、LoRa 及 NB-IoT 等多種物理通信介質(zhì)上。采用這 2 種水利行業(yè)規(guī)約，遙測站需要在應(yīng)用層根據(jù)物理信道的特點將數(shù)據(jù)分包，再分包發(fā)送，每包數(shù)據(jù)發(fā)送失敗具有自動重發(fā)功能，為保證數(shù)據(jù)正確，每包數(shù)據(jù)均需加上校驗。因此，這 2 種水利行業(yè)傳輸規(guī)約適合低帶寬、小數(shù)據(jù)量、自建通道、測站地處偏遠的自動監(jiān)測應(yīng)用場景。

隨著物聯(lián)網(wǎng)的興起和移動通信網(wǎng)絡(luò)技術(shù)的快速發(fā)展，終端機內(nèi)嵌以太網(wǎng) TCP/IP 協(xié)議且具有網(wǎng)絡(luò)通信能力成為其最基本的功能，而 TCP/IP 協(xié)議本身已提供復(fù)雜高效的傳輸機制，能確保鏈路的可靠性，因此，在 TCP/IP 協(xié)議的應(yīng)用層傳輸圖片和短視頻這類相較于水文數(shù)據(jù)比較大的數(shù)據(jù)類型時，不需要再考慮數(shù)據(jù)分包、失敗重傳、正確性校驗等機制。在這種情況下，如果再使用 2 種水利行業(yè)規(guī)約對圖片進行分包，每包數(shù)據(jù)加上校驗，失敗重傳，而沒有充分利用 TCP/IP 協(xié)議的特點，效率就比較低。

除了 2 種水利行業(yè)規(guī)約外，還有很多基于 TCP/IP協(xié)議廣泛使用的文件傳輸協(xié)議適合圖片數(shù)據(jù)傳輸，比如 FTP（File Transfer Protocol），TFTP（Trivial File Transfer Protocol）和 HTTP/HTTPS 等應(yīng)用層協(xié)議，這些協(xié)議已經(jīng)成為一種事實上的互聯(lián)網(wǎng)通用技術(shù)標(biāo)準(zhǔn)，他們充分利用了底層 TCP/IP 協(xié)議可靠傳輸?shù)奶攸c，快速高效。其中：FTP 和 TFTP 協(xié)議[3]需要打開中心站專用的 TCP/UDP（User Datagram Protocol）接收端口，由于這些協(xié)議采用明文傳輸而沒有充分考慮網(wǎng)絡(luò)安全，很容易造成網(wǎng)絡(luò)安全的隱患，因此已經(jīng)很少使用；HTTP 可用于傳輸包括文本、圖片、短視頻、HTML 文件等多種類型的數(shù)據(jù)，且充分利用底層 TCP/IP 協(xié)議提供的可靠傳輸鏈路，不需要考慮復(fù)雜的傳輸過程，具有簡單、靈活和高效的特點。為此研究采用 HTTP 協(xié)議替代水利行業(yè)規(guī)約傳輸高清圖片，以充分利用高速網(wǎng)絡(luò)通信信道的特點，提高水文自動測報系統(tǒng)圖片數(shù)據(jù)的傳輸效率和適用性。

HTTP 協(xié)議是互聯(lián)網(wǎng)的基礎(chǔ)協(xié)議，目前使用最廣泛的版本是 HTTP/1.1，是互聯(lián)網(wǎng)最流行也是最典型的應(yīng)用層協(xié)議，下層通常采用 TCP/IP 協(xié)議，默認的 HTTP 服務(wù)端口是 80。

1 采集圖片格式和傳輸方式的介紹

遙測站圖片的采集由遙測終端機完成，通常采用 RS-232/485 串口、RJ45 網(wǎng)絡(luò)接口或者 USB 接口連接攝像機并控制其拍攝圖片，再傳輸至遙測終端機中。由于終端機存儲資源有限，為了用較少的存儲空間得到較好的圖片品質(zhì)，攝像機采用壓縮方式保存和傳輸圖片，通常是 JPEG 格式。JPEG 格式有很高的壓縮率，使得圖片尺寸相對較小，有利于在有限帶寬的情況下快速傳輸。

通常，發(fā)送端在帶寬有限、信道可靠性不是很好的條件下傳輸圖片數(shù)據(jù)時，為了更好地控制傳輸，采用斷點續(xù)傳功能。將 JPEG 格式圖片的二進制流數(shù)據(jù)采用平均分幀的方式傳輸數(shù)據(jù)，每幀數(shù)據(jù)順序編號。發(fā)送端根據(jù)分幀大小計算傳輸 1 幅圖片總共需要的幀數(shù)（假設(shè)總幀數(shù)為N），并在與接收端首次通信時告知總幀數(shù)，則接收端返回發(fā)送端已經(jīng)接收的幀數(shù)X（數(shù)值為 0～（N- 2）），然后發(fā)送端從圖片的第（X+ 1）幀開始傳輸數(shù)據(jù)，直至所有數(shù)據(jù)傳輸完畢。假設(shè)在傳輸過程中，接收端在接收到第Y幀數(shù)據(jù)后中斷，在重新建立連接再次傳輸時，發(fā)送端直接從第（Y+ 1）幀開始傳輸，而不是從第0 幀開始傳輸。

2 采用 HTTP 協(xié)議傳輸圖片的流程

遙測終端機采用 HTTP 協(xié)議向中心站發(fā)送圖片，首先要通過移動通信網(wǎng)絡(luò)或者有線以太網(wǎng)與中心站 HTTP 服務(wù)端口建立 TCP 連接，然后將要發(fā)送的圖片數(shù)據(jù)按照 HTTP/1.1 協(xié)議組織成請求報文發(fā)送到中心站，中心站在接收到請求報文后，返回HTTP 響應(yīng)，并斷開 TCP 連接。采用 HTTP 協(xié)議傳輸圖片的流程圖如圖 1 所示。

圖1 采用 HTTP 協(xié)議發(fā)送圖片的流程圖

遙測站向中心站傳輸圖片，遙測站是客戶端，中心站是服務(wù)器，遙測站采用 POST 方法向服務(wù)器提交 HTTP 請求，圖片數(shù)據(jù)包含在請求正文中。

2.1 建立 TCP 連接

遙測終端機通常內(nèi)置 2.5G/3G/4G 移動通信模組[4]，終端機通過 AT 指令控制模組與服務(wù)器 HTTP服務(wù)端口建立 TCP 連接。

如果遙測終端機集成 RJ45 網(wǎng)絡(luò)接口并內(nèi)嵌TCP/IP 協(xié)議棧，終端機可以直接與服務(wù)器 HTTP 服務(wù)端口建立 TCP 連接。

2.2 發(fā)送 HTTP 請求報文

客戶端采用 POST 請求方法按照以下 4 個組成部分生成 HTTP 請求并發(fā)送至服務(wù)器 HTTP 服務(wù)端口：

1）狀態(tài)行。狀態(tài)行主要由請求方法、URL（統(tǒng)一資源定位器）、HTTP Version 協(xié)議版本 3 個部分組成，發(fā)送圖片請求方法為 POST，HTTP Version協(xié)議版本為 HTTP/1.1，URL 字段格式為 http://host[":"port][abs_path]，其中：http 表示要通過HTTP 協(xié)議定位網(wǎng)絡(luò)資源；host 表示合法的 Internet主機域名或者 IP 地址；port 指定 1 個端口號；abs_path 指定請求資源的統(tǒng)一資源標(biāo)志符 URI。

2）消息報頭。常用的鍵值對為

a. Accept：*/*，指定客戶端能夠接收所有的內(nèi)容類型。

b. User-Agent：Telemetry_system，描述客戶端的類型為遙測站。

c. Connection：Close，不需要保持持久連接。

d. Content-Type：image/jpg，傳輸文件類型為JPG 格式的圖片。

e. Content-Length：81920，該字段數(shù)值為請求發(fā)送的正文長度，也就是圖片的大小，81920 為本次請求傳輸?shù)臄?shù)據(jù)長度，以 B 為單位，每次請求傳輸時該字段數(shù)值將會根據(jù)要傳輸數(shù)據(jù)的長度而改變。

3）空行?；剀嚀Q行。

4）報文正文。報文正文是 HTTP 協(xié)議的負載，可以將圖片數(shù)據(jù)二進制流放在報文正文部分，為更清晰地描述圖片信息，可以在圖片數(shù)據(jù)頭包含一些用戶自定義的屬性，比如圖片的文件名稱和大小、拍攝時間、圖片編號等信息，以回車換行符結(jié)束。

下面是遙測站向服務(wù)器發(fā)送的一個 HTTP 請求報文，用以傳輸圖片，其中狀態(tài)行和消息報頭的每行內(nèi)容都以回車換行符結(jié)束。

回車換行

圖片二進制流。

2.3 返回響應(yīng)報文

服務(wù)器在接收到客戶端發(fā)送的 HTTP 請求報文后[5]，首先讀取狀態(tài)行，如果請求方法為 POST，并且 Content-Type 為 image/jpg，讀取長度為 Content-Length 字段鍵值的報文正文，將讀取的二進制流數(shù)據(jù)保存成圖片即可。

接下來，服務(wù)器返回客戶端 HTTP 響應(yīng)報文，響應(yīng)報文主要由以下 4 個部分組成：

1）狀態(tài)行。包括協(xié)議碼、狀態(tài)碼和狀態(tài)碼描述。

2）響應(yīng)報頭。常用的鍵值對為

a. Date：服務(wù)器時間，遙測站獲取該信息用以保持時鐘同步。

b. Content-Type：報文數(shù)據(jù)類型。

c. Content-Length：響應(yīng)正文長度。

3）回車換行。

4）響應(yīng)正文。響應(yīng)正文可以為 JSON 格式編碼正文信息，JSON 對象可以由用戶自定義。下面是服務(wù)器典型的 HTTP 響應(yīng)報文，其中狀態(tài)行和響應(yīng)報頭的每行內(nèi)容都以回車換行符結(jié)束。

2.4 關(guān)閉 TCP 連接

服務(wù)器根據(jù)客戶端發(fā)送的消息報頭中Connection 鍵值決定是否關(guān)閉連接：如果該字段為Close，服務(wù)器立即關(guān)閉 TCP 連接；如果該字段為Keep-alive，則該連接會保持一段時間，服務(wù)器在該時間內(nèi)可以繼續(xù)接收客戶端的請求，直到接收到客戶端發(fā)送消息報頭 Connection 字段為 close 的請求報文時，立即關(guān)閉連接。

通過建立 TCP 連接，發(fā)送 HTTP 請求報文，服務(wù)器返回響應(yīng)報文，關(guān)閉 TCP 連接 4 個步驟，就可以將 1 幅圖片傳輸至服務(wù)器。

3 采用 HTTP 協(xié)議傳輸圖片的特點和時效分析

3.1 特點分析

HTTP 協(xié)議通常被用來提供網(wǎng)頁瀏覽服務(wù)，只要有網(wǎng)頁信息服務(wù)就必須打開 HTTP 協(xié)議服務(wù)端口，因此各企業(yè)和單位的防火墻都針對 HTTP 協(xié)議服務(wù)端口做出特殊性重點防護，防止非法入侵。遙測站采用 HTTP 協(xié)議傳輸圖片，不需要改變中心站網(wǎng)絡(luò)設(shè)置就可以完成，適用性強，同時由于具有無連接、無狀態(tài)的特點，不易引起網(wǎng)絡(luò)安全問題，因此被廣泛采用。

相較于 2 種水利行業(yè)規(guī)約，遙測站采用 HTTP互聯(lián)網(wǎng)通用協(xié)議傳輸圖片具有以下特點：

1）HTTP 協(xié)議是一種事實上的互聯(lián)網(wǎng)通信標(biāo)準(zhǔn)，遙測站遵循 HTTP 協(xié)議傳輸圖片，可以兼容很多互聯(lián)網(wǎng)的通信應(yīng)用，實現(xiàn)跨平臺、行業(yè)、領(lǐng)域的數(shù)據(jù)傳輸。

2）HTTP 協(xié)議是 TCP/IP 協(xié)議層之上的應(yīng)用層協(xié)議，不需要考慮分包、校驗和重傳機制，數(shù)據(jù)傳輸?shù)目煽啃杂上聦?TCP/IP 負責(zé)。HTTP 協(xié)議一次性將全部數(shù)據(jù)提交給傳輸層，由 TCP/IP 負責(zé)將數(shù)據(jù)可靠地傳輸至服務(wù)器，應(yīng)用較為簡單。

3）隨著高帶寬、低延時的 4G/5G 移動通信技術(shù)的發(fā)展和信號覆蓋范圍的擴大，帶寬和速度不再是遙測站數(shù)據(jù)傳輸?shù)钠款i，采用 HTTP 協(xié)議傳輸圖片，可以充分發(fā)揮 HTTP 協(xié)議簡單靈活的特點，簡化通信流程，減輕應(yīng)用層的開發(fā)負擔(dān)。

4）隨著 SaaS（Software-as-a-Service）新的軟件應(yīng)用模式的興起，遙測站作為物聯(lián)網(wǎng)的 1 個節(jié)點，可能需要與各種軟件服務(wù)接口進行對接，這些服務(wù)接口很多都基于 TCP/IP 的通用互聯(lián)網(wǎng)協(xié)議，比如 HTTP，WebService 等接口，遙測站遵循這些標(biāo)準(zhǔn)，方便與各種服務(wù)接口對接。

5）HTTP 協(xié)議作為一種廣泛使用的互聯(lián)網(wǎng)協(xié)議，有著非常成熟的應(yīng)用框架。遙測站和中心站都遵循 HTTP 協(xié)議，用戶不需要理解和處理復(fù)雜的專用協(xié)議，通過簡單開發(fā)和軟件部署就可以建立從發(fā)送到接收完整的應(yīng)用平臺。

隨著物聯(lián)網(wǎng)技術(shù)的發(fā)展，物聯(lián)網(wǎng)常用的應(yīng)用層協(xié)議（包括 MQTT，HTTP，CoAP 等）也逐漸應(yīng)用廣泛起來，與 HTTP 通信協(xié)議一樣，MQTT 和 CoAP協(xié)議也是基于 TCP/IP 的上層應(yīng)用層協(xié)議，其中：MQTT 協(xié)議基于 TCP，請求方式遵循發(fā)布/訂閱的異步通信方式；CoAP 協(xié)議基于 UDP，請求方式和HTTP 協(xié)議一樣遵循的是請求/響應(yīng)方式。MQTT 和CoAP 協(xié)議是為計算能力有限，且工作在低帶寬、不可靠網(wǎng)絡(luò)的遠程傳感器和控制設(shè)備通信而設(shè)計的一種協(xié)議，特別適合類似傳感器數(shù)據(jù)的小數(shù)據(jù)量傳輸，而對于圖片、設(shè)備程序升級包這類數(shù)據(jù)量相對大一些的數(shù)據(jù)通常采用 HTTP 協(xié)議比較合適。

3.2 時效分析

在嵌入式系統(tǒng)中，TCP/IP 協(xié)議的應(yīng)用層不能獲取底層協(xié)議的傳輸過程信息，因此都是以固定時間間隔或者采用發(fā)送/確認方式傳輸多幀數(shù)據(jù)的。在嵌入式以太網(wǎng)環(huán)境中，IP 鏈路層數(shù)據(jù)幀 MTU（Maximum Tran-smission Unit）的最大長度通常設(shè)定為 1 500 B[6]，減去 IP 數(shù)據(jù)報、TCP 報文段和應(yīng)用層報文的首部信息，應(yīng)用層每幀數(shù)據(jù)以 1 kB 最為合適。如果要傳輸 1 幅 100 kB 大小的圖片，總共需要 100 幀數(shù)據(jù)才能完成傳輸。如果不考慮中間傳輸失敗，所有數(shù)據(jù)傳輸均為一次性完成，以 4G 移動通信網(wǎng)絡(luò)作為傳輸通道，3 種規(guī)約的時效性分析如下：

1）采用 SL 651—2014《水文監(jiān)測數(shù)據(jù)傳輸規(guī)約》“多包發(fā)送/確認”的鏈路傳輸模式，考慮到嵌入式系統(tǒng)的任務(wù)切換時間，應(yīng)用層每兩幀數(shù)據(jù)之間的時間間隔通常設(shè)置為 100～200 ms，完成所有數(shù)據(jù)傳輸至少需要 10～20 s。

2）采用 SZY 206—2016《水資源監(jiān)測數(shù)據(jù)傳輸規(guī)約》的“發(fā)送/確認”傳輸服務(wù)類別，考慮到嵌入式系統(tǒng)的任務(wù)切換和返回確認幀時間，應(yīng)用層每兩幀數(shù)據(jù)之間的時間間隔通常為 150～200 ms，完成所有數(shù)據(jù)傳輸至少需要 15～20 s。

3）采用 HTTP 協(xié)議傳輸，應(yīng)用層一次性提交所有圖片數(shù)據(jù)，不考慮分幀，底層 TCP/IP 協(xié)議進行分包傳輸，實際測試表明，1 幅 100 kB 左右的圖片傳輸可以在 5 s 內(nèi)完成。

從分析可以看出，同樣的通信條件下，傳輸相同數(shù)據(jù)量的數(shù)據(jù)，采用 HTTP 協(xié)議所用時間要少很多。

4 結(jié)語

水文自動測報系統(tǒng)中遙測站通過移動通信網(wǎng)絡(luò)或者有線以太網(wǎng)采用 HTTP 協(xié)議向中心站傳輸圖片，與水利行業(yè)傳輸規(guī)約相比，具有靈活、高效的特點，可為移動通信網(wǎng)絡(luò)覆蓋比較好或者具備有線網(wǎng)絡(luò)通信條件的遙測站傳輸圖片數(shù)據(jù)提供參考和借鑒，能夠滿足大多數(shù)對于實時性要求較高的水文自動測報系統(tǒng)的需求。對于其他類型的數(shù)據(jù)，可以根據(jù)數(shù)據(jù)大小、通信信道和具體項目應(yīng)用環(huán)境選擇合適的通信規(guī)約。

由于 HTTP 協(xié)議采用明文傳輸數(shù)據(jù)，沒有充分考慮安全性，容易被竊聽截取，對于保密數(shù)據(jù)的傳輸，可以進一步研究終端機在已經(jīng)實現(xiàn)的 HTTP 協(xié)議基礎(chǔ)上加入加密機制，采用 HTTPS 協(xié)議傳輸；HTTP 協(xié)議也支持斷點續(xù)傳功能，適合數(shù)據(jù)量特別大的數(shù)據(jù)類型的傳輸，針對斷點續(xù)傳的應(yīng)用，需要做進一步研究。