WebSocket
Posted by Bruce Tsai
03/03/2016
WebSocket
HTML5 的 WebSocket 是一種建立在單一 TCP 連線上的全雙工（full-duplex）通訊管道，可以讓網頁應用程式與伺服器之間做即時性、雙向的資料傳遞。
筆者的考量
- 在 Port / Session / Server 上的限制與風險？
- 惡意行為的風險（如大量資料傳輸）？
- Cross domain 的風險？
- 客戶端的傳輸數據如何監控
SignalR
SignalR 是基於 .Net 平台上能快速建置出支援即時通訊(real-time)的應用程式的一種 Solution 。資料傳遞時是以 JSON 為基礎，所以也可以相容大多的瀏覽器而且也非常輕量化，然而如果是較老的瀏覽器（IE6、IE7）就無法直接支援，可能還是得透過外部的 JSON Parser 來處理。
輪詢（Polling）
輪詢（polling）的做法是讓瀏覽器每隔一段時間就自動送出一個 HTTP 請求給伺服器，獲取最新的網頁資料，這個做法是最老舊的方式，如果你已經事先知道伺服器上資料更新的頻率或時間，那麼就可以使用這樣的方式讓瀏覽器上的資料同步更新，但是在許多即時性的網頁應用程式上，情況並不是這樣，你通常不會知道伺服器上的資料何時會更新，在伺服器沒有新資料時，瀏覽器如果也送出 HTTP 請求，就會造成浪費網路資源的狀況。
長時間輪詢（Long-Polling）
長時間輪詢（long-polling）則是讓伺服器在接收到瀏覽器所送出 HTTP 請求後，伺服器會等待一段時間，若在這段時間裡面伺服器有新的資料，它就會把最新的資料傳回給瀏覽器，如果等待的時間到了之後也沒有新資料的話，就會送一個回應給瀏覽器，告知瀏覽器資料沒有更新。
雖然長時間輪詢可以減少產生原本輪詢（polling）造成網路頻寬浪費的狀況，但是如果在資料更新很頻繁的狀況下，長時間輪詢並不會比傳統的輪詢有效率，而且有時候資料量很大時，會造成連續的 polls 不斷產生，反而會更糟糕。
串流（Streaming）
串流（streaming）是讓伺服器在接收到瀏覽器所送出 HTTP 請求後，立即產生一個回應瀏覽器的連線，並且讓這個連線持續一段時間不要中斷，而伺服器在這段時間內如果有新的資料，就可以透過這個連線將資料馬上傳送給瀏覽器。
這個方式雖然不錯，但是由於他是建立在 HTTP 協定上的一種傳輸機制，所以有可能會因為代理伺服器（proxy）或防火牆（firewall）將其中的資料存放在緩衝區中，造成資料回應上的延遲，因此許多使用串流的 Comet 實作會在偵測到有代理伺服器的狀況時，改用長時間輪詢的方式處理。另外透過 TLS（SSL）的連線也可以避免緩衝區的問題，但是這個方式除了設定麻煩之外，也會造成伺服器額外的負擔。
FB 的 Polling
參考資料：