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