你可以把 WebSocket 看成是 HTTP 協(xié)議為了支持長連接所打的一個大補丁，它和 HTTP 有一些共性，是為了解決 HTTP 本身無法解決的某些問題而做出的一個改良設計。在以前 HTTP 協(xié)議中所謂的 keep-alive connection 是指在一次 TCP 連接中完成多個 HTTP 請求，但是對每個請求仍然要單獨發(fā) header；所謂的 polling 是指從客戶端（一般就是瀏覽器）不斷主動的向服務器發(fā) HTTP 請求查詢是否有新數據。這兩種模式有一個共同的缺點，就是除了真正的數據部分外，服務器和客戶端還要大量交換 HTTP header，信息交換效率很低。它們建立的“長連接”都是偽.長連接，只不過好處是不需要對現有的 HTTP server 和瀏覽器架構做修改就能實現。

WebSocket 解決的第一個問題是，通過第一個 HTTP request 建立了 TCP 連接之后，之后的交換數據都不需要再發(fā) HTTP request了，使得這個長連接變成了一個真.長連接。但是不需要發(fā)送 HTTP header就能交換數據顯然和原有的 HTTP 協(xié)議是有區(qū)別的，所以它需要對服務器和客戶端都進行升級才能實現。在此基礎上 WebSocket 還是一個雙通道的連接，在同一個 TCP 連接上既可以發(fā)也可以收信息。此外還有 multiplexing 功能，幾個不同的 URI 可以復用同一個 WebSocket 連接。這些都是原來的 HTTP 不能做到的。

另外說一點技術細節(jié)，因為看到有人提問 WebSocket 可能進入某種半死不活的狀態(tài)。這實際上也是原有網絡世界的一些缺陷性設計。上面所說的 WebSocket 真.長連接雖然解決了服務器和客戶端兩邊的問題，但坑爹的是網絡應用除了服務器和客戶端之外，另一個巨大的存在是中間的網絡鏈路。一個 HTTP/WebSocket 連接往往要經過無數的路由，防火墻。你以為你的數據是在一個“連接”中發(fā)送的，實際上它要跨越千山萬水，經過無數次轉發(fā)，過濾，才能最終抵達終點。在這過程中，中間節(jié)點的處理方法很可能會讓你意想不到。

比如說，這些坑爹的中間節(jié)點可能會認為一份連接在一段時間內沒有數據發(fā)送就等于失效，它們會自作主張的切斷這些連接。在這種情況下，不論服務器還是客戶端都不會收到任何提示，它們只會一廂情愿的以為彼此間的紅線還在，徒勞地一邊又一邊地發(fā)送抵達不了彼岸的信息。而計算機網絡協(xié)議棧的實現中又會有一層套一層的緩存，除非填滿這些緩存，你的程序根本不會發(fā)現任何錯誤。這樣，本來一個美好的 WebSocket 長連接，就可能在毫不知情的情況下進入了半死不活狀態(tài)。

而解決方案，WebSocket 的設計者們也早已想過。就是讓服務器和客戶端能夠發(fā)送 Ping/Pong Frame（RFC 6455 - The WebSocket Protocol）。這種 Frame 是一種特殊的數據包，它只包含一些元數據而不需要真正的 Data Payload，可以在不影響 Application 的情況下維持住中間網絡的連接狀態(tài)。