WebSocket 雙向即時通訊 - 初探

Web 已經走向 Application 的概念，其中即時性(real-time)這個特點扮演很重要的角色

早期 Web service 要做到即時通訊不外乎兩種

• Polling
  每n秒問一次 server，n 越小即時性越好，但相對 server loading 就越大
• Long polling
  需要 Server support，延遲 response，確切來說是需要的時候再 response

但這兩種方式都需要額外的 overhead

• HTTP 協定限制，一個 request 配一個 response，然後結束 connection，每次重新連線都需要 tcp 3-way handshake
• Request 只能從 client 主動發出，若要做到 server push，client 得先建立一條連線讓 server 需要時 send back
• 每次連線都要帶上 HTTP header，對頻寬也是一種浪費
• Connection 斷掉再建立有個空窗期

而 WebSocket 正是改善這些缺點

• 全雙工通訊(full-duplex communication)，連線一旦建立，server/client 隨時都可以發送資料給對方
• 除了第一次 handshake 外，過程中傳送資料的 header 很小
• 避免對同一個網站建立多條 connection

WebSocket 的 implementation

• Server library
  WebSocket - Server Side - Wikipedia, the free encyclopedia 幾乎各語言都有對應的 library 可以用
• Frontend client library
  Socket.io

WebSocket 對各種瀏覽器版本的支援度

• Can I use Web Sockets?
• Comparison of WebSocket implementations - Wikipedia, the free encyclopedia

WebSocket Protocol/Packet 分析

• RFC-6455
• WebSocket - WebSocket protocol handshake - Wikipedia, the free encyclopedia
• websocket新版协议分析＋python实现 - 小小的世界
• WebSocket协议分析 - 功夫Panda - 博客园

其實在 HTTP 1.0 與 1.1 也有 persistent connection 的實作

• HTTP 1.0 persistent connection：又稱 HTTP keep-alive 或 HTTP connection reuse，可以在同個 connection 下發送多次 request/response 
• HTTP 1.1 提出了 pipelining：允許一次發送多個 request 給 server，但 server response 時也必需按照順序

但這機制卻沒有被廣泛的應用？是因為早期的 web server 存在 C10K problem 嗎？還是 server 支援度的問題？加上 proxy 與 browser 有限制 client 到 web server 的 current connection 只能建立兩條，避免浪費 server 資源

詳細可以參考 HTTP 連線管理 | ihower { blogging }

實現網頁即時傳訊 Web instant message (IM)

最近想弄一個Web IM，在web上做即時聊天有一定的困難，因為受限在http協定原生的特性：

client:request -> server:response -> 結束
傳輸一定要從client開始，而且一來一往誰也不能多，想做到server push有一定的難度，不像tcp raw socket自由度那麼高。


早期的聊天室會使用polling的方式定期 refresh (post back) 來更新頁面，同步的時間取決於refresh的頻率，但server loading也隨著頻率上升而增加。後來有了Ajax，頁面更新不用再一直閃爍，但還是有原本耗資源的問題。

近期較廣泛被使用的是Ajax搭配long polling，做到省資源又可以與server同步的效果。
Polling就是client定期的發request，long polling就是定期發request，但server不馬上response，而是等到有需要的時候再response (例如有人傳新訊息給你時)，通常browser timeout都蠻長的，所以這段等待的期間相對polling就很省資源。如果還不是很懂，可以參考這一篇：Browser 與 Server 持續同步的作法介紹。

要做到long polling這個效果需要server support，server必需要把request object先keep住，等到有需要的時候再抓出來回應給client。用Tornado來舉例，就是RequestHandler被call時，先把Handler存起來，等到時機到了再執行finish() function。


下面列出幾種IM的 model，我想實現的是最後一種 ── 跨平台而且server可以隨著loading scale-up。