WebSocket的原理是什么,針對這個問題,這篇文章詳細介紹了相對應(yīng)的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
讓客戶滿意是我們工作的目標,不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶,將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴,公司提供的服務(wù)項目有:域名注冊、虛擬空間、營銷軟件、網(wǎng)站建設(shè)、奉賢網(wǎng)站維護、網(wǎng)站推廣。
概念和原理
WebSocket協(xié)議和HTTP協(xié)議一樣,都是在ISO七層模型的最頂層——應(yīng)用層。WebSocket允許服務(wù)器端主動向客戶端推送數(shù)據(jù)。在WebSocket協(xié)議中,客戶端瀏覽器和服務(wù)器只需要完成一次握手就可以創(chuàng)建持久性的連接,并在瀏覽器和服務(wù)器之間進行雙向的數(shù)據(jù)傳輸——全雙工通訊。
HTTP和WebSocket連接生命周期對比圖:
WebSocket協(xié)議是通過HTTP協(xié)議來建立傳輸層TCP連接的
web Socket請求頭字段:
通過Connection:upgrade和upgrade:websocket字段把http協(xié)議升級成websocket協(xié)議,所以在請求頭中的Connection和Upgrade表示客戶端發(fā)起的是WebSocket請求;
同時請求頭中還有Sec-WebSocket-Version字段表示客戶端所使用的協(xié)議版本號,服務(wù)器會確認是否支持該版本號,如果支持了,服務(wù)端的響應(yīng)就沒有這個字段,如果不支持,響應(yīng)的字段中就會有這個字段,對應(yīng)的是服務(wù)端支持的版本號;
Sec-WebSocket-Key是一個Base64編碼值,由瀏覽器隨機生成,用于升級request,服務(wù)端拿到這個編碼值會把http協(xié)議升級成websocket協(xié)議
Sec-WebSocket-Extensions表示客戶端想表達的協(xié)議級的擴展;
Web Socket響應(yīng)頭字段:
HTTP/1.1 101 Switching procotols是一個切換協(xié)議,WebSocket協(xié)議通過HTTP協(xié)議來建立傳輸層的TCP連接;
Connection和Upgrade,和請求字段一樣;
Sec-WebSocket-Accept: 表示服務(wù)器接受了客戶端的請求,由Sec-Websocket-Key計算得來的,**計算方式:**將請求頭中的Sec-WebSocket-Key和258EAFA5-E941-47DA-95CA-C5AB0DC85B11連接,然后進行SHA-1取哈希值,會得到一個20位的結(jié)果,然后再把這個結(jié)果用base64編碼轉(zhuǎn)換;
優(yōu)點和缺點
優(yōu)點:
支持雙向通訊,實時性更強;
數(shù)據(jù)格式更輕量,性能開銷小,通訊高效;因為http協(xié)議每次都要攜帶完整的頭部,但是websocket在連接建立之后,從服務(wù)端到客戶端只需要攜帶2-10個字節(jié)的頭部,而從客戶端到服務(wù)端也只需要2-10個字節(jié)的頭部以及4個字節(jié)的掩碼;
支持擴展,用戶可以擴展協(xié)議或者實現(xiàn)自定義好的子協(xié)議(比如支持自定義壓縮算法等),美劇硅谷中的pied piper的壓縮算法應(yīng)用于直播技術(shù)
缺點:
少部分瀏覽器可能不支持,瀏覽器支持的程度與方式有區(qū)別;
長連接對后端業(yè)務(wù)的代碼穩(wěn)定性要求更高,后端推送功能相對復(fù)雜;
成熟的 HTTP生態(tài)下有大量的組件可以復(fù)用,WebSocket較少;
應(yīng)用場景:
即時聊天通訊,網(wǎng)站消息通知,
在線協(xié)同編輯,如騰訊文檔;
多玩家在線游戲,視頻彈幕,股票基金實時報價;
應(yīng)用
業(yè)務(wù)場景:實現(xiàn)網(wǎng)站私信功能
方式一、使用AJAX輪詢
分析這種方式:可以設(shè)置請求時間間隔特別短(如200ms),可以讓用戶基本感受不到延時,能夠完成功能,但是這樣做對網(wǎng)絡(luò)、服務(wù)器的浪費都特別大,1. 大量的HTTP請求響應(yīng),每次都要通過TCP三次握手建立連接然后再返回;2. 即便是沒有消息,也要進行發(fā)送請求,后端Web服務(wù)器和WSGI服務(wù)器都要進行處理,如果用戶量一大,這種方式的缺陷會非常明顯;
方式二、使用WebSocket建立連接
分析這種方式:只需要建立一次連接即可,并且前端可以向后端推送,后端也可以向前端推送,并且是有消息了才會推送,沒消息就不會推送,請求響應(yīng)的頭字節(jié)還小,優(yōu)勢非常明顯;
在django中應(yīng)用這種技術(shù)
需要考慮的問題:
如何區(qū)別路由HTTP請求和WebSocket請求
如何兼容django的認證系統(tǒng)(因為私信肯定是要登錄的,所以需要認證)
如果接收和推送WebSocket消息
如何通過ORM保存和獲取數(shù)據(jù)
解決辦法:使用django-channels或則dwebsocket
django-channels
是什么:django-channels是一個位django提供異步擴展的庫,通常主要用來提供WebSocket支持和后臺任務(wù),因為django是一個同步框架。
django同步框架圖:一個請求來了,django處理過程中用戶是需要等待的,重點是nginx會超時;
所以,為了避免nginx超時,或者用戶等待體驗差,我們可以使用celery異步任務(wù)調(diào)度,把耗時的任務(wù)異步處理,讓django先給nginx和用戶返回一個結(jié)果。
等任務(wù)處理完了,django并不能主動把結(jié)果推送出去,這時候就需要使用channels了。
channels原理:
請求流程圖:
從左向右,請求來了之后會按照類型分別訪問不同的方向。
channels的整體架構(gòu)
這個架構(gòu)圖中總共分成了三層:1. Interface Server是負責(zé)對協(xié)議進行解析,將不同協(xié)議分發(fā)到不同的Channel;2. Channel Layer是第二層,有了第1層的解析,請求可以分為http請求和websocket請求,這時候就要在Channel Layer這個頻道層不同的隊列中,可以是一個FIFO隊列中進行緩沖排隊,通常使用redis,不同的頻道有不同的接收者監(jiān)聽; 3.Consumer消費者層,用來接收和處理頻道層的消息;
channels文件和配置含義
asgi.py 是介于網(wǎng)絡(luò)協(xié)議服務(wù)和Python應(yīng)用之間的標準接口,能夠處理多種通用協(xié)議類型,包括HTTP、HTTP2和WebSocket;如果沒有websocket的網(wǎng)絡(luò)協(xié)議項目部署只需要使用nginx+uWSGI+django就可以了,因為uWSGI服務(wù)器能夠識別wsgi.py;但是如果有websocket的網(wǎng)絡(luò)協(xié)議通訊項目,在部署的時候則就要使用到符合asgi接口標準的服務(wù),例如daphne;
channel_layers 需要在settings.py中配置,類似一個通道, 發(fā)送者(producer)在一端發(fā)送消息,消費者(consumer)在另一端監(jiān)聽;
routings.py 相當于django中的urls.py,把http路由寫在urls.py中,websocket請求寫在routings.py中,與總的urls.py同級;
consumers.py channels中的消費者,相當于django中的views.py,創(chuàng)建在每個app下;
WSGI和ASGI的區(qū)別
WSGI:Python Web Server Gateway Interface,為Python語言定義的Web服務(wù)器或框架之間的一種簡單而通用的接口;
ASGI:Asynchronous Server Gateway Interface, 異步網(wǎng)關(guān)服務(wù)接口,一個介于網(wǎng)絡(luò)協(xié)議服務(wù)和Python應(yīng)用直接的接口,能夠處理多種通用的協(xié)議類型,如HTTP、HTTP2和WebSocket;
區(qū)別:WSGI是基于HTTP協(xié)議模式的,不支持WebSocket,而ASGI就是為了支持Python常用的WSGI所不支持的新的協(xié)議標準,即ASGI是WSGI的擴展,而且能夠通過asyncio異步運行;ASGI還可以支持chat protocols, loT protocols物聯(lián)網(wǎng)協(xié)議等等…
關(guān)于WebSocket的原理是什么問題的解答就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。