基于Websocket的橋梁結構變形實時監測系統設計

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

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

0 引 言

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

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

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

1 基于Websocket的實時通信技術

1.1 相關實時通信技術

1.1.1 Ajax輪詢技術

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

1.1.2 Long Polling技術

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

1.1.3 基于Iframe的流方式

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

1.1.4 SSE技術

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

1.2 基于Websocket的實時通信技術

1.2.1 Websocket協議概述

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

1.2.2 Websocket工作原理

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

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

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

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

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

圖1 Websocket客戶端握手消息

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

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

圖2 Websocket服務器響應消息

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

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

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

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

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

圖3 Websocket模型通信原理

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

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

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

2 系統設計

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

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

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

2.1 系統設計

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

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

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

圖4 監控系統流程

2.2 系統關鍵技術

2.2.1 Grpc通信

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

2.2.2 Echarts

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

2.2.3 Django框架

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

2.3 系統詳細設計

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

2.4 系統實現

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

(1)數據采集模塊。

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

(2)數據存儲模塊。

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

(3)實時監測模塊。

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

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

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

(5)用戶管理模塊。

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

3 系統測試

3.1 功能測試

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

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

3.2 性能測試

3.2.1 測試指標

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

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

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

Websocket Statistics圖：Websocket靜態圖，顯示方案運行時Websocket服務器接收及發送的數據量。

3.2.2 測試方法

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

3.2.3 測試結果

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

圖5 Vuser圖

圖6 Throughput圖

圖7 Websocket Statistics圖

4 結束語

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