遙測(cè)站采用 HTTP 協(xié)議傳輸圖片的應(yīng)用研究

熊啟龍

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

2.1 建立 TCP 連接

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

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

2.2 發(fā)送 HTTP 請(qǐng)求報(bào)文

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

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

2）消息報(bào)頭。常用的鍵值對(duì)為

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

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

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

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

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

3）空行?；剀嚀Q行。

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

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

回車換行

圖片二進(jìn)制流。

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

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

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

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

2）響應(yīng)報(bào)頭。常用的鍵值對(duì)為

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

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

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

3）回車換行。

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

2.4 關(guān)閉 TCP 連接

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

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

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

3.1 特點(diǎn)分析

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

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

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

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

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

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

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

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

3.2 時(shí)效分析

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

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

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

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

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

4 結(jié)語(yǔ)

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

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