HTML 5 Web Socket：下一次Web通訊革命揭幕

　　最近關於HTML 5 Web Socket的流言已經滿天飛，它通過Web上的一個單一Socket定義了一個全雙工系統通訊通道，HTML 5 Web Socket並不是普通HTTP通訊的增強版，它代表著一個巨大的進步，特別是針對即時的、事件驅動的Web應用程式。

　　Google的工程師Ian Hickson說“資料的位元組數急劇減少到2位元組，延遲從150毫秒減少到50毫秒，實際上，這兩個因素已經足以引起Google的興趣了”。通過在一個瀏覽器中類比全雙工系統串連，HTML 5 Web Socket對Web通訊帶來了顯著的改善。

　　讓我們與傳統的解決方案相比，看看HTML 5 Web Socket是如何減少不必要的網路流量和延遲的。

　　當前的Web通訊——頭疼的輪詢(Polling)

　　通常，當瀏覽器訪問一個網頁時，會向託管該網頁的Web伺服器發送一個HTTP請求，Web伺服器識別這一請求，並返迴響應。例如，股票價格，新聞報道，門票銷售，流量模式，醫療設備讀數等，在瀏覽器渲染頁面時，響應可能會到期，如果你想獲得最新的“即時”資訊，你可以不斷地手動重新整理頁面，但顯然這不是最好的辦法。

　　目前提供的即時Web程式主要是圍繞輪詢和其它伺服器端推送技術進行的，最著名的是Comnet，它延遲了HTTP響應的結束，基於Comnet的推送通常是使用JavaScript結合長輪詢(Long Polling)或流串連策略實現的。

　　使用輪詢時，瀏覽器定期發送HTTP請求，並立即收到響應，這種技術是交付即時資訊的第一次嘗試，顯然，如果知道訊息傳遞的時間間隔，這算是一個好辦法，因為你可以在伺服器上的資訊可用時同步用戶端請求，但即時資料往往是不可預測的，不可避免會產生一些不必要的請求，導致許多串連處於開啟狀態，有些不必關閉的串連卻被關閉了。

　　使用長輪詢時，瀏覽器向伺服器發送一個請求，伺服器在既定期限內保持請求處於開啟狀態，如果在此期間收到通知，向用戶端發送一個包含訊息的響應，如果在此期間沒有收到訊息，伺服器發送一個響應終止開啟的請求。最重要的是要理解，當你的資訊容量很高時，長輪詢與傳統的輪詢相比不提供任何效能改善。實際上，它可能更糟，因為長輪詢可能會失控進入一個死迴圈。

　　使用流時，瀏覽器發送一個完整的請求，但伺服器發送一個響應，並儲存開啟狀態，然後不斷更新使其一直保持開啟（或在一段時間內保持開啟），無論何時訊息準備好發送時，響應就更新，但伺服器不會發送一個結束的響應，因此串連就一直保持開啟狀態，後面發送的訊息就可以繼續使用這個串連。但流仍然是封裝在HTTP中的，阻擾了防火牆和Proxy 伺服器選擇緩衝區中的內容進行響應，因此訊息傳遞的時間就延長了。許多流式Comnet解決方案都轉向了長輪詢，另外，TLS（SSL）串連可以用來屏蔽來自緩衝區的響應，但在這種情況下，每個串連消耗的伺服器資源更多了。

　　最終，所有這些方法都提供了即時資料，包含HTTP請求和回應標頭，其中包含許多額外的，不必要的頭資料，最重要的是，全雙工系統串連需要的不僅僅是從伺服器到用戶端的下行串連。為了類比基於半雙工HTTP上的全雙工系統通訊，目前的許多解決方案都使用了兩個串連：一個下行串連，一個上行串連。維護和協調這兩個串連需要大量的系統開銷，並增加了複雜性。簡言之，HTTP不是為即時的，全雙工系統通訊設計的，1所示，它顯示了構建一個Comnet Web應用程式的複雜性，它從後端資料來源使用發布/訂閱模式基於半雙工HTTP顯示即時資料。

圖 1：Comnet程式的複雜性

　　當你試圖向外擴充那些Comet解決方案時，情況變得更糟糕，類比基於HTTP的雙向通訊容易出錯，即使終端使用者感覺某些東西看起來象是一個即時Web應用程式，但這種“即時”體驗的代價都是非常高昂的，需要付出更多的延遲等待時間，不必要的網路流量和對CPU效能的拖累。

　　HTML 5 Web Socket——拯救

　　HTML 5 Web Socket定義在HTML 5規範的通訊章節，它代表Web通訊的下一個演變：通過一個單一的Socket實現一個全雙工系統，雙向通訊的通道。HTML 5 Web Socket提供了一個真正的標準，你可以使用它構建可擴充的即時Web應用程式。此外，由於它提供了一個瀏覽器內建的通訊端，消除了Comet解決方案的許多問題，Web Socket顯著降低了系統開銷和複雜性。

　　為了建立一個Web Socket串連，用戶端和伺服器在初始握手期間要從HTTP協議升級到WebSocket協議，如下面的例子：

　　例1：WebSocket握手（瀏覽器請求，伺服器響應）

GET /text HTTP/1.1
Upgrade: WebSocket  
Connection: Upgrade  
Host: www.websocket.org  
...  
HTTP/1.1 101 WebSocket Protocol Handshake  
Upgrade: WebSocket  
Connection: Upgrade  
...

　　建立好串連後，WebSocket資料幀就可以在用戶端和伺服器之間以全雙工系統模式傳輸，在同一時間任何方向，可以全雙工系統發送文本和二進位幀，最小的幀只有2個位元組。在文本幀中，每一幀始於0x00直接，止於0xFF位元組，資料使用UTF-8編碼。WebSocket文本幀使用終結器，而二進位幀使用一個長度首碼。

　　注意：雖然WebSocket協議已經可以支援多種用戶端，但不能將未經處理資料傳遞給JavaScript，因為JavaScript不支援位元組類型，因此，如果用戶端是JavaScript，位元據會被忽略，但可以傳遞給支援位元組類型的用戶端。

　　Comet和HTML 5 Web Socket之間的對決

　　人們最關注的是HTML 5 Web Socket如何減少不必要的網路流量和延遲，我們比較一個輪詢應用程式和Web Socket應用程式就知道了。

　　對於輪詢的例子，我建立了一個簡單的Web應用程式，一個網頁使用傳統的發布/訂閱模式從RabbitMQ訊息代理請求即時的股票資料，它是通過輪詢一個託管在Web伺服器上的Java Servlet實現的，RabbitMQ訊息代理從一個虛構的，不斷更新價格的股票價格源接收資料，網頁串連並訂閱一個特定的股票頻道（訊息代理上的一個主題），使用XMLHttpRequest每秒更新一次進行輪詢。當收到更新時，執行一些計算，然後將股票資料顯示在圖2所示的表中。

圖 2：一個JavaScript股票行情應用程式

　　注意：後端的股票源每秒實際上產生了大量的股票價格更新，因此使用每秒一次輪詢的方式比使用長輪詢方式更好，長輪詢會產生許多連續的輪詢，輪詢會更有效地阻止傳入更新。

　　這一切看起來還不錯，但仔細觀察，你就會發現這種應用程式存在嚴重的問題，例如，使用Firefox的Firebug外掛程式（允許你調試網頁和監控頁面載入和指令碼執行時間），你可以看到每秒都有一個GET請求砸向伺服器。開啟Live HTTP Headers（另一個Firefox 外掛程式，顯示即時的HTTP訊息頭流量）揭示每個請求關聯的訊息頭開銷數量是相當驚人的。下面兩個例子顯示了一個請求和響應的HTTP訊息頭資料。

　　例2：HTTP要求標頭

GET /PollingStock//PollingStock HTTP/1.1  
Host: localhost:8080  
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-us  
Accept-Encoding: gzip,deflate  
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  
Keep-Alive: 300  
Connection: keep-alive  
Referer: http://www.example.com/PollingStock/  
Cookie: showInheritedConstant=false;
　　　　 showInheritedProtectedConstant=false;
　　　　 showInheritedProperty=false;
　　　　 showInheritedProtectedProperty=false;
　　　　 showInheritedMethod=false;
　　　　 showInheritedProtectedMethod=false;
　　　　 showInheritedEvent=false;
　　　　 showInheritedStyle=false;
　　　　 showInheritedEffect=false

　　例3：HTTP回應標頭

HTTP/1.x 200 OK  
X-Powered-By: Servlet/2.5  
Server: Sun Java System Application Server 9.1_02  
Content-Type: text/html;charset=UTF-8  
Content-Length: 21  
Date: Sat, 07 Nov 2009 00:32:46 GMT

　　HTTP請求和回應標頭資訊開銷總共包括871位元組，而且還不包括任何資料，當然，這隻是一個例子，你的訊息頭資料完全可能低於871位元組，但我也看到過訊息頭資料超過2000位元組的情況。在這個例子中，股票主題訊息資料大約只有20個字元。

　　當你把這樣的程式大規模部署給使用者時會怎麼樣？我們使用三個不同的用例觀察一下該輪詢應用程式關聯的HTTP請求和回應標頭資料需要的網路輸送量。

用例A：1000用戶端，每秒輪詢一次
網路輸送量（871x1000）=871000位元組=6968000位元/秒（6.6Mbps）

用例B：10000用戶端，每秒輪詢一次
網路輸送量（871x10000）=8710000位元組=69680000位元/秒（66Mbps）

用例C：100000用戶端，每秒輪詢一次
網路輸送量（871x100000）=87100000位元組=696800000位元/秒（665Mbps）

　　這是一個不必要的巨大的網路輸送量，這時我們可以使用HTML 5 Web Socket，我使用HTML 5 Web Socket重構了應用程式，給網頁添加了一個事件處理常式，同步監聽來自訊息代理的股票更新訊息。每個訊息都是一個Web Socket幀，開銷只有2個位元組（而不是871位元組），再來看看對網路輸送量的影響。

用例A：1000用戶端，每秒輪詢一次
網路輸送量（2x1000）=2000位元組=16000位元/秒（0.015Mbps）

用例B：10000用戶端，每秒輪詢一次
網路輸送量（2x10000）=20000位元組=160000位元/秒（0.153Mbps）

用例C：100000用戶端，每秒輪詢一次
網路輸送量（2x100000）=200000位元組=1600000位元/秒（1.526Mbps）

　　正如你在圖3中可以看到的，與輪詢解決方案相比，HTML 5 Web Socket減少了不必要的網路流量。

圖 3：比較輪詢和WebSocket應用程式之間的網路輸送量

　　延遲減少怎麼樣呢？看看圖4便知，圖中上半部分顯示了半雙工輪詢方案的延遲，這裡我們假設訊息從伺服器傳輸到瀏覽器需要50毫秒，輪詢方式引入許多額外的延遲，因為當響應完成時，一個新的請求已經發送到伺服器了，這個新請求又需要50毫秒，在此期間伺服器不能發送任何訊息給瀏覽器，導致額外的伺服器記憶體消耗。

　　圖4下半部分顯示了Web Socket方式產生的延遲，一旦串連升級到Web Socket，訊息的傳輸會更及時，從伺服器傳輸到瀏覽器仍然需要50毫秒，但Web Socket串連保持開啟，之後就再也不用向伺服器發送請求了。

圖 4：輪詢和Web Socket應用程式之間的延遲對比

　　HTML5 Web Socket和Kaazing WebSocket網關

　　目前，只有Google的Chrome瀏覽器原生支援HTML 5 Web Socket，但其它瀏覽器也將提供支援，若要解決這個限制，Kaazing Web Socket網關為所有舊瀏覽器（IE 5.5+，Firefox 1.5+，Safari 3.0+和Opera 9.5+）提供了一個完整的Web Socket模擬，因此你現在就可以使用HTML 5 Web Socket API。

　　Web Socket很了不起，但在你的瀏覽器中有一個全雙工系統通訊端串連後可以做什麼呢？為了充分利用HTML 5 Web Socket的全部功能，Kaazing為二進位通訊提供了一個ByteSocket庫，為諸如Stomp、AMQP、XMPP、IRC等協議提供了更進階的庫，它們都是建立在Web Socket之上的。

　　例如，如果你為Stomp或AMQP協議使用了一個更進階的庫，這時你可以直接與後端訊息代理如RabbitMQ進行通訊，通過直接連接服務，不再需要額外的應用程式服務邏輯將這些雙向，全雙工系統TCP後端協議轉換成非雙向，半雙工HTTP串連，因為瀏覽器本身就可以理解這些協議。

圖5 ：Kaazing Web Socket網關擴充基於TCP的訊息，並具有更好的效能

　　總結

　　HTML 5 Web Socket在即時Web應用擴充性方面朝前邁出了一大步，正如你在本文中所看到的，HTML 5 Web Socket可以提供5000：1或 – 根據HTTP訊息頭大小 – 1000：1的比例減少不必要的HTTP頭流量和3：1的比例減少通訊延遲，這不是一個漸進式的改進，而是一次革命性的飛躍。

　　Kaazing Web Socket網關讓HTML 5 Web Socket代碼能夠在所有瀏覽器中運行，同時提供額外的協議庫允許你充分利用HTML 5 Web Socket提供的全雙工系統通訊端串連功能，直接與後端服務進行通訊。