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

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

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

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

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