包文祥 胡廣朋

（江蘇科技大學(xué)計(jì)算機(jī)學(xué)院 鎮(zhèn)江 212000）

1 引言

近幾年，隨著人們對(duì)信息實(shí)時(shí)性的需求不斷提升，實(shí)時(shí)Web技術(shù)越來越受到互聯(lián)網(wǎng)組織機(jī)構(gòu)的重視。網(wǎng)頁的實(shí)時(shí)通信是建立在互聯(lián)網(wǎng)基礎(chǔ)之上的一種通訊方式，隨著JavaScript發(fā)展和流行，基于瀏覽器的B/S 架構(gòu)的應(yīng)用交互性越來越強(qiáng)，大有替代C/S 架構(gòu)應(yīng)用的趨勢(shì)。HTTP 作為瀏覽器和服務(wù)器之間通信的協(xié)議，它的局限性開始逐漸暴露出來。HTTP 的請(qǐng)求/響應(yīng)模型都是通過響應(yīng)瀏覽器的請(qǐng)求進(jìn)而發(fā)送數(shù)據(jù)給客戶端，然而客戶端并不知道來源于服務(wù)器的數(shù)據(jù)何時(shí)發(fā)生改變，這樣不能確保數(shù)據(jù)的實(shí)時(shí)性，瀏覽器每一次給服務(wù)器發(fā)出響應(yīng)指令時(shí)都要帶上一段HTTP 頭和一些相關(guān)的請(qǐng)求信息，這樣會(huì)造成實(shí)現(xiàn)復(fù)雜、資源浪費(fèi)、實(shí)時(shí)性不高等問題。因此關(guān)于HTML5 的WebSocket 協(xié)議進(jìn)入了開發(fā)者的視野，它可以為實(shí)現(xiàn)真正意義上的Web實(shí)時(shí)通信提供可能性。本文將分析傳統(tǒng)的實(shí)時(shí)通信技術(shù)及以WebSocket 和一種安全加密算法實(shí)現(xiàn)Web實(shí)時(shí)應(yīng)用，設(shè)計(jì)出一種更加符合Web實(shí)時(shí)需求的通信應(yīng)用。

2 傳統(tǒng)的Web實(shí)時(shí)通信

實(shí)時(shí)Web應(yīng)用，是指客戶端和服務(wù)器端保持?jǐn)?shù)據(jù)在時(shí)間上的一致性的Web應(yīng)用，即客戶端會(huì)隨著服務(wù)器端的數(shù)據(jù)變化而立即反映到客戶端上。傳統(tǒng)的請(qǐng)求/響應(yīng)是無法實(shí)現(xiàn)實(shí)時(shí)通信的功能，開發(fā)者使用現(xiàn)有的技術(shù)和手段來達(dá)到一種實(shí)時(shí)通信的目的，目前傳統(tǒng)的實(shí)時(shí)Web應(yīng)用技術(shù)如圖1。

圖1 傳統(tǒng)的實(shí)時(shí)Web應(yīng)用技術(shù)

2.1 輪詢技術(shù)

輪詢技術(shù)在使用時(shí)，客戶端需要以固定的頻率向服務(wù)器端發(fā)送HTTP 請(qǐng)求來保持客戶端和服務(wù)器端的實(shí)時(shí)性，這樣就可以不斷刷新客戶端的頁面進(jìn)來展示數(shù)據(jù)改變的信息［1］。在輪詢過程中，客戶端無法確定滿足實(shí)時(shí)需求的請(qǐng)求頻率大小。若請(qǐng)求頻率過大，客戶端頻繁的請(qǐng)求將會(huì)給造成網(wǎng)絡(luò)負(fù)擔(dān)和服務(wù)器負(fù)載；若請(qǐng)求頻率過小，就會(huì)造成某些重要的實(shí)時(shí)信息不能即時(shí)反映到客戶端上從而造成數(shù)據(jù)的延遲和丟失。通常每次客戶端在發(fā)起請(qǐng)求的時(shí)候會(huì)傳輸HTTP 的請(qǐng)求頭，如果請(qǐng)求的固定頻率不能控制得很好的情況下，將會(huì)造成很多的網(wǎng)絡(luò)資源消耗和噪聲，浪費(fèi)了大量的帶寬資源。輪詢技術(shù)的客戶端和服務(wù)器端交互圖如圖2（a）所示。

2.2 瀏覽器插件技術(shù)

在采用基于瀏覽器插件的技術(shù)方案［2］實(shí)現(xiàn)的實(shí)時(shí)Web 應(yīng)用中，在HTML 頁面中內(nèi)嵌入一個(gè)使用了 XMLSocket 類的 Flash 程序。JavaScript 通過調(diào)用此Flash 程序提供的套接口接口與服務(wù)器端的套接口［3］進(jìn)行通信。JavaScript 在收到服務(wù)器端以XML 格式傳送的信息后可以很容易地控制HTML 頁面的內(nèi)容顯示?；跒g覽器插件（flash）內(nèi)部有自己的Socket 實(shí)現(xiàn)完成數(shù)據(jù)交換，再通過JavaS-cript 調(diào)用，從而達(dá)到實(shí)時(shí)傳輸目的。此方式比輪詢更高效，多數(shù)的企業(yè)客服都是采用這種方案，但是也存在需要安裝flash 插件以及移動(dòng)端手機(jī)瀏覽器不支持等問題。

2.3 基于HTTP長(zhǎng)連接技術(shù)

HTTP 每次請(qǐng)求都會(huì)經(jīng)過客戶端請(qǐng)求、連接通道打開、服務(wù)器端響應(yīng)、連接通道關(guān)閉四步，因此每次HTTP 請(qǐng)求響應(yīng)之后連接通道將會(huì)立即關(guān)閉。HTTP長(zhǎng)連接則通過一些特殊手段使連接在一段時(shí)間內(nèi)保持打開狀態(tài)［4］?；贖TTP長(zhǎng)連接技術(shù)有兩種技術(shù)實(shí)現(xiàn)方式:基于Ajax 的長(zhǎng)輪詢方式和基于Iframe的流方式［5］。

2.3.1 基于Ajax的長(zhǎng)輪詢

在基于Ajax長(zhǎng)輪詢的方式中，當(dāng)客戶端發(fā)起請(qǐng)求時(shí)，服務(wù)器會(huì)檢查當(dāng)前是否有新信息需要返回給客戶端，如果服務(wù)器沒有信息要返回的時(shí)候進(jìn)入阻塞等待狀態(tài)。一旦服務(wù)器查詢到新信息需要返回客戶端，Ajax 使用回調(diào)函數(shù)處理這條信息，同時(shí)迅速再次發(fā)送一個(gè)請(qǐng)求等待服務(wù)器處理。客戶端和服務(wù)器端交互時(shí)序圖如圖2（b）所示。雖然基于Ajax的長(zhǎng)輪詢雖然仍然使用了輪詢的思想，但較之普通輪詢減少了普通輪詢服務(wù)器多次盲目返回空數(shù)據(jù)，提高了信息實(shí)時(shí)更新的可靠性，一定程度降低了對(duì)于各種資源的浪費(fèi)［6］，但是當(dāng)服務(wù)器端的信息更新頻繁時(shí)，每次長(zhǎng)連接維持的時(shí)間較短，而客戶端在一次連接斷開后會(huì)立即再次連接，從而導(dǎo)致該技術(shù)退化為簡(jiǎn)單的輪詢。此外基于Ajax 的長(zhǎng)輪詢還存在服務(wù)器端處理資源消耗多、實(shí)時(shí)信息延遲較大、消耗的網(wǎng)絡(luò)流量大、流量的有效利用率低的缺點(diǎn)［7］。

圖2 傳統(tǒng)的實(shí)時(shí)通信客戶端和服務(wù)器端交互時(shí)序圖

2.3.2 基于Iframe的流方式

通過在客戶端頁面中設(shè)置一個(gè)隱藏的iframe窗口，html設(shè)定定時(shí)器修改iframe的src屬性設(shè)為對(duì)服務(wù)器端發(fā)出一個(gè)長(zhǎng)連接的請(qǐng)求的 URL［8～9］。當(dāng)該頁面被打開時(shí)，通過iframe 可以發(fā)起一個(gè)長(zhǎng)連接請(qǐng)求，進(jìn)而與服務(wù)器建立長(zhǎng)連接，服務(wù)器向iframe 傳輸數(shù)據(jù)（通常是HTML，里面含有插入信息的javascript），來實(shí)時(shí)更新頁面［10］。服務(wù)器端接到這個(gè)請(qǐng)求后作出回應(yīng)并不斷更新連接狀態(tài)以保證客戶端和服務(wù)器端的連接不過期。客戶端和服務(wù)器端交互時(shí)序圖如圖2（c）所示。并且在這種方式下客戶端和服務(wù)器端保持長(zhǎng)連接容易造成資源浪費(fèi)［11］。

3 基于WebSocket 的實(shí)時(shí)安全Web通信方案

隨著HTML5 標(biāo)準(zhǔn)規(guī)范最終制定完成，Web-Socket 協(xié)議是基于HTML5 提供的一種在單個(gè)TCP連接上進(jìn)行全雙工通訊的協(xié)議，該協(xié)議本質(zhì)上為通信雙方提供一個(gè)基于TCP連接的雙向通道，所以能夠高效的在雙向通道中實(shí)時(shí)互相發(fā)送信息［12］。首先由客戶端向服務(wù)器端發(fā)送一個(gè)HTTP 請(qǐng)求，即WebSocket 連接的起始于一個(gè)HTTP 請(qǐng)求，該請(qǐng)求頭中會(huì)包含“Upgrade:WebSocket”表明瀏覽器端請(qǐng)求將會(huì)通過 HTTP 協(xié)議升級(jí)到 WebSocket 協(xié)議［13］。服務(wù)器端收到握手請(qǐng)求后解析其HTTP 請(qǐng)求頭信息，若匹配正確，就接受本次握手連接，并給出相應(yīng)的響應(yīng)信息“Sec-WebSocket-Accept:加密后的key”，此時(shí)連接建立成功升級(jí)為WebSocket協(xié)議，客戶端和服務(wù)器端便可通過此連接實(shí)現(xiàn)全雙工通信。其中基于WebSocket 協(xié)議服務(wù)器和客戶端交互時(shí)序圖如圖3 所示。

圖3 基于WebSocket協(xié)議服務(wù)器和客戶端交互時(shí)序圖

信息數(shù)據(jù)交換通常需要通信信道上進(jìn)行傳輸，Web 服務(wù)器和Web 瀏覽器之間的信息交換也是通過數(shù)據(jù)包的網(wǎng)絡(luò)傳輸來實(shí)現(xiàn)，因此，Web 數(shù)據(jù)傳輸過程的安全性直接影響著Web 安全［14］。WebSocket通信屬于全雙工通信，其信息傳輸數(shù)據(jù)的安全性更加不容小視。在WebSocket實(shí)時(shí)通信中，可以利用序列密碼的特點(diǎn)，采用速度較快的FC4 算法對(duì)傳輸數(shù)據(jù)進(jìn)行加密，保證傳輸數(shù)據(jù)的安全性。RC4是 Ron Rivest 在1987 年為 RSA 公司設(shè)計(jì)的一種序列密碼，它是一個(gè)可變密鑰長(zhǎng)度、面向字節(jié)操作的序列密碼［15］。

設(shè) 明 文 流 為 M=m1m2…mn，密 鑰 流 為K=k1k2…kn（密鑰流由密鑰或種子密鑰通過密鑰流生成器得到），則:

加密:C=c1c2…cn，其中 ci=Eki(mi)(i=1,2,…n)解密:M=m1m2…mn，其中 mi=Dki(ci)(i=1,2,…n)

具體過程如圖4所示。

圖4 序列密碼流程

同步序列密碼為一個(gè)六元組（P，C，K，L，E，D）和函數(shù)g，并且滿足以下條件:

1）P 是由所有可能明文構(gòu)成的有限集。

2）C 是由所有可能密文構(gòu)成的有限集。

3）K 是由所有可能密鑰構(gòu)成的有限集。

4）L 是一個(gè)稱為密鑰流字母表的有限集。

5）g 是一個(gè)密鑰生成器。g 使用密鑰k 作為輸入，產(chǎn)生無限的密鑰流 k1k2…,ki?L ，i ≥1。

6）對(duì)任意的k ?L，都有一個(gè)加密規(guī)則ek?E和對(duì)應(yīng)的揭秘規(guī)則dk?D 。并且對(duì)每一明文x ? P ，ek:P → C 和 dk:C → P 是滿 足 dk(ek(x))=x的函數(shù)。

圖5 密鑰流生成器模型

典型的密鑰流生成器的模型如圖5所示。

同步序列密碼的加密過程可以用以下方程進(jìn)行描述:

其中，σ0是取決于密鑰k的初始態(tài)，f是下一個(gè)態(tài)函數(shù)，g是生成密鑰流的函數(shù)。

本文采用對(duì)數(shù)據(jù)流先使用AES 算法實(shí)現(xiàn)傳輸數(shù)據(jù)的加解密，再使用速率較高的序列密碼RC4算法對(duì)密文進(jìn)行加密，這樣既保證了傳輸過程中的數(shù)據(jù)保密性，又能保證數(shù)據(jù)加解密的速率。數(shù)據(jù)加密傳輸過程如下描述:

Server 端使用了AES 算法產(chǎn)生密鑰Key 之后，并通過安全傳輸手段發(fā)送到Client端；

Server 端使用密鑰Key 加密明文M，生成密文C；

密文C 通過序列密碼算法RC4加密，生成密文C1；

Server 端向 Client 端發(fā)送密文 C1，Client 端接收密文C1；

Client 端接收C1，使用RC4 解密算法解密密文C1，生成解密后的M1；

Client使用收到的密鑰Key 解密密文M1，生成解密后的明文M。

圖6是數(shù)據(jù)加密傳輸流程圖

圖6 數(shù)據(jù)加密傳輸流程圖

4 基于WebSocket 的Web 實(shí)時(shí)安全通信案例

本文將以Node.js 為出發(fā)點(diǎn)構(gòu)建Web 實(shí)時(shí)安全通信方案，Node.js［16］使用事件驅(qū)動(dòng)，非阻塞 I/O 模型而得以輕量和高效，并且可以十分快速、高效地構(gòu)建Web 實(shí)時(shí)應(yīng)用。Express 框架是一種基于Node.js 平臺(tái)的Web 應(yīng)用開發(fā)框架，提供了一系列強(qiáng)大特性可以快速地搭建一個(gè)具有完整功能的網(wǎng)站，并且Express提供豐富而又簡(jiǎn)便的HTTP工具及API 可以快速地完成通信模塊［17］。Socket.IO 是一個(gè)用于實(shí)時(shí)通信的Node.js 軟件包，它對(duì)跨瀏覽器構(gòu)建實(shí)時(shí)Web 應(yīng)用提供了完整的封裝。它首先會(huì)在客戶端瀏覽器支持WebSocket 協(xié)議的情況下使用升級(jí)為WebSocket 協(xié)議來實(shí)現(xiàn)實(shí)時(shí)通信，并且會(huì)根據(jù)客戶端環(huán)境的選擇和變化使用相應(yīng)的技術(shù)來滿足實(shí)時(shí)需求［18］。

Web 實(shí)時(shí)通信的實(shí)現(xiàn)可分成服務(wù)器端和客戶端兩個(gè)方面。服務(wù)器端用了Node.js 中的軟件包Socket.IO，從而更加高效地實(shí)現(xiàn)功能，并且使用Express 框架對(duì)后端部分的邏輯進(jìn)行處理，簡(jiǎn)化邏輯處理過程，使實(shí)現(xiàn)過程相對(duì)容易一些?？蛻舳耸褂肏TML5、CSS、JavaScript來實(shí)現(xiàn)驗(yàn)證用戶、發(fā)送消息的傳遞功能［19］。

1）服務(wù)器端的實(shí)現(xiàn)過程

服務(wù)器端主要用于廣播各個(gè)客戶端發(fā)送的信息，以及它們登錄上線，下線信息。服務(wù)器端的具體實(shí)現(xiàn)流程如圖7（a）所示。

2）客戶端的實(shí)現(xiàn)過程

當(dāng)一個(gè)用戶登錄成功以后，首先當(dāng)前用戶的用戶列表會(huì)展示所有在此聊天室的用戶名稱，其次在聊天室的其他用戶會(huì)接受到新用戶登錄的信息并且各個(gè)客戶端的用戶列表會(huì)增加當(dāng)前登錄用戶的登錄名稱。當(dāng)存在客戶端發(fā)送信息時(shí)，在聊天室下的其它客戶端會(huì)立即收到當(dāng)前客戶端發(fā)送的信息［20］。當(dāng)存在客戶端進(jìn)行下線操作時(shí)，在聊天室下的其他客戶端會(huì)立即收到當(dāng)前客戶端發(fā)送的信息下線的消息并且用戶列表刪除當(dāng)前退出的用戶名?？蛻舳说木唧w實(shí)現(xiàn)流程如圖7（b）所示。

圖7 實(shí)時(shí)通信前后臺(tái)流程圖

5 結(jié)語

本文以現(xiàn)有的幾種實(shí)時(shí)Web應(yīng)用技術(shù)為例，分析這幾種實(shí)時(shí)Web 應(yīng)用技術(shù)的工作原理及存在的問題。所以在此基礎(chǔ)上結(jié)合WebSocket 協(xié)議的優(yōu)勢(shì)及一種安全加密算法實(shí)現(xiàn)實(shí)時(shí)Web 應(yīng)用實(shí)現(xiàn)方案，目前一些版本較低的主流瀏覽器還不能對(duì)WebSocket 協(xié)議進(jìn)行支持，以及該協(xié)議具體規(guī)范在正式發(fā)布前還存在一定的安全性問題，這就使得新方案的實(shí)際企業(yè)級(jí)應(yīng)用上存在一定的風(fēng)險(xiǎn)。隨著WebSocket 技術(shù)的不斷更新和完善，這項(xiàng)技術(shù)能夠越來越廣泛地運(yùn)用到我們?nèi)粘Ｉ町?dāng)中。