基于Websocket的橋梁結(jié)構(gòu)變形實(shí)時(shí)監(jiān)測(cè)系統(tǒng)設(shè)計(jì)

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

(長(zhǎng)安大學(xué) 信息工程學(xué)院，陜西 西安 710064)

0 引 言

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

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

基于Websocket技術(shù)的橋梁結(jié)構(gòu)變形遠(yuǎn)程實(shí)時(shí)監(jiān)測(cè)系統(tǒng)[7-8]可以對(duì)橋梁建設(shè)及后期維護(hù)中對(duì)橋梁數(shù)據(jù)進(jìn)行遠(yuǎn)程實(shí)時(shí)監(jiān)控、數(shù)據(jù)存儲(chǔ)和歷史查詢。此系統(tǒng)實(shí)現(xiàn)了集遠(yuǎn)程化與網(wǎng)絡(luò)化為一體的實(shí)時(shí)監(jiān)控[9]。

1 基于Websocket的實(shí)時(shí)通信技術(shù)

1.1 相關(guān)實(shí)時(shí)通信技術(shù)

1.1.1 Ajax輪詢技術(shù)

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

1.1.2 Long Polling技術(shù)

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

1.1.3 基于Iframe的流方式

Iframe是HTML中的標(biāo)簽，把它的屬性設(shè)置為隱藏并且將它的src屬性設(shè)置為對(duì)長(zhǎng)連接的請(qǐng)求，然后服務(wù)器就可持續(xù)向客戶端推送數(shù)據(jù)。其缺點(diǎn)為IE與Firefox底部進(jìn)度條顯示加載未完成，但I(xiàn)E中圖表則顯示加載正在進(jìn)行，這會(huì)給用戶一種正在加載的錯(cuò)覺(jué)。

1.1.4 SSE技術(shù)

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

1.2 基于Websocket的實(shí)時(shí)通信技術(shù)

1.2.1 Websocket協(xié)議概述

Websocket協(xié)議是在TCP協(xié)議基礎(chǔ)上發(fā)展起來(lái)的一種新網(wǎng)絡(luò)協(xié)議。在建立連接時(shí)，客戶端向服務(wù)器發(fā)起包含升級(jí)為ws協(xié)議附加頭信息的“握手”HTTP請(qǐng)求。服務(wù)器在解析完頭信息后，將信息響應(yīng)給客戶端，只要“握手”操作完成并成功，就表明Websocket連接就被成功建立，連接后只有客戶端或者服務(wù)器其中的一方關(guān)閉，連接才會(huì)被斷開(kāi)，否則雙方就持續(xù)交互。

1.2.2 Websocket工作原理

Websocket協(xié)議建立連接步驟如下：

(1)Websocket客戶端發(fā)送HTTP升級(jí)請(qǐng)求。

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

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

具體客戶端握手消息如圖1所示，其中Connection：Upgrade表示該請(qǐng)求為協(xié)議升級(jí)請(qǐng)求；Upgrade：Websocket表示升級(jí)到Websocket協(xié)議，Sec-WebSocket-Key用來(lái)驗(yàn)證Websocket連接是否有效。

圖1 Websocket客戶端握手消息

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

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

圖2 Websocket服務(wù)器響應(yīng)消息

(3)客戶端驗(yàn)證服務(wù)器的響應(yīng)。

客戶端收到服務(wù)器響應(yīng)后，驗(yàn)證服務(wù)器是否收到協(xié)議升級(jí)請(qǐng)求，并返回握手應(yīng)答報(bào)文。

只要Websocket連接建立，就會(huì)啟動(dòng)全雙工通信，客戶端和服務(wù)器就可以實(shí)時(shí)地向?qū)Ψ桨l(fā)送消息，直到某一方關(guān)閉連接。Websocket 通信模型如圖3所示。

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

總結(jié)以上幾種實(shí)時(shí)通信技術(shù)，其特性如表1所示。

圖3 Websocket模型通信原理

表1 幾種實(shí)時(shí)通信方式比較

從表1可以看出，Websocket在傳輸數(shù)據(jù)時(shí)只需一次連接建立，并且可以實(shí)現(xiàn)網(wǎng)頁(yè)中長(zhǎng)久實(shí)時(shí)信息的交互。在實(shí)時(shí)通信技術(shù)中有很大的優(yōu)勢(shì)。

隨著橋梁規(guī)模及建設(shè)速度的提升，隨之發(fā)生的安全事故也層出不窮，橋梁的變形監(jiān)測(cè)尤其重要?；赪ebsocket技術(shù)的橋梁結(jié)構(gòu)變形實(shí)時(shí)監(jiān)測(cè)系統(tǒng)，可以在有網(wǎng)絡(luò)的情況下，隨時(shí)隨地實(shí)時(shí)監(jiān)測(cè)橋梁結(jié)構(gòu)變形數(shù)據(jù)情況并對(duì)橋梁健康狀況進(jìn)行評(píng)估，從而實(shí)時(shí)智能地對(duì)橋梁故障進(jìn)行診斷和維護(hù)。這對(duì)橋梁的正確施工和后期橋梁的健康狀況監(jiān)測(cè)具有重要作用。

2 系統(tǒng)設(shè)計(jì)

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

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

該系統(tǒng)前端頁(yè)面開(kāi)發(fā)設(shè)計(jì)，引入Echarts圖表庫(kù)，結(jié)合以Json為數(shù)據(jù)傳輸格式的Websocket技術(shù)，同步獲取Websocket客戶端數(shù)據(jù)，圖形化展示數(shù)據(jù)，通過(guò)界面實(shí)現(xiàn)用戶數(shù)據(jù)良好交互。

2.1 系統(tǒng)設(shè)計(jì)

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

此監(jiān)測(cè)系統(tǒng)主要包括：數(shù)據(jù)實(shí)時(shí)采集，數(shù)據(jù)處理，數(shù)據(jù)傳輸、顯示和存儲(chǔ)等功能。

此監(jiān)測(cè)系統(tǒng)由數(shù)據(jù)接收器、連接器、Web服務(wù)器和瀏覽器4部分構(gòu)成。基本過(guò)程如圖4所示。Grpc服務(wù)端負(fù)責(zé)實(shí)時(shí)接收橋梁數(shù)據(jù)并對(duì)數(shù)據(jù)進(jìn)行初步的處理和存儲(chǔ)，然后所有客戶端接收Websocket服務(wù)端發(fā)送的數(shù)據(jù)，并利用網(wǎng)頁(yè)中的JavaScript對(duì)數(shù)據(jù)進(jìn)行簡(jiǎn)單處理，最后使用圖庫(kù)表Echarts展示數(shù)據(jù)。

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

2.2 系統(tǒng)關(guān)鍵技術(shù)

2.2.1 Grpc通信

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

2.2.2 Echarts

由JS(JavaScript)開(kāi)發(fā)的Echarts[12]圖庫(kù)表，可以通過(guò)數(shù)據(jù)動(dòng)態(tài)變化來(lái)驅(qū)動(dòng)圖表改變，考慮到移動(dòng)端的顯示，使用代碼重構(gòu)，使得Echarts庫(kù)體積較小。本項(xiàng)目橋梁監(jiān)測(cè)數(shù)據(jù)即使用Echarts實(shí)現(xiàn)數(shù)據(jù)的圖形化顯示，只要Websocket服務(wù)器發(fā)送數(shù)據(jù)，就會(huì)刷新界面，更新圖表信息。

2.2.3 Django框架

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

2.3 系統(tǒng)詳細(xì)設(shè)計(jì)

基于對(duì)系統(tǒng)平臺(tái)的需求分析，文中對(duì)基于Websocket技術(shù)的橋梁結(jié)構(gòu)變形遠(yuǎn)程實(shí)時(shí)監(jiān)測(cè)系統(tǒng)[14-15]進(jìn)行詳細(xì)設(shè)計(jì)，將此系統(tǒng)分為五個(gè)模塊：數(shù)據(jù)采集模塊、數(shù)據(jù)存儲(chǔ)模塊、實(shí)時(shí)監(jiān)控模塊、歷史記錄查詢模塊、用戶管理模塊。

2.4 系統(tǒng)實(shí)現(xiàn)

基于Websocket技術(shù)的橋梁結(jié)構(gòu)變形實(shí)時(shí)監(jiān)測(cè)系統(tǒng)[16]的實(shí)現(xiàn)也分為五個(gè)模塊，其中在數(shù)據(jù)采集模塊采用Grpc通信技術(shù)，在實(shí)時(shí)監(jiān)測(cè)模塊采用Websocket技術(shù)完成對(duì)數(shù)據(jù)的實(shí)時(shí)交互。

(1)數(shù)據(jù)采集模塊。

數(shù)據(jù)采集模塊即開(kāi)啟gRPC服務(wù)端后，只要有遠(yuǎn)程Grpc客戶端啟動(dòng)，數(shù)據(jù)便開(kāi)始傳輸，服務(wù)端接收數(shù)據(jù)并按照規(guī)定編碼方式進(jìn)行解碼，數(shù)據(jù)采集過(guò)程完成。

(2)數(shù)據(jù)存儲(chǔ)模塊。

數(shù)據(jù)存儲(chǔ)模塊即gRPC提取到數(shù)據(jù)后，對(duì)數(shù)據(jù)進(jìn)行簡(jiǎn)單處理后，連接數(shù)據(jù)庫(kù)，存入數(shù)據(jù)庫(kù)。

(3)實(shí)時(shí)監(jiān)測(cè)模塊。

在此系統(tǒng)[17]中，gRPC模塊嵌入到Django框架，當(dāng)項(xiàng)目啟動(dòng)后，gRPC服務(wù)端啟動(dòng)，此時(shí)將gRPC接收的數(shù)據(jù)進(jìn)行簡(jiǎn)單處理后存儲(chǔ)到數(shù)據(jù)庫(kù)的同時(shí)，傳入到Websocket服務(wù)端，Websocket服務(wù)端會(huì)主動(dòng)將數(shù)據(jù)傳輸?shù)巾?yè)面的Websocket客戶端，再通過(guò)Echarts展示數(shù)據(jù)的變化情況。同時(shí)可以查看項(xiàng)目初次建立時(shí)的圖片信息，也可以查詢當(dāng)數(shù)據(jù)超過(guò)設(shè)定的閾值異常后的圖像信息。

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

歷史記錄查詢模塊主要是通過(guò)選擇項(xiàng)目，任務(wù)，時(shí)間等條件，連接數(shù)據(jù)庫(kù)，通過(guò)Echarts可視化方法來(lái)展示此項(xiàng)目在這段時(shí)間內(nèi)的數(shù)據(jù)變化。

(5)用戶管理模塊。

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

3 系統(tǒng)測(cè)試

3.1 功能測(cè)試

對(duì)系統(tǒng)的功能模塊進(jìn)行測(cè)試，模塊正常運(yùn)行，已達(dá)預(yù)期效果。系統(tǒng)主要功能的測(cè)試結(jié)果如表2所示。

表2 系統(tǒng)主要功能測(cè)試結(jié)果

3.2 性能測(cè)試

3.2.1 測(cè)試指標(biāo)

在多用戶同時(shí)進(jìn)行數(shù)據(jù)監(jiān)控時(shí)，整體系統(tǒng)多方面的性能指標(biāo)，重點(diǎn)描述下述幾個(gè)方面：

Vuser圖：虛擬情況下的用戶數(shù)，擬說(shuō)明各網(wǎng)站能夠同時(shí)支持的并發(fā)用戶數(shù)。

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

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

3.2.2 測(cè)試方法

在系統(tǒng)性能的監(jiān)測(cè)層面，借助LoadRunner12來(lái)組件網(wǎng)站的仿真性測(cè)驗(yàn)。依次選擇具備代表性的模塊開(kāi)展具體的加壓，依照所有模塊的實(shí)際運(yùn)用人數(shù)，來(lái)對(duì)網(wǎng)站開(kāi)展仿真性的測(cè)驗(yàn)，以借助該措施來(lái)發(fā)現(xiàn)系統(tǒng)性能方面的缺陷，并對(duì)系統(tǒng)做出進(jìn)一步的改善。

3.2.3 測(cè)試結(jié)果

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

圖5 Vuser圖

圖6 Throughput圖

圖7 Websocket Statistics圖

4 結(jié)束語(yǔ)

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