CTO問：WebSocket 是啥玩意？
點擊下方??“Python之禪”關注公眾號
?和 10萬+技術人一起精進
今天這篇文章沒有代碼，看起來不會很累
瀏覽器客戶端與服務器通信時，傳統的HTTP連接是這樣的
HTTP1.0
每發(fā)一個請求都要先建立一個TCP連接，客戶端收到響應后連接斷開，發(fā)起第二次請求時重新建立新的TCP連接。這就好比你和女朋友打電話，撥通電話后，你說一句，女朋友回復完后雙方就自動掛機了。你要講第二句，不好意思，你得重新撥號，如此往復，最后你可能瘋掉了。
但早期HTTP1.0就是這樣，打開一個網頁如果有100個請求，那就要建立100次連接，這種方式對資源是一種嚴重的浪費。
HTTP1.1
到了HTTP1.1 有了一定改善，出了一個叫長連接的模型（Keepalive），也叫持久連接。發(fā)送請求前，先建立TCP連接，不過，連接后，你可以多次發(fā)送請求和接受響應了，效率大幅提升。
但是，HTTP 請求是按順序發(fā)出的，第二次請求必須在第一個響應達到后才能發(fā)起。就好比，你和女朋友打電話時，撥通后，你說一句，等她回復后才能接著說第二句，如果她還沒回你，那對不起，你只能等。這樣處理也是有好處的，我明確知道你回復我的是哪句話。
HTTP1.1已經比HTTP1.0先進了很多，雖然HTTP1.1 還有個管道連接（Pipelining），就是建立連接后，可以不用等上一個請求的響應結果就可以發(fā)送第二個請求。
但這個功能在瀏覽器中默認是關閉的。主要原因有：
一些代理服務器不能正確的處理 HTTP Pipelining。 Head-of-line Blocking 連接頭阻塞：在建立起一個 TCP 連接之后，假設客戶端在這個連接連續(xù)向服務器發(fā)送了幾個請求。按照標準，服務器應該按照收到請求的順序返回結果，假設服務器在處理首個請求時花費了大量時間，那么后面所有的請求都需要等著首個請求結束才能響應。
不過，這些問題在HTTP2.0中得到了解決，關于2.0 這個可以后續(xù)再展開講
傳統的HTTP服務都是由客服端向服務器主動發(fā)起請求獲取結果，客戶端不主動就永遠拿不到結果，所以對實時性要求比較的場景，我們一般用輪詢的方式，每隔一段時間去問一下服務器，
服務器有新的數據了嗎？
沒有
過了幾秒鐘，又問
服務器有新的數據了嗎？
有了，我給你
就這樣如此往復的執(zhí)行。
那對即時性要求更高的場景，有沒有可能服務器主動告知客戶端，只要有數據更新了就通知客戶端，而不是讓客戶端去詢問呢，答案就是WebSocket
WebSocket
WebSocket是一種在單個 TCP 連接上進行全雙工通訊的協議。WebSocket 是獨立的、創(chuàng)建在 TCP 上的協議，和 HTTP 的唯一關聯是使用 HTTP 協議的101狀態(tài)碼進行協議切換，使用的 TCP 端口是80，可以用于繞過大多數防火墻的限制。WebSocket 使得客戶端和服務器之間的數據交換變得更加簡單，允許服務端直接向客戶端推送數據而不需要客戶端進行請求，在 WebSocket API 中，瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接，并允許數據進行雙向傳送。
WebSocket常出現在線聊天室、在線客服系統、評論系統、WebIM等業(yè)務場景中。
WebSocket 作為一種規(guī)范，在實際開發(fā)過程中，我們只要按照規(guī)范來構建服務端和客戶端就可以基于WebSocket實現Web上的即時聊天功能。好在，現在并不需要我們從零去自己實現WebSocket協議，Socket.IO 就是一個開源的WebSocket庫。
好了，今天先寫到這里，下期基于 websocket 實戰(zhàn)一把。