摘 要:推送技術(shù)以其實時性高和資源占用小等諸多優(yōu)點,逐漸得到應(yīng)用。首先介紹了煤礦Web實時監(jiān)測系統(tǒng)發(fā)展現(xiàn)狀,并分析了這一實時系統(tǒng)的主要特點;其次,對比了輪詢和推送兩種實時監(jiān)測技術(shù)的工作原理及其優(yōu)缺點;最后,介紹了推送技術(shù)的主要實現(xiàn)方式。
關(guān)鍵詞:推送;實時;監(jiān)測系統(tǒng);輪詢
中圖分類號:TP391
近年來,煤礦各種安全事故頻發(fā),為保障煤礦安全生產(chǎn)和職工人身安全,防止煤礦事故,2006年底,國家安監(jiān)總局發(fā)布的《關(guān)于修改〈煤礦安全規(guī)程〉第六十八條和第一百五十八條的決定》中明確指出:所有礦井必須裝備礦井安全監(jiān)控系統(tǒng)[1]。隨后,越來越多的煤礦企業(yè)配備安裝了各種安全監(jiān)控監(jiān)測設(shè)備,這大大提升了煤礦安全生產(chǎn)水平,降低了事故發(fā)生率。伴隨著硬件裝備的不斷升級,與之配套的實時監(jiān)測系統(tǒng)也得到了較快發(fā)展,尤其是基于B/S架構(gòu)的Web實時監(jiān)測系統(tǒng),以其使用方便、易于維護(hù)、信息資料共享程度高等優(yōu)點,被廣泛應(yīng)用于煤礦實時監(jiān)測系統(tǒng)中。一些新的信息交互技術(shù)被應(yīng)用于系統(tǒng)中,使得系統(tǒng)的實時性、友好性等方面都有了較大提升。目前,廣泛采用輪詢方式實現(xiàn)信息的實時展示,但這種效率低下的方式已經(jīng)逐漸無法滿足不斷提升的煤礦Web系統(tǒng)的實時性要求,并且對網(wǎng)絡(luò)帶寬和服務(wù)端資源都造成了很大的壓力。
針對上述情況,本文介紹了目前新興的實時信息交互技術(shù)-推送技術(shù),這一技術(shù)不僅為監(jiān)測系統(tǒng)帶來了更高的實時性,也極大的降低了服務(wù)器資源和網(wǎng)絡(luò)帶寬的壓力,提升了煤礦安全生產(chǎn)管理的信息化水平。
1 實時監(jiān)測系統(tǒng)的信息交互模式
煤礦實時監(jiān)測系統(tǒng),要求將監(jiān)測到的最新數(shù)據(jù)在第一時間顯示到系統(tǒng)中,以便監(jiān)控人員及時根據(jù)信息做出響應(yīng)。根據(jù)煤礦監(jiān)測的特點,其監(jiān)測的數(shù)據(jù)變化時間不定,有些數(shù)據(jù)的實時性很強,比如風(fēng)速或瓦斯?jié)舛鹊?;另有一些?shù)據(jù),例如風(fēng)門設(shè)備的開停狀態(tài),變化頻率就很低。對于這種要求實時性高卻數(shù)據(jù)更新周期不定的系統(tǒng),就需要有一個數(shù)據(jù)交互機制來滿足這類實時監(jiān)測的要求。傳統(tǒng)模式和基于推送技術(shù)的模式都可實現(xiàn)這類需求,但有截然不同的工作原理。
1.1 傳統(tǒng)的實時監(jiān)測模式
理想的實時監(jiān)測系統(tǒng)應(yīng)該是當(dāng)服務(wù)端識別到數(shù)據(jù)發(fā)生變化時,立刻主動將數(shù)據(jù)發(fā)送給客戶端。然而,HTTP作為客戶端-服務(wù)器通信的標(biāo)準(zhǔn)協(xié)議,它是無狀態(tài)的,而且在某種意義上來說,也是一種單向的協(xié)議。HTTP場景中所有通信都必須由客戶端發(fā)起,至服務(wù)器結(jié)束,服務(wù)器端僅是被動等待客戶端發(fā)出請求之后將數(shù)據(jù)傳送給客戶端。這與實時監(jiān)測系統(tǒng)的場景要求恰好相反。為了實現(xiàn)數(shù)據(jù)更新,Web開發(fā)人員采用一種稱為輪詢的方式,客戶端會以固定的時間間隔與服務(wù)器聯(lián)系,查找是否有新數(shù)據(jù)可用,如圖1所示,為輪詢的工作原理。但這實際上是一種偽實時場景,數(shù)據(jù)雖然被以一定頻率顯示到客戶端,但無法與數(shù)據(jù)更新頻率完全一致,這種更新機制不是真正意義上的實時更新。
圖1 輪詢工作原理
從圖1例子可知,這段時間內(nèi)客戶端以固定間隔請求服務(wù)器5次,服務(wù)器響應(yīng)了5次,其中僅有2次響應(yīng)包含了最新數(shù)據(jù),且最新數(shù)據(jù)只是在數(shù)據(jù)更新之后的最近一次輪詢響應(yīng)后才發(fā)送到客戶端。
輪詢方式已經(jīng)廣泛用于煤礦Web監(jiān)測系統(tǒng)中,其主要優(yōu)點是實現(xiàn)簡單。這種方式只要客戶端加入定時獲取數(shù)據(jù)的少量腳本代碼,即可實現(xiàn)數(shù)據(jù)的持續(xù)更新。一些成熟的技術(shù)如Ajax,是目前最廣泛的實現(xiàn)方式。
然而,輪詢也存在著較大問題,主要有以下兩方面:(1)資源消耗大。在大多數(shù)時候,輪詢純粹是浪費,因而服務(wù)器沒有任何更新。這種方法不是沒有代價的,它有兩大問題。一方面,這種方法極度浪費網(wǎng)絡(luò)資源。每一個輪詢請求都會創(chuàng)建一個TCP套接字連接,套接字連接本身代價極高,需要服務(wù)器更多的CPU和內(nèi)存資源;另一方面,每次請求都要在網(wǎng)絡(luò)上傳輸一些數(shù)據(jù),如果請求未在服務(wù)器上發(fā)現(xiàn)任何更新,那么這樣的數(shù)據(jù)傳輸就是浪費帶寬資源。(2)實時性差??紤]到輪詢的頻率,這樣的更新并不是實時的。例如,輪詢方式采用固定的時間間隔請求數(shù)據(jù),如果在下一個請求周期到來之前,數(shù)據(jù)發(fā)生多次變化,用戶將只能看到最后一次的新數(shù)據(jù)而錯過某些數(shù)據(jù),無法實時看到所有變化。這就要求請求的時間間隔與數(shù)據(jù)更新時間完全匹配,這對于數(shù)據(jù)更新周期不定的系統(tǒng)來說,是不可能的。對于需要以盡可能實時方式運行的應(yīng)用程序來說,這樣的等待也是不可接受的??紤]到如上兩大問題,對于需要關(guān)鍵、實時的服務(wù)器端更新的企業(yè)應(yīng)用程序而言,輪詢并非最佳方案。
1.2 基于推送技術(shù)的實時監(jiān)測模式
為解決輪詢方式資源占用大和實時性差等問題,開發(fā)人員采用了一種稱為推送的方式,實現(xiàn)了更為有效的Web實時監(jiān)測系統(tǒng)。推送是一種主動從Web服務(wù)器發(fā)送數(shù)據(jù)到瀏覽器的機制。雖然HTTP協(xié)議并無相關(guān)配置來直接實現(xiàn)此機制,開發(fā)人員使用各種獨創(chuàng)方法來繞過這些問題,從而使得推送得以實現(xiàn)。如圖2所示,為推送的工作原理。
圖2 推送工作原理
從圖2中例子可知,這段時間內(nèi)客戶端僅在首次建立了請求連接,之后沒有請求。服務(wù)端響應(yīng)了2次,這2次都包含了最新數(shù)據(jù),最新數(shù)據(jù)在到達(dá)服務(wù)器第一時間發(fā)送到客戶端,沒有延遲。
推送技術(shù)主要有如下優(yōu)點:(1)實時性強。推送正是為了滿足Web系統(tǒng)更高實時性的要求應(yīng)運而生的。服務(wù)器端完全能夠控制更新數(shù)據(jù)的時間和頻率,與傳統(tǒng)輪詢請求更新的模式相比,實現(xiàn)了真正意義上的實時更新。(2)資源消耗少。推送技術(shù)由于一直保持連接,不像輪詢每次都要進(jìn)行重新建立連接和發(fā)送完整而冗余的信息,這對于網(wǎng)絡(luò)帶寬的占用和服務(wù)器CPU資源及內(nèi)存消耗都較小。當(dāng)然,由于始終保持連接,即使無數(shù)據(jù)傳輸時也如此,因此服務(wù)器必須為每個推送鏈接分配并讓其一直占用一個TCP套接字連接,這對于TCP/IP端口數(shù)有限的服務(wù)器是一個必須關(guān)注的問題。只要將推送技術(shù)主要用于實時性要求強的核心模塊,這一資源消耗是可以忽略了。
推送技術(shù)目前存在的主要不足是實現(xiàn)方式較為復(fù)雜。由于HTTP協(xié)議在底層不直接提供對推送的支持,因此實現(xiàn)推送的方式并不容易。另外,開發(fā)人員固有的研發(fā)思路和開發(fā)模式,也使得對推送這一新技術(shù)的學(xué)習(xí)曲線較為陡峭。隨著對推送技術(shù)的深入研究和廣泛應(yīng)用,其學(xué)習(xí)難度在逐漸下降,實現(xiàn)方式也在不斷簡化和完善。
2 推送技術(shù)的實現(xiàn)方式
推送技術(shù)在應(yīng)用中已有不少解決方案,主要分為兩類:一類采用瀏覽器插件技術(shù)(ActiveX、Applet、Flash),基于套接口傳送信息,或是使用RMI、CORBA進(jìn)行遠(yuǎn)程調(diào)用[2];另一類則無需安裝插件,基于HTTP長鏈接或最新的HTTP5標(biāo)準(zhǔn)。以下介紹幾種常見的推送實現(xiàn)技術(shù)。
2.1 Comet
Comet是基于HTTP長連接的推送技術(shù),有流方式和長輪詢方式。其工作原理是:用戶發(fā)起請求后就掛起,等待服務(wù)器返回數(shù)據(jù),在此期間不會斷開連接。流和長輪詢方式的區(qū)別是:前者在客戶端發(fā)起連接就不會斷開連接,并由服務(wù)器端進(jìn)行控制。當(dāng)服務(wù)器端有更新時,刷新數(shù)據(jù),客戶端進(jìn)行更新;而后者是當(dāng)服務(wù)器端有更新返回,客戶端先斷開連接,進(jìn)行處理,然后重新發(fā)起連接。
Comet雖然可達(dá)到雙向通信,但依然需要發(fā)出請求,而且會大量消耗服務(wù)器帶寬和資源。
2.2 WebSocket
WebSocket是HTML5標(biāo)準(zhǔn)中的一種新協(xié)議,它支持瀏覽器與服務(wù)器的雙向通信[3],只需要一個握手動作,瀏覽器和服務(wù)器之間就形成了一條快速通道以便互相傳送數(shù)據(jù)。這一技術(shù)的出現(xiàn)第一次從底層支持推送,而無需開發(fā)人員采用變通方法實現(xiàn)推送,大大提高了推送效率,降低了資源消耗。然而,目前這一技術(shù)存在的不足在于其需要瀏覽器內(nèi)核的支持,目前現(xiàn)代瀏覽器如Firefox 4、Chrome 4、IE10及以上版本等,都已經(jīng)支持WebSocket標(biāo)準(zhǔn)。但對于IE9及以下版本,無法直接支持WebSocket。
2.3 SignalR
以上介紹了幾種常見的推送實現(xiàn)方式,由于不同方式需要的支撐環(huán)境不同,需要瀏覽器、插件、運行平臺等方面的支持,這給開發(fā)人員提出了較高要求。目前,已經(jīng)出現(xiàn)幾種較好的解決方案,屏蔽了以上這些技術(shù)細(xì)節(jié),讓開發(fā)人員專注于業(yè)務(wù)領(lǐng)域的開發(fā),大大簡化了推送功能的實現(xiàn),SignalR就是其中較有代表性的方案之一。
SignalR是一個微軟.NET框架庫和jQuery插件,是集成的客戶端與服務(wù)器庫,基于瀏覽器的客戶端和基于ASP.NET的服務(wù)器組件可以借助它進(jìn)行雙向多步對話。該對話不受限制地進(jìn)行單個無狀態(tài)請求/響應(yīng)數(shù)據(jù)交換;它將繼續(xù)直到明確關(guān)閉。對話通過永久連接進(jìn)行,允許客戶端向服務(wù)器發(fā)送多個消息,并允許服務(wù)器做出相應(yīng)答復(fù),值得注意的是,還允許服務(wù)器向客戶端發(fā)送異步消息。它是基于現(xiàn)有技術(shù)的復(fù)合體。SignalR屏蔽了底層具體的推送實現(xiàn)細(xì)節(jié),一般情況下,它會使用Comet進(jìn)行推送,如果瀏覽器支持WebSocket,它就采用WebSocket方式。
3 結(jié)論
本文通過對推送技術(shù)的工作原理和實現(xiàn)方式進(jìn)行介紹,了解了推送技術(shù)的主要工作機制及適用領(lǐng)域,其高實時性和資源占用小等優(yōu)點,非常適合煤礦Web實時監(jiān)測系統(tǒng)。雖然目前在這一領(lǐng)域尚未廣泛應(yīng)用推送技術(shù),但可以預(yù)知,這將是實現(xiàn)下一代煤礦實時監(jiān)測系統(tǒng)的重要技術(shù)之一。
參考文獻(xiàn):
[1]國家安全生產(chǎn)監(jiān)督管理總局.關(guān)于修改〈煤礦安全規(guī)程〉第六十八條和第一百五十八條的決定[Z].2006,10(25).
[2]孫清國.Web應(yīng)用中的服務(wù)器推送技術(shù)研究綜述[J].計算機系統(tǒng)應(yīng)用,2008,11.
[3]尹西杰.基于智能Agent的Web信息自動推送系統(tǒng)[J].網(wǎng)絡(luò)通訊與安全,2012,8(16).
作者簡介:柳波(1982.9-),男,北京人,碩士,助理工程師,現(xiàn)主要從事煤炭行業(yè)安全信息化軟件的研發(fā)工作。
作者單位:煤炭科學(xué)研究總院北京分院,北京 100083
基金項目:“十二五”國家科技支撐計劃課題:礦井動目標(biāo)監(jiān)測技術(shù)及在用設(shè)備智能管控技術(shù)平臺與裝備(基于物聯(lián)網(wǎng)安全管控技術(shù))。課題編號:2013BAK06B05。