摘要：WebSocket 是一種協(xié)議，基于 TCP 協(xié)議；HTTP 也是一種協(xié)議，基于 TCP 協(xié)議。連接要保持還是關(guān)閉是由你服務(wù)器應(yīng)用來控制的。WebSocket 協(xié)議和 HTTP 協(xié)議是兩種不同的東西，它們扯上關(guān)系是只是因為：客戶端開始建立 WebSocket 連接時要發(fā)送一個 header 標(biāo)記了 Upgrade 的 HTTP 請求，表示請求協(xié)議升級。所以服務(wù)器端做出響應(yīng)的簡便方法是，直接在現(xiàn)有的

WebSocket 是一種協(xié)議，基于 TCP 協(xié)議；HTTP 也是一種協(xié)議，基于 TCP 協(xié)議。

連接要保持還是關(guān)閉是由你服務(wù)器應(yīng)用來控制的。

WebSocket 協(xié)議和 HTTP 協(xié)議是兩種不同的東西，它們扯上關(guān)系是只是因為：
客戶端開始建立 WebSocket 連接時要發(fā)送一個 header 標(biāo)記了 Upgrade 的 HTTP 請求，表示請求協(xié)議升級。
所以服務(wù)器端做出響應(yīng)的簡便方法是，直接在現(xiàn)有的 HTTP 服務(wù)器軟件和現(xiàn)有的端口上實現(xiàn) WebSocket 協(xié)議，重用現(xiàn)有代碼（比如解析和認(rèn)證這個 HTTP 請求。如果在 TCP 協(xié)議上實現(xiàn)，這兩個功能就要重新實現(xiàn)），然后再回一個狀態(tài)碼為 101 的 HTTP 響應(yīng)完成握手，再往后發(fā)送數(shù)據(jù)時就沒 HTTP 的事了。

互聯(lián)網(wǎng)一共才十幾年歷史，而 WebSocket 從提議變成推薦標(biāo)準(zhǔn)就需要幾年，因為中間要經(jīng)過大量的安全驗證和實驗。
Web 1 的時代人們訪問 Web 頁面是即停即走。Web 2 之后單個頁面停留時間越來越長，頁面功能越來越豐富——這時有了 RIA 的概念，改變了客戶端的編程模型——更甚至許多實時應(yīng)用根本不用離開頁面，比如聊天、游戲應(yīng)用。
客戶端瀏覽器決定了客戶端編程語言的能擁有的功能，以前如何做那些交互性很高的應(yīng)用呢？
一些技術(shù)有 XHR，iframe, 實時性要求非常高的就只能用第三方插件，比如 Flash 或 Silverlight。
但 XHR 和 iframe 存在一些根本避免不了問題：1）每次交互就需要兩個 HTTP 請求 2）即使單個 HTTP 請求也要傳送很多字節(jié)（header 笨重）3）客戶端不知道消息何時能夠到達(dá)，只能輪詢。服務(wù)器肯定會表示壓力很大！
插件則需要額外安裝，還有安全性問題和移動設(shè)備根本不能被支持的問題。
有了需要之后才有了解決方案—— WebSocket 就是這種靈丹妙藥，看看主要特性：實時交互、服務(wù)器能夠主動推送內(nèi)容、只需要建立一次連接、快速（延遲小，每條消息可以小到兩個字節(jié)）、開發(fā)者友好（接口簡單，并是熟悉的事件模型）等等。
所以，HTML 4 選擇權(quán)很小，是否要支持 WebSocket 依據(jù)需求和環(huán)境而定；而選擇 HTML 5 的話，有了 socket 通信和圖形編程的能力，能夠開發(fā)出什么精彩應(yīng)用只取決于你的想象力。