王麗紅，王夏黎，曹晨潔，趙嘉興

(長安大學 信息工程學院，陜西 西安 710064)

0 引 言

隨著信息技術的飛速發(fā)展，互聯網技術已覆蓋生活中的各個領域。用服務器推送技術[1-2]實施監(jiān)控，能夠使用戶不需要安裝應用程序，在有瀏覽器的電腦上直接進行實時監(jiān)控，減輕了監(jiān)控系統的維護成本。

HTTP協議[3]遵從在瀏覽器和服務器建立連接的請求—響應模式。Ajax輪詢[4]則遵循以固定時間間隔向瀏覽器發(fā)送請求的模式。此方式缺乏靈活性并且需要服務器具備快速處理速度。Comet技術遵循HTTP長連接[5]的通信特點。通常包括是長輪詢(Long Polling)和Iframe流兩種形式。這些技術最大的缺點就是需要由瀏覽器主動發(fā)出請求，不斷建立連接并等待服務器處理。體現了服務器的被動性。同時浪費帶寬和網絡資源。Websocket技術使用基于瀏覽器-服務器的雙向通信模式，瀏覽可以基于時間的方式與服務器實現真正的實時通信[6]。

基于Websocket技術的橋梁結構變形遠程實時監(jiān)測系統[7-8]可以對橋梁建設及后期維護中對橋梁數據進行遠程實時監(jiān)控、數據存儲和歷史查詢。此系統實現了集遠程化與網絡化為一體的實時監(jiān)控[9]。

1 基于Websocket的實時通信技術

1.1 相關實時通信技術

1.1.1 Ajax輪詢技術

Ajax輪詢技術[10]采用不需驗證服務器接收數據與否，而是使客戶端定時向服務器發(fā)送請求并接收返回的響應的模式。該模式缺點為定時性，即瀏覽器-服務器之間的數據傳輸需定時，且HTTP請求可能包含較長的頭部，需傳輸數據僅為全部數據的一部分。顯然此通信方式會極大地浪費服務器的帶寬和資源。

1.1.2 Long Polling技術

基于以上缺陷，可采用Ajax的優(yōu)化技術—Long Polling技術。該技術旨在服務器添加了檢驗更新數據的功能，服務器只有得到新數據后才向客戶端傳輸數據內容。否則會進入持續(xù)等待狀態(tài)，若等待時間過長，客戶端就會重新向客戶端發(fā)送HTTP請求。這種連接方式雖然實現了服務端主動傳輸消息，但是仍然需要頻繁發(fā)出請求。還是會存在服務器端浪費帶寬和資源的問題。

1.1.3 基于Iframe的流方式

Iframe是HTML中的標簽，把它的屬性設置為隱藏并且將它的src屬性設置為對長連接的請求，然后服務器就可持續(xù)向客戶端推送數據。其缺點為IE與Firefox底部進度條顯示加載未完成，但IE中圖表則顯示加載正在進行，這會給用戶一種正在加載的錯覺。

1.1.4 SSE技術

SSE(server sent events)的通信原理和基于Iframe實時通信技術相似。服務器端的響應內容類型必須為“text/event-stream”，當連接建立之后，服務端就能夠不斷向服務器端推送數據。然而這種技術并不是很好地支持IE瀏覽器，使用具有局限性。只能服務器-瀏覽器單向發(fā)送數據。

1.2 基于Websocket的實時通信技術

1.2.1 Websocket協議概述

Websocket協議是在TCP協議基礎上發(fā)展起來的一種新網絡協議。在建立連接時，客戶端向服務器發(fā)起包含升級為ws協議附加頭信息的“握手”HTTP請求。服務器在解析完頭信息后，將信息響應給客戶端，只要“握手”操作完成并成功，就表明Websocket連接就被成功建立，連接后只有客戶端或者服務器其中的一方關閉，連接才會被斷開，否則雙方就持續(xù)交互。

1.2.2 Websocket工作原理

Websocket協議建立連接步驟如下：

(1)Websocket客戶端發(fā)送HTTP升級請求。

Websocket客戶端發(fā)起“握手”請求到服務器。定義URI：

ws-URI=ws://127.0.0.1:8080/

具體客戶端握手消息如圖1所示，其中Connection：Upgrade表示該請求為協議升級請求；Upgrade：Websocket表示升級到Websocket協議，Sec-WebSocket-Key用來驗證Websocket連接是否有效。

圖1 Websocket客戶端握手消息

(2)服務器接收服務端握手信息，并發(fā)送服務器打開握手的信息。

服務器通過請求的頭部信息確定是否為Websocket請求。并通過規(guī)定算法將Sec-WebSocket-Key的信息生成新字符串序列，然后把它寫入Sec-WebSocket-Accept內。具體Websocket服務器響應如圖2所示。

圖2 Websocket服務器響應消息

(3)客戶端驗證服務器的響應。

客戶端收到服務器響應后，驗證服務器是否收到協議升級請求，并返回握手應答報文。

只要Websocket連接建立，就會啟動全雙工通信，客戶端和服務器就可以實時地向對方發(fā)送消息，直到某一方關閉連接。Websocket 通信模型如圖3所示。

Websocket技術通過升級協議，不用發(fā)送大量頭部信息，輕量且速度快。真正地雙向通信，減少了不必要的開銷，該方案大大提高了通信的實時性。

總結以上幾種實時通信技術，其特性如表1所示。

圖3 Websocket模型通信原理

表1 幾種實時通信方式比較

從表1可以看出，Websocket在傳輸數據時只需一次連接建立，并且可以實現網頁中長久實時信息的交互。在實時通信技術中有很大的優(yōu)勢。

隨著橋梁規(guī)模及建設速度的提升，隨之發(fā)生的安全事故也層出不窮，橋梁的變形監(jiān)測尤其重要。基于Websocket技術的橋梁結構變形實時監(jiān)測系統，可以在有網絡的情況下，隨時隨地實時監(jiān)測橋梁結構變形數據情況并對橋梁健康狀況進行評估，從而實時智能地對橋梁故障進行診斷和維護。這對橋梁的正確施工和后期橋梁的健康狀況監(jiān)測具有重要作用。

2 系統設計

在橋梁的建設過程中，橋梁的準確施工關系著整個橋梁施工工程的質量以及施工成本，后期橋梁的安全性更關系著整個道路的暢通。因此，對橋梁結構變形進行實時監(jiān)測在確保橋梁正確施工以及確定及時有效的維護養(yǎng)護方案等方面顯得尤為重要。

隨著監(jiān)測技術的不斷提升，橋梁結構變形實時監(jiān)測的方法也越來越多。如傳感器技術監(jiān)測、GPS技術監(jiān)測、三維激光掃描技術監(jiān)測等，然而這些橋梁遠程監(jiān)測監(jiān)控系統基本采用軟件式開發(fā)。文中從便捷的角度出發(fā)，提前獲取到橋梁結構變形監(jiān)測數據，設計了基于Websocket技術的橋梁結構變形實時監(jiān)測系統，并加以實現，此系統在有網絡的前提下可對橋梁結構變形情況實時監(jiān)測、橋梁健康及時評估及對橋梁故障實時診斷和維護。對橋梁的正確施工和后期橋梁的健康狀況監(jiān)測具有重要作用。

該系統前端頁面開發(fā)設計，引入Echarts圖表庫，結合以Json為數據傳輸格式的Websocket技術，同步獲取Websocket客戶端數據，圖形化展示數據，通過界面實現用戶數據良好交互。

2.1 系統設計

完整的監(jiān)控系統需要考慮的特性包括數據的可靠性、實時性、安全性和完整性等。實時性即監(jiān)控系統對數據無延遲的及時傳輸，避免了難以發(fā)現及時數據異常的問題。數據的完整性即接收到的橋梁數據不能有丟失。否則數據的完整性不能保障。如果監(jiān)控系統的上述特性無法得到保障，那么現場監(jiān)控也就失去了實際價值。

此監(jiān)測系統主要包括：數據實時采集，數據處理，數據傳輸、顯示和存儲等功能。

此監(jiān)測系統由數據接收器、連接器、Web服務器和瀏覽器4部分構成?；具^程如圖4所示。Grpc服務端負責實時接收橋梁數據并對數據進行初步的處理和存儲，然后所有客戶端接收Websocket服務端發(fā)送的數據，并利用網頁中的JavaScript對數據進行簡單處理，最后使用圖庫表Echarts展示數據。

圖4 監(jiān)控系統流程

2.2 系統關鍵技術

2.2.1 Grpc通信

采用HTTP/2協議，用ProtoBuf作為序列化工具的Grpc框架[11]是由Google開發(fā)。其客戶端和服務器端都提供多種語言接口。該框架是先在proto文件里定義一個service，指定被遠程調用的方法，然后在Grpc服務端重寫接口函數并且處理客戶端調用。它最大的優(yōu)勢就是采用ProtoBuf協議，將proto類型文件生成所需程序，簡單易用。

2.2.2 Echarts

由JS(JavaScript)開發(fā)的Echarts[12]圖庫表，可以通過數據動態(tài)變化來驅動圖表改變，考慮到移動端的顯示，使用代碼重構，使得Echarts庫體積較小。本項目橋梁監(jiān)測數據即使用Echarts實現數據的圖形化顯示，只要Websocket服務器發(fā)送數據，就會刷新界面，更新圖表信息。

2.2.3 Django框架

Django框架[13]采用MTV模式即模型—模板—視圖模式，“M”為“Model”、“T”為“Templates”、“V”為“Views”。使用該模式可對系統內組件的耦合關系進行控制，使得各個組件之間互不影響。同時Django提供的ORM機制方便用戶定義所需數據模型，降低了對數據庫開發(fā)的編程壓力。

2.3 系統詳細設計

基于對系統平臺的需求分析，文中對基于Websocket技術的橋梁結構變形遠程實時監(jiān)測系統[14-15]進行詳細設計，將此系統分為五個模塊：數據采集模塊、數據存儲模塊、實時監(jiān)控模塊、歷史記錄查詢模塊、用戶管理模塊。

2.4 系統實現

基于Websocket技術的橋梁結構變形實時監(jiān)測系統[16]的實現也分為五個模塊，其中在數據采集模塊采用Grpc通信技術，在實時監(jiān)測模塊采用Websocket技術完成對數據的實時交互。

(1)數據采集模塊。

數據采集模塊即開啟gRPC服務端后，只要有遠程Grpc客戶端啟動，數據便開始傳輸，服務端接收數據并按照規(guī)定編碼方式進行解碼，數據采集過程完成。

(2)數據存儲模塊。

數據存儲模塊即gRPC提取到數據后，對數據進行簡單處理后，連接數據庫，存入數據庫。

(3)實時監(jiān)測模塊。

在此系統[17]中，gRPC模塊嵌入到Django框架，當項目啟動后，gRPC服務端啟動，此時將gRPC接收的數據進行簡單處理后存儲到數據庫的同時，傳入到Websocket服務端，Websocket服務端會主動將數據傳輸到頁面的Websocket客戶端，再通過Echarts展示數據的變化情況。同時可以查看項目初次建立時的圖片信息，也可以查詢當數據超過設定的閾值異常后的圖像信息。

(4)歷史記錄查詢模塊。

歷史記錄查詢模塊主要是通過選擇項目，任務，時間等條件，連接數據庫，通過Echarts可視化方法來展示此項目在這段時間內的數據變化。

(5)用戶管理模塊。

用戶管理模塊使得管理員可增刪查改用戶，用戶也可自行修改信息等。

3 系統測試

3.1 功能測試

對系統的功能模塊進行測試，模塊正常運行，已達預期效果。系統主要功能的測試結果如表2所示。

表2 系統主要功能測試結果

3.2 性能測試

3.2.1 測試指標

在多用戶同時進行數據監(jiān)控時，整體系統多方面的性能指標，重點描述下述幾個方面：

Vuser圖：虛擬情況下的用戶數，擬說明各網站能夠同時支持的并發(fā)用戶數。

Throughput圖：吞吐量圖，顯示方案運行中服務器的吞吐量。吞吐量的單位為字節(jié)/秒。反映了網站服務器的數據傳輸能力。

Websocket Statistics圖：Websocket靜態(tài)圖，顯示方案運行時Websocket服務器接收及發(fā)送的數據量。

3.2.2 測試方法

在系統性能的監(jiān)測層面，借助LoadRunner12來組件網站的仿真性測驗。依次選擇具備代表性的模塊開展具體的加壓，依照所有模塊的實際運用人數，來對網站開展仿真性的測驗，以借助該措施來發(fā)現系統性能方面的缺陷，并對系統做出進一步的改善。

3.2.3 測試結果

經過性能測試，發(fā)現通過50個用戶對系統進行循環(huán)迭代20分鐘周期內訪問，Vuser用戶在測試期間的每一秒都正常運行和退出成功，如圖5所示。Vuser在每一秒內從服務器獲得的數據量達到140 000字節(jié)，反映了網站網絡帶寬的處理能力業(yè)務較強，如圖6所示。Websocket客戶端接收和發(fā)送的字節(jié)數都和實際相符，如圖7所示。本次測試結果滿足本次項目設計要求。

圖5 Vuser圖

圖6 Throughput圖

圖7 Websocket Statistics圖

4 結束語

對常用的幾種實時通信技術的通信原理進行了剖析，對基于Websocket協議的實時通信技術進行了重點分析，通過案例分析、技術比較，Websocket技術優(yōu)勢明顯，所以選用Websocket技術實現了基于Websocket技術的橋梁結構變形實時監(jiān)測系統，編寫測試用例，采用loadrunner工具進行網站性能測試，經過多次的測試和豐富的用例，測試結果顯示Websocket技術達到了預期效果。此系統通過對橋梁結構變形實時監(jiān)控產生的數據進行展示與分析，及時發(fā)現橋梁異常情況，大大發(fā)揮監(jiān)控平臺的作用，減少了因橋梁結構變形而造成的經濟損失，達到了實時監(jiān)控的目的。