黑馬注：最近，微信朋友圈最紅的不再是各種雞湯，而是一款呆萌的小游戲“圍住神經貓”。不少網友表示，朋友圈已被這只貓刷屏!“圍住神經貓”是南京一家公司的游戲團隊開發的，開發只用了一天半。現在這股神經貓的傳播熱潮已經席卷整個網絡。這里i黑馬為各位帶來神經貓背后的故事：

“圍住神經貓”火了。這是一款HTML5游戲，在微信獲得了瘋狂轉發，短短兩天時間里，即獲得一千萬次的點擊和500萬次的用戶數。百度指數兩日間便完成了0到75804的跨越，而出現食品安全危機的麥當勞在7月21日百度指數峰值時竟比圍住神經貓的百度指數少了兩萬多。

一個設計再加一個程序員，開發時長共計1.5天，這就是一款百萬用戶數游戲的全部成本。這款游戲是南京泥巴怪公司開發的，做“圍住神經貓”也是想為了自己的“在線兒童社區”聚攏些用戶而已。

“圍住神經貓”采用HTML5游戲方式開發，最大的好處就是“即點即玩”，為游戲微信傳播提供了一個“便捷”的前提，而非像通常意義上的 App 那樣，需要經過更多的步驟從應用商店下載。而開發成本低的原因也恰恰是因為使用了HTML5游戲引擎——開發者只負責考慮創意問題，重復機械的底層游戲編程模塊則由游戲引擎負責。

于是，作為“圍住神經貓”的游戲引擎，HTML5游戲引擎公司Egret也趕上了這波現象級神經貓熱潮，一日之間網站瀏覽量翻了十倍。

對于Egret創始人兼CEO陳書藝來講，“圍住神經貓”游戲網頁最下面那一行“Egret framwork”則意味著，他在短短半天的時間里，兩部手機——一部iPhone5s，一部三星Galaxy，毫無電力——他的電話已經被打爆了，嵌入廣告邀請、采訪邀請、投資意向紛至沓來。采訪當時，陳書藝的手機還一直在充電狀態。馬鑒是Egret的聯合創始人，負責管理引擎產品和技術團隊。他則頻繁遭遇QQ群“開小窗”，其中甚至有公司公關，希望馬鑒可以幫忙制作HTML5游戲，嵌入公司的一些軟推廣。《財經天下》周刊采訪時曾被打斷兩次，一次是一個投資人的來訪，而另一次是陳書藝短暫離開時，自己的手機刺耳地在馬鑒背后發出響聲。

Egret是一家HTML5游戲引擎公司，這個定義對普通讀者來說可能有些模糊，按照定義來講，HTML5是一系列制作網頁互動效果的技術的集合，而簡單來講，它的優勢在于能夠在移動端為Flash之所不能為的動畫效果。而游戲引擎，則可以用陳書藝過去的經歷來解釋：2005年，從英國回國一年的他加入Discuz!公司。泡過論壇的人都會在網頁的最下方看到：powered by Discuz!字樣——它是十年間最流行的網絡論壇框架。Discuz!的用戶可以在不需要任何編程的基礎上，通過簡單的設置和安裝，在互聯網上搭建論壇服務。直到今天，還有很多論壇在使用這套框架。而Egret想要做得就是HTML5游戲界的Discuz!。

游戲引擎行業也不乏國際品牌，Cocos的2D引擎，Unity的3D引擎已是聲名在外。而Egret的市場策略與它們的不同之處在于，前兩者的使命是使游戲開發者在開發App游戲上更加便捷，而Egret則側重于開發HTML5游戲。這種策略挺中國特色的，畢竟目前微信和微博的病毒傳播成為一種主流，游戲開發者可能更愿意先通過易于傳播的移動網頁，以“即點即用”的方式推廣自己的游戲，期望用戶產生依賴之后，會去應用商店下載。而且，游戲引擎業又不像時尚界、投資界、媒體界一樣有“外來和尚光環效應”，畢竟不是每個程序員都是海歸，而Egret提供的中文文檔使游戲開發門檻更低。

Egret的產品被“圍住神經貓”的開發者選為自己的游戲引擎還有一個原因，Egret公司聯合創始人馬鑒此前十年都在Adobe負責Flash產品研發，連從Egret官網下載的程序后綴都是.air，以Adobe Air開發的程序才會帶有這一后綴。而神經貓的開發者此前曾一度開發過Flash游戲。當開發者看到Egret的界面，簡直震驚了，因為代碼邏輯與Flash開發別無二致，只要稍微替換一些代碼說明，即可上手。

給陳書藝打電話的人不乏希望“圍住神經貓”可以嵌入廣告。現象級產品可以賺快錢，但是現象級產品制造者的制造者，他們的商業模式卻不太清晰。在陳書藝看來，這不是現在急需解決的問題，他對《財經天下》周刊的記者說，“我們公司成立才半年多時間，目前就是希望能把產品做好。”

在整個游戲引擎行業主要有三種盈利模式，最簡單是賣軟件，比如Unity的3D引擎，代理商價格在一萬兩千元左右，這在中國基本不可行。然后就是為游戲開發者提供云服務等增值服務，以CocoonJS為代表。最后則是利用游戲引擎做一個游戲集合平臺，類似最早的Web端4399小游戲集合平臺，游戲引擎公司擔任因流量的任務，Turbulenz游戲引擎就發布了一個ga.me的網站。對于每一種商業模式陳書藝都不置可否。

他可能還沒想清楚做HTML5游戲引擎最終的盈利方向，但是他覺得，今年是他做HTML5搜索引擎最合適的契機，“這個項目讓我覺得特別興奮”，據他所說，他算是為此放棄了一份差點IPO的創業公司——奇矩互動。“我不是想賺多少錢，我是挺想做點……”他沒好意思把“做成一件大事”說出口，默默轉頭開始挪回因為需要拍攝雜志照片而挪動的茶幾。

簡單的來講，做HTML5游戲引擎，陳書藝就是想“占山頭”，先把這件事做了。在這個時間點上，他和馬鑒發現做HTML5游戲引擎的時機已經日趨成熟。首先是移動社交網絡的興起，游戲“即點即用”這個需求是存在的。其次是HTML5的規范標準日趨穩定，Google的Chrome、微軟的IE、蘋果的Safari逐漸愿意支持規范統一的的標準化。而移動硬件的進化已經逐漸能滿足需求運行游戲的需求，2010年，很多智能手機都沒有配置對Canvas的硬件加速，這使某些游戲開發者“有心無力”，而現在就連紅米Note都已經配備了8核處理器。

陳書藝總提到一個具體的年份，2010年。這一年是一個HTML5的里程碑，喬布斯在加利福尼亞州庫比蒂諾總部的內部大會上回答一位蘋果員工的提問，“沒有人愿意使用Flash，全球已經開始步入HTML5時代。”使得HTML5走入人們的視線中心，此后HTML5經過捧后殺——以一家名叫Moblyng的提供HTML5解決方案的公司的倒閉作為引爆點。“其實這件事也是這個公司自己的經營問題”，陳書藝說，接著他看了一眼被喬布斯視為HTML5的手刃對象Adobe的前員工馬鑒。

泥巴怪公司無疑是互聯網的幸運者，但是除了HTML5，其本身對一些細節的改造或多或少成為了它火爆的因素。“圍住神經貓”并非泥巴怪的首創游戲，此前中美日各國開發者均開發過類似游戲——格點圍住一只不斷移動的貓，就算獲勝。而把日本漫畫“全是貓”和圍貓游戲相結合，再加上不同級別勝利者的取名“擊敗了精神病院99%的精神病患者，獲得稱號精神病院長”、“擊敗了精神病院100%的精神病患者，獲得稱號：白天睡覺喵”迎合了互聯網亞文化的賤心理，再加上微信分享使人類“攀比心”作祟，使得“圍住神經貓”比其它“圍貓游戲”更有可能獲得人類的關注度，當然，最重要還是運氣好。

本文來自《財經天下周刊》的投稿

麗楓，鄭力新，王佳斌

（華僑大學 工學院，福建 泉州 362021）

摘要：隨著互聯網技術的不斷發展，Web技術在各個領域得到了不同程度的運用，人們對于Web應用的實時性提出了更高的要求，HTML5WebSocket協議因此得到了廣泛的關注。通過對基于HTTP的傳統Web實時通信方案進行分析，針對其中的不足與缺點，深入介紹了基于HTML5 WebSocket協議的實時通信機制以及相對于傳統方案的優勢，并通過使用Node.js的Express框架和HTML5 WebSocket協議的第三方應用程序編程接口Socket.io類庫實現了一個基于WebSocket協議的Web應用。經實驗表明，所描述的研究能成功地在客戶端和服務器端完成基于HTML5 WebSocket協議的實時通信過程并建立連接。

0引言

隨著互聯網技術的高速發展，人們對Web應用的實時性要求越來越高，傳統的Web實時通信方案已經無法滿足一些現實應用的需求。在長期的Web應用過程中該傳統方案逐漸露出資源浪費、實時性不高等問題，這些問題的出現對一些實時性要求較高的Web應用（如在線游戲、在線證券、設備監控等）造成了不好的用戶體驗。除此之外，這些不足還會制約Web實時通信的性能，對通信效率造成影響。面對這種情況，HTML5規范中定義了WebSocket協議來實現更好的用戶體驗和實時通信功能，并針對傳統的Web實時通信方案在實際運用中產生的資源浪費問題進行改善，提高通信效率。

目前，WebSocket協議的實現主要分為客戶端和服務器端兩部分。對于其客戶端而言，許多的主流瀏覽器(包括個人電腦和移動終端)如谷歌、火狐、IE等都在不同的版本上支持WebSocket客戶端應用程序編程接口。而對于其服務器端而言，也有許多常見的應用服務器如WebSphere、WebLogic、Tomcat等在不同的版本上支持WebSocket服務器端應用程序編程接口。綜上所述，本文從傳統的Web實時通信方案出發，針對其在Web應用中所體現的不足與缺點，深入研究WebSocket協議在Web實時通信方面的原理與優勢，并根據該協議的通信機制進行實現。

1傳統的Web實時通信方案

1.1輪詢

在早期的Web應用中，所采用的Web實時通信方案是輪詢。在使用輪詢時，客戶端需要頻繁地向服務器端發送HTTP請求來保持客戶端和服務器端的同步以便不斷地刷新客戶端所要呈現的信息。在這個過程中，客戶端無法確定合適的時間間隔向服務器端發送HTTP請求。若間隔的時間太短，客戶端頻繁的請求將會給服務器端造成巨大的壓力；若間隔的時間太長，就無法滿足客戶端和服務器端實時通信的要求。由于客戶端在頻繁地發送請求時服務器端的數據可能還未進行更新，導致服務器端返回的大部分應答包中的數據域為空，因而產生了很多無謂的網絡傳輸，浪費了大量的帶寬資源和其他網絡資源。對于圖1客戶端與服務器端的交互圖每次的HTTP請求而言，過長的HTTP頭信息也會占用不必要的帶寬資源。因此，這是一種缺乏靈活性又低效的Web實時通信方案。其中客戶端和服務器端的交互過程如圖1(a)所示。

1.2Comet技術

目前，Comet技術［1］的實現方式包括基于異步JavaScript和可擴展標記語言(Asynchronous JavaScript and Extensible Markup Language,AJAX)的長輪詢方式和基于Iframe的流方式。這兩種方式針對輪詢都做出了較大的改進。

1.2.1基于AJAX的長輪詢方式

基于AJAX的長輪詢方式［2］通過采用AJAX技術讓客戶端向服務器端發送HTTP請求，進而與服務器端建立連接，且該連接會在服務器端保持一段時間。若服務器端檢測到有新數據產生，那么它會將這些數據通過連接發送至客戶端，然后關閉連接；若服務器端在連接存在期間都沒有產生新的數據發送至客戶端，那么它將會向客戶端發送一個超時信息，然后關閉連接。無論服務器端的數據是否還在更新，在連接關閉之后，客戶端都需要重新向服務器端發送HTTP請求來建立連接。其中客戶端和服務器端的交互過程如圖1(b)所示。

雖然這種方式能夠對客戶端的部分頁面進行更新，減少服務器端發送的數據量，降低客戶端請求的頻率，減少無效的網絡傳輸，但當服務器端更新數據的速度較快時，基于AJAX的長輪詢方式將變成普通的輪詢，不僅會降低其性能，而且還會對服務器端造成較大的處理壓力。除此之外，為了保持HTTP連接長時間處于打開狀態，服務器端也需要消耗一定的服務器資源。因此，使用基于AJAX的長輪詢方式會產生資源浪費的問題。

1.2.2基于Iframe的流方式

基于Iframe的流方式［3］通過客戶端頁面上內嵌的一個Iframe標簽向服務器端發送HTTP請求，服務器端在響應該請求后與客戶端建立一條長連接。連接建立后，服務器端通過不斷地更新該連接的狀態以保持其不過期。當服務器端檢測到有新數據產生時，它會將新數據通過該連接發送給客戶端；當客戶端和服務器端之間的通信出現問題導致連接出現錯誤或者關閉時，客戶端會立即發出連接請求與服務器端重新建立連接，否則該連接會一直持續，不會關閉。其中客戶端和服務器端的交互過程如圖1(c)所示。

雖然這種方式有利于減少客戶端的請求次數，減輕客戶端和服務器端之間的網絡負擔，避免因頻繁的建立連接和關閉連接所帶來的資源浪費，但由于基于Iframe的流方式在連接過程中始終只維持一個長連接，因此客戶端頁面會一直處于加載過程中而無法顯示頁面加載完成，從而影響用戶體驗。且當有多個客戶端同時向服務器端發送HTTP請求時，由于服務器端長期只維持一個連接，因此會導致服務器端在這種高并發狀態下的處理能力降低，造成大量的服務器資源和其他網絡資源被消耗。

由于基于AJAX的長輪詢方式和基于Iframe的流方式在通信過程中一直采用HTTP作為通信協議，因此每次的HTTP請求和應答所攜帶的完整的HTTP頭信息不僅增加了實時更新信息時的數據傳輸量，還造成帶寬資源的浪費。此外，為了維持和協調通信過程中HTTP連接隨時處于可用狀態，服務器端也需要消耗資源。對于HTTP連接的建立和關閉過程而言，服務器端新產生的數據有可能會因為無法及時發送到客戶端而導致客戶端的數據丟失。由于這兩種方式對Web應用中的實時信息和非實時信息的請求/響應方式都未發生改變，因此，當實時信息的請求較為頻繁時，可能會造成服務器端較大的處理壓力，從而影響非實時信息的呈現。其中基于HTTP的Web實時應用模型如圖2所示。

2傳統的Web實時通信方案

WebSocket協議［45］是HTML5規范中的一種新的通信協議，是能夠在客戶端和服務器端進行異步通信的一種方法。它支持客戶端與服務器端通過全雙工通信的方式實現實時通信，本質上是一個基于傳輸控制協議的協議。因此，WebSocket連接的建立過程與傳輸控制協議連接的建立過程有些相似，客戶端和服務器端需要通過“握手”來建立WebSocket連接。

首先由客戶端向服務器端發送一個HTTP請求，該請求不同于一般的HTTP請求，它包含了一些附加的HTTP頭信息，其中一條信息“Upgrade:WebSocket”表明這是一個申請將當前HTTP協議升級為WebSocket協議的HTTP請求。若服務器端收到該請求后能正確解讀其HTTP頭信息，那么它會返回一個基于HTTP的應答報文給客戶端，此時連接建立成功［6］，之后，客戶端和服務器端便可以通過該連接主動向對方發送或者接收數據，直到其中一方主動關閉該連接。其中客戶端和服務器端的交互過程如圖3所示。

通過WebSocket協議，客戶端和服務器端之間只要做一個“握手”的動作就可以建立一條雙向通信的通道。這不僅讓服務器端可以主動與客戶端互發信息，而且還避免了因客戶端頻繁請求而造成的網絡資源浪費、實時通信效率低、服務器處理壓力大等問題［7］。由于WebSocket連接采用WebSocket協議作為通信協議，因此在傳輸過程中數據幀的頭部信息所占的字節數將大大降低，從而有效地減小了通信過程中傳輸的數據量和網絡負載，節約了帶寬資源。在基于WebSocket協議的實時通信方案中，Web應用中的實時部分和非實時部分被加以區分。客戶端使用WebSocket協議獲取實時內容，使用HTTP協議獲取非實時內容。而服務器端則采用兩種不同的模塊來處理實時的WebSocket請求和非實時的HTTP請求，其應用模型如圖4所示。

通過上述模型可以看出，該實時通信方案使服務器端的結構更加明確，不僅讓WebSocket協議和HTTP協議各司其職、互不干擾，而且還降低了系統的耦合性，在最大程度上發揮了兩個模塊的功能。此外，由于采用以傳輸控制協議為基礎的WebSocket協議來處理實時服務，因此可以保證傳輸數據過程中的穩定性和及時性，在較大程度上提高了實時通信的性能。相對于傳統方案來說，該方案不僅減小了對服務器資源的浪費，也減輕了服務器端的處理壓力。

3基于WebSocket的Web實時通信應用實例

本文采用基于Node.js［8］的Express框架和Socket.io類庫來實現基于WebSocket的Web實時通信應用。其中，Node.js是一個JavaScript運行平臺，可用于構建響應速度快、容易擴展的網絡程序。但由于Node.js中只提供了大量的低端功能，因此文中將使用Express框架進行Web實時通信應用的開發。Express是一個能夠在Node.js中使用的 Web應用程序開發框架，它提供的一系列強大的特性，能夠讓Web應用程序的開發變得更加方便、快速。

Socket.io是一個開源、跨平臺且支持客戶端和服務器端進行實時雙向通信的WebSocket庫［9-10］。它包括客戶端的JavaScript庫和服務器端的Node.js模塊。它能夠根據不同的客戶端自動在一些實時通信機制中選擇合適的一個來實現Web實時應用。當使用支持HTML5技術的瀏覽器客戶端進行實時通信時，Socket.io會選譯效率最高、消耗服務器資源最少的WebSocket協議來實現實時通信，并在瀏覽器客戶端發生變化時自動選擇其他方式進行通信。因此，Socket.io能有效解決跨平臺的實時通信問題。

3.1在線聊天室的設計

在線聊天室的設計分為客戶端與服務器端兩個部分，其實時通信過程如圖5所示。

3.2在線聊天室的實現

在線聊天室的實現也分為客戶端和服務器端兩個部分。其中客戶端通過使用HTML5、層疊樣式表以及JavaScript來實現用戶名的驗證功能、消息顯示功能和數據傳送功能。服務器端通過JavaScript來實現與客戶端的實時通信功能、廣播功能以及在線用戶列表的管理功能。圖8用戶登錄成功時客戶端與服務器端的交互圖3.2.1客戶端的實現過程

當有新的客戶端用戶加入聊天室時，已在聊天室的用戶將會接收到新用戶加入聊天室的消息且用戶列表會被即時更新以顯示新加入的用戶名。新用戶所在頁面也會被更新以顯示所有在線用戶。當有客戶端用戶在聊天室發送聊天消息時，該消息會被即時廣播給所有在線用戶。當有客戶端用戶退出聊天室時，其他在線用戶將會接收到該用戶退出聊天室的消息且用戶列表會被實時更新以移除下線用戶的用戶名。下線用戶所在的頁面也會進行相應的調整。若用戶在聊天過程中直接退出聊天室頁面，則所有在線用戶都會收到該用戶退出聊天室的消息。客戶端的具體實現流程如圖6所示。

3.2.2服務器端的實現過程

當有多個客戶端用戶存在時，服務器端的主要功能包括管理所有在線用戶的用戶列表以及廣播它們之間的聊天消息。服務器端的具體實現流程如圖7所示。

3.2.3客戶端和服務器端的交互過程

本文主要針對用戶成功登錄進聊天室的情況進行介紹。當用戶成功登錄在線聊天室時，客戶端和服務器端通過觸發事件進行實時交互，其具體交互過程如圖8所示。

4結論

傳統的Web實時通信方案是在長期的應用實踐中發展出來的，其中比較常用的是基于AJAX的長輪詢方式和基于Iframe的流方式。但由于這兩種方案都是采用基于HTTP的通信方式，因此當Web實時應用采用這兩種方案時會產生難以解決的問題。而WebSocket協議的出現適時地提供了一種新的Web實時通信方案，它能夠更加快捷有效地構建出簡單高效的Web實時應用。因此，本文通過分析傳統的Web實時通信方案的不足之處，不僅從理論層面分析了基于WebSocket的Web實時通信方案的優勢，而且還通過使用HTML5、層疊樣式表和JavaScript編寫了具體的應用實例簡單的實現了該方案。隨著WebSocket協議的不斷發展，基于WebSocket的Web實時通信方案將會被廣泛應用。

參考文獻

［1］ 蔡驥然，曹海傳.B/S架構下基于OPC與Comet技術的實時監控系統［J］.計算機應用，2012,32(z2):214216.

［2］ 文愛平，文德民.基于IE瀏覽器的Ajax Comet架構［J］.電腦知識與技術，2010,6(17):46464648.

［3］ 張家愛，孫飛.Comet技術在Web開發中的研究與應用［J］.煤炭技術，2011,30(12):153154.

［4］ 陸晨，馮向陽,蘇厚勤.HTML5 WebSocket握手協議的研究與實現［J］.計算機應用與軟件，2015,32(1):128131,178.

［5］ 李代立，陳榕.WebSocket在Web實時通信領域的研究［J］.電腦知識與技術，2010,6(28):79237925,7935.

［6］ 周東仿，孟寧.基于WebSocket的網絡設備自發現機制［J］.計算機工程與設計，2013,34(2):392396,438.

［7］ 溫照松，易仁偉，姚寒冰.基于WebSocket的實時Web應用解決方案［J］.電腦知識與技術,2012,8(16):38263828.

［8］ 王金龍，宋斌，丁銳.Node.js:一種新的Web應用構建技術［J］.現代電子技術，2015,38(6):7073.

［9］ 李廣文.基于Socket.io的互動教學即時反饋系統的設計與實現［J］.中國現代教育裝備，2012(18):1012.

［10］ 黃經贏.基于Socket.io+Node.js+Redis構建高效即時通訊系統［J］.現代計算機(專業版)，2014(19):6264,69.