今天這篇文章沒有代碼，看起來不會很累

瀏覽器客戶端與服務器通信時，傳統的HTTP連接是這樣的

HTTP1.0

每發一個請求都要先建立一個TCP連接，客戶端收到響應后連接斷開，發起第二次請求時重新建立新的TCP連接。這就好比你和女朋友打電話，撥通電話后，你說一句，女朋友回復完后雙方就自動掛機了。你要講第二句，不好意思，你得重新撥號，如此往復，最后你可能瘋掉了。

但早期HTTP1.0就是這樣，打開一個網頁如果有100個請求，那就要建立100次連接，這種方式對資源是一種嚴重的浪費。

HTTP1.1

到了HTTP1.1 有了一定改善，出了一個叫長連接的模型（Keepalive），也叫持久連接。發送請求前，先建立TCP連接，不過，連接后，你可以多次發送請求和接受響應了，效率大幅提升。

但是，HTTP 請求是按順序發出的，第二次請求必須在第一個響應達到后才能發起。就好比，你和女朋友打電話時，撥通后，你說一句，等她回復后才能接著說第二句，如果她還沒回你，那對不起，你只能等。這樣處理也是有好處的，我明確知道你回復我的是哪句話。

HTTP1.1已經比HTTP1.0先進了很多，雖然HTTP1.1 還有個管道連接（Pipelining），就是建立連接后，可以不用等上一個請求的響應結果就可以發送第二個請求。

但這個功能在瀏覽器中默認是關閉的。主要原因有：

一些代理服務器不能正確的處理 HTTP Pipelining。

Head-of-line Blocking 連接頭阻塞：在建立起一個 TCP 連接之后，假設客戶端在這個連接連續向服務器發送了幾個請求。按照標準，服務器應該按照收到請求的順序返回結果，假設服務器在處理首個請求時花費了大量時間，那么后面所有的請求都需要等著首個請求結束才能響應。

不過，這些問題在HTTP2.0中得到了解決，關于2.0 這個可以后續再展開講

傳統的HTTP服務都是由客服端向服務器主動發起請求獲取結果，客戶端不主動就永遠拿不到結果，所以對實時性要求比較的場景，我們一般用輪詢的方式，每隔一段時間去問一下服務器，

服務器有新的數據了嗎？沒有過了幾秒鐘，又問服務器有新的數據了嗎？有了，我給你

就這樣如此往復的執行。

那對即時性要求更高的場景，有沒有可能服務器主動告知客戶端，只要有數據更新了就通知客戶端，而不是讓客戶端去詢問呢，答案就是WebSocket

WebSocket

WebSocket是一種在單個 TCP 連接上進行全雙工通訊的協議。WebSocket 是獨立的、創建在 TCP 上的協議，和 HTTP 的唯一關聯是使用 HTTP 協議的101狀態碼進行協議切換，使用的 TCP 端口是80，可以用于繞過大多數防火墻的限制。WebSocket 使得客戶端和服務器之間的數據交換變得更加簡單，允許服務端直接向客戶端推送數據而不需要客戶端進行請求，在 WebSocket API 中，瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接，并允許數據進行雙向傳送。

WebSocket常出現在線聊天室、在線客服系統、評論系統、WebIM等業務場景中。

WebSocket 作為一種規范，在實際開發過程中，我們只要按照規范來構建服務端和客戶端就可以基于WebSocket實現Web上的即時聊天功能。好在，現在并不需要我們從零去自己實現WebSocket協議，Socket.IO 就是一個開源的WebSocket庫。

好了，今天先寫到這里，下期基于 websocket 實戰一把。

各位伙伴們好，詹帥本帥搭建了一個個人博客和小程序，匯集各種干貨和資源，也方便大家閱讀，感興趣的小伙伴請移步小程序體驗一下哦！（歡迎提建議）

推薦閱讀

牛逼！Python常用數據類型的基本操作（長文系列第①篇）

牛逼！Python的判斷、循環和各種表達式（長文系列第②篇）

牛逼！Python函數和文件操作（長文系列第③篇）

牛逼！Python錯誤、異常和模塊（長文系列第④篇）

總結

以上是生活随笔為你收集整理的CTO问：WebSocket 是啥玩意？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。