早期 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 對各種瀏覽器版本的支援度
- RFC-6455
- WebSocket - WebSocket protocol handshake - Wikipedia, the free encyclopedia
- websocket新版协议分析+python实现 - 小小的世界
- WebSocket协议分析 - 功夫Panda - 博客园
其實在 HTTP 1.0 與 1.1 也有 persistent connection 的實作
詳細可以參考 HTTP 連線管理 | ihower { blogging }
- 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 }
沒有留言:
張貼留言