[[428976]]

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

瀏覽器客戶端與服務器通信時，傳統(tǒng)的HTTP連接是這樣的。

HTTP1.0

每發(fā)一個請求都要先建立一個TCP連接，客戶端收到響應后連接斷開，發(fā)起第二次請求時重新建立新的TCP連接。這就好比你和女朋友打電話，撥通電話后，你說一句，女朋友回復完后雙方就自動掛機了。你要講第二句，不好意思，你得重新?lián)芴枺绱送鶑?，最后你可能瘋掉了?/p>

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

HTTP1.1

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

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

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

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

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

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

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

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

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

WebSocket

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

WebSocket常出現(xiàn)在線聊天室、在線客服系統(tǒng)、評論系統(tǒng)、WebIM等業(yè)務場景中。

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

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

本文轉(zhuǎn)載自微信公眾號「Python之禪」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系Python之禪公眾號。