WebSocket - 新一代網路傳輸技術WebSocket簡介

日期：
在Client-Server的傳輸架構中，雙向溝通是必要的，過去網頁透過許多種方式與Server溝通來達到雙向溝通的目的，最常見的方式是使用Comet機制，讓瀏覽器每隔一段時間對Server發出HTTP Request來確認Server是否有資料回傳，此種方式會造成許多問題：

(1)伺服器需要處理許多不同Client的TCP連線，這些連線包含了接收Client端資料與傳送資料至Client端的2條連線，因此對Server的負擔極大。
(2)由於Client不斷發出HTTP(Hyper Text Transfer Protocol) Request給Server確認是否有資料回傳，而HTTP Request Header占了大量的Bytes，傳送時不僅占了大量網路頻寬，對Server，資源的消耗量也會變大。
(3)對Client端而言，也需要維持與Server的連線資訊來判斷Server回傳的資料並進行動作。

為了解決上述的問題，IETF定義了WebSocket協定，透過單一條雙向溝通的TCP連線克服了長久以來的困境。

首先，我們先來了解在WebSocket出現之前，普遍使用的傳輸技術Comet的概念，在與WebSocket比較看出彼此的差異。

Comet

在WebSocket尚未問世前，Comet是最常用來解決網頁Client-Server雙向溝通的方法，Comet主要有兩種實作方式：
(1)Long Polling：Long Polling原理是瀏覽器發出一個Request，而Server讓這個Request持續開啟一段時間，若在這時間間隔內Server有資料就會回傳給Client，如果沒有Server則會關上Request。但是，當傳送的訊息相當龐大時，可能會造成傳送不完全，使得控制失靈。
(2)Streaming：Streaming原理是Server會與Client建立起一條持續的連線，為了使連線不中斷，Server每隔一段時間會發送Response給Client，確保連線不中斷，在Streaming中使用隱藏的iframe tag，Server將資料傳入iframe，交給iframe內的javascript執行頁面的更新。使用Streaming有一些缺點，因為使用Streaming傳送時，訊息會被包裝起來，因此到防火牆前會被放入Buffer中，導致傳送時間延遲。

看完了Comet的原理後，大致了解了Comet雖然解決了雙向溝通的問題，但瓶頸在於它在控制連線生命週期上花了太多Effort，導致效能會較差，而WebSocket解決了這個問題，讓效能不會卡在連線生命週期，增強了資料傳輸的效率，接著我們來看WebSocket如何解決了Comet的問題。

WebSocket

WebSocket是於2011年12月，由IETF(Internet Engineering Task Force)制定的協定(RFC-6455)，W3C在HTML5規範內制定了WebSocket API的標準。由於WebSocket是建立於HTTP原有的架構之上，基本上還是以HTTP作為傳輸層，因此和一般HTTP一樣使用80與443port(https)，Proxy與Firewall沿用HTTP。WebSocket大幅改善了Comet的缺點，不僅將連線數量減少為一條，當Server端有資料更新時，會自動傳送給Client端，進行即時更新的動作，傳送的HTTP Request Header也僅僅只有2bytes長度大小(如圖 1)，所以WebSocket非常適合應用於一些即時系統上，例如:遊戲、證券交易系統、多人共同編輯等。

圖1.WebSocket訊息格式

建立WebSocket連線時，Client會發送HTTP Request給Server(如圖 2)，並要求Server將HTTP Protocol更新為WebSocket Protocol(如圖 3)，待Server更新完後即完成了HandShake，此時Server與Client就建立了一條雙向的WebSocket連線，資料就可以在兩者之間即時的傳輸。

圖2.Http Request for Upgrade Http Protocol to WebSocket Protocol

圖3.Protocol Switch HandShake

如同一般的Socket一樣，要使用WebSocket需要有一個Server來建立連線與處理資料的傳遞，Client可以有多個來自瀏覽器、應用程式、手機App…等。

WebSocket Client API

W3C在HTML5標準之下制定了瀏覽器與WebSocket Server溝通的WebSocket API，其API主有有四個，分別為onopen、onmessage、onerror、onclose。onopen為當瀏覽器與WebSocket Server完成HandShake後，會觸發onopen的API；onmessage為當瀏覽器從WebSocket Server端接收到資料後，會觸發onmessage的API；onerror為在整個WebSocket連線的過程中，無論是傳送資料錯誤或連線中斷…等狀況發生時，onerror會被觸發；onclose為與當WebSocket Server中斷連線後，onclose會被觸發，另外，當onerror發生後，瀏覽器接著會觸發onclose，將連線中斷。綜合上述API說明來看，整個WebSocket API觸發的流程如下圖：

圖4.WebSocket API Life Cycle

下表為各瀏覽器支援WebSocket的情形：
IE
Chrome
Safari
Opera
Firefox
Android Browser
BlackBerry Browser
支援
10.0
14.0~29.0
6.0
12.1~16.0
6.0~23.0
X
7.0~10.0
部分支援
X
4.0~13.0
5.0~5.1
11.0~12.0
4.0~5.0
X
X
不支援
5.0~9.0
X
3.1~4.0
9.0~10.6
2.0~3.6
2.1~4.2
X

總結

WebSocket大幅的改善了瀏覽器與Server溝通的效能，打破了互動式網頁的瓶頸，Google、Facebook相繼使用WebSocket來使得他們的社群網頁反應更加即時。雖然WebSocket掀起了網頁技術新革命，但WebSocket屬於HTML5其中之一的標準，因此相容於WebSocket的瀏覽器數量不多，使得WebSocket在目前市場上不太普遍。世界知名網頁服務公司Google尤其推崇WebSocket，在WebSocket還沒正式制定完整的標準時，他們在Chrome 4.0就開始就部分支援WebSocket，且為了推廣自家瀏覽器Chrome，Google製作了使用WebSocket的遊戲(Super Sync Sports，如圖 7)來吸引使用者，這個遊戲有趣的地方在於他利用WebSocket讓每個玩家透過手機連接上Server來同時競賽，相信玩過這款遊戲的使用者能夠體會到WebSocket的強大。

圖5.Google Chrome WebSocket Game (Super Sync Sports)



參考來源：

留言

張貼留言