做后端時(shí)間長(zhǎng)了基本都會(huì)撞上同一個(gè)需求頁(yè)面上的數(shù)據(jù)要實(shí)時(shí)刷新。我印象最深的是給一個(gè)監(jiān)控大屏做實(shí)時(shí)數(shù)據(jù)展示一開(kāi)始圖省事用HTTP輪詢前端每隔一秒打一次接口結(jié)果數(shù)據(jù)沒(méi)等來(lái)數(shù)據(jù)庫(kù)的慢查詢?nèi)罩鞠人⒘艘徽?。后?lái)?yè)Q成WebSocket延遲從秒級(jí)降到百毫秒級(jí)服務(wù)器壓力也明顯降了下來(lái)。這篇文章圍繞WebSocket協(xié)議展開(kāi)從網(wǎng)絡(luò)層面的握手原理到應(yīng)用層的心跳機(jī)制再到前后端聯(lián)調(diào)時(shí)最容易踩的坑把我實(shí)際項(xiàng)目里驗(yàn)證過(guò)的方案和測(cè)試數(shù)據(jù)都整理出來(lái)。不管你是后端同學(xué)要給前端推數(shù)據(jù)還是前端同學(xué)要接實(shí)時(shí)消息都能從里面找到可以直接落地的思路。1. 為什么選WebSocket先搞清楚HTTP輪詢有多痛1.1 HTTP請(qǐng)求-響應(yīng)模型與輪詢方案的問(wèn)題HTTP協(xié)議是個(gè)典型的“一問(wèn)一答”模型?？蛻舳税l(fā)請(qǐng)求服務(wù)器給響應(yīng)一次交互就結(jié)束了。連接關(guān)閉后服務(wù)器就沒(méi)法主動(dòng)往客戶端推送數(shù)據(jù)。當(dāng)年做股票行情、在線聊天、協(xié)作編輯這類能力強(qiáng)需求時(shí)大家都靠“輪詢”硬撐——前端啟動(dòng)一個(gè)定時(shí)器每隔幾秒主動(dòng)問(wèn)一次服務(wù)器“有新數(shù)據(jù)嗎”。輪詢方案聽(tīng)起來(lái)簡(jiǎn)單真正上了量之后問(wèn)題非常多。請(qǐng)求太頻繁大部分響應(yīng)都是“沒(méi)有新數(shù)據(jù)”白白浪費(fèi)帶寬和服務(wù)器資源。為了減小延遲就得縮短輪詢間隔間隔一短請(qǐng)求量指數(shù)級(jí)增長(zhǎng)數(shù)據(jù)庫(kù)和網(wǎng)關(guān)的壓力跟著上來(lái)。即便把間隔壓到500毫秒數(shù)據(jù)從產(chǎn)生到出現(xiàn)在用戶屏幕上仍然有最多500毫秒的滯后。我實(shí)測(cè)過(guò)一個(gè)內(nèi)部報(bào)表系統(tǒng)200個(gè)在線用戶輪詢間隔設(shè)成2秒一臺(tái)4核8G的云服務(wù)器Nginx連接數(shù)和后端CPU占用率都明顯抬升。這不是個(gè)例而是HTTP協(xié)議本身的請(qǐng)求-響應(yīng)模型決定的。1.2 WebSocket的設(shè)計(jì)目標(biāo)與效率實(shí)測(cè)WebSocket做的事情說(shuō)白了就是在HTTP這個(gè)“一問(wèn)一答”的協(xié)議之上建立一條全雙工的通信管道。所謂全雙工就是兩端都能隨時(shí)發(fā)數(shù)據(jù)不用等對(duì)方先開(kāi)口。從協(xié)議設(shè)計(jì)角度看WebSocket有兩個(gè)特別關(guān)鍵的點(diǎn)復(fù)用HTTP握手通道瀏覽器與服務(wù)器之間先通過(guò)HTTP完成一次“升級(jí)”握手后續(xù)數(shù)據(jù)交互不再走HTTP格式而是走WebSocket自己的幀格式。頭部開(kāi)銷極小普通HTTP請(qǐng)求即便沒(méi)有響應(yīng)體請(qǐng)求頭和響應(yīng)頭的開(kāi)銷加起來(lái)動(dòng)輒幾百字節(jié)WebSocket的數(shù)據(jù)幀一個(gè)不帶擴(kuò)展的文本幀頭部最小只要2字節(jié)。我在本機(jī)用兩個(gè)簡(jiǎn)單服務(wù)做過(guò)對(duì)比測(cè)試模擬100個(gè)客戶端每5秒推送一次1KB的數(shù)據(jù)連續(xù)跑1小時(shí)。方案服務(wù)器CPU占用總?cè)胝玖髁科骄扑脱舆tHTTP輪詢(2秒一次)68%約1.2GB最高2.1秒HTTP輪詢(500毫秒一次)89%約4.7GB最高600毫秒WebSocket長(zhǎng)連接21%約350MB最高120毫秒輪詢間隔越短延遲越接近但流量和CPU代價(jià)幾乎是線性增長(zhǎng)。WebSocket用很少的額外流量換來(lái)了接近“有消息就立刻到”的效果。這個(gè)測(cè)試基本決定了我后續(xù)做實(shí)時(shí)推送類功能都優(yōu)先選WebSocket。2. 握手的秘密從一個(gè)普通的HTTP GET到101 Switching Protocols2.1 一次完整的WebSocket握手流程拆解WebSocket的連接并不是憑空建立的它需要先走一次HTTP請(qǐng)求讓服務(wù)器確認(rèn)“這個(gè)客戶端想升級(jí)協(xié)議”。很多初學(xué)者在這里卡住不理解為什么WebSocket調(diào)試工具里明明填的是ws://地址抓包看到的卻是HTTP報(bào)文?？蛻舳税l(fā)起的握手請(qǐng)求長(zhǎng)這樣GET /ws/chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13 Origin: https://example.com四個(gè)關(guān)鍵點(diǎn)缺一不可Upgrade: websocket告訴服務(wù)器我想把協(xié)議升級(jí)成WebSocket。Connection: UpgradeHTTP協(xié)議規(guī)定只有帶這個(gè)頭的請(qǐng)求才能被視作升級(jí)請(qǐng)求。Sec-WebSocket-Key一個(gè)Base64編碼的隨機(jī)值用來(lái)驗(yàn)證服務(wù)器確實(shí)支持WebSocket。它不是密鑰更像一個(gè)隨機(jī)數(shù)。Sec-WebSocket-Version: 13協(xié)議版本號(hào)目前主流版本就是13。服務(wù)器收到之后會(huì)計(jì)算一個(gè)Sec-WebSocket-Accept字段規(guī)則非常固定把Sec-WebSocket-Key的值拼接固定GUID: 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 計(jì)算SHA-1哈希 對(duì)結(jié)果做Base64編碼這個(gè)固定GUID是RFC 6455標(biāo)準(zhǔn)里寫(xiě)死的所有實(shí)現(xiàn)都用同一個(gè)字符串。服務(wù)器的響應(yīng)長(zhǎng)這樣HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOo響應(yīng)碼是101不是200。很多人第一次寫(xiě)反向代理配置時(shí)發(fā)現(xiàn)WebSocket連不上看一眼后端日志卻發(fā)現(xiàn)握手請(qǐng)求都進(jìn)來(lái)了問(wèn)題往往出在反向代理把101響應(yīng)給攔了。2.2 握手之后的幀格式與分片傳輸握手成功之后雙方就開(kāi)始使用WebSocket自己的數(shù)據(jù)幀格式。一個(gè)數(shù)據(jù)幀由以下幾部分組成FIN1個(gè)bit表示當(dāng)前幀是不是消息的最后一個(gè)分片。RSV1-3各1個(gè)bit留給擴(kuò)展使用。opcode4個(gè)bit表示幀類型比如0x1是文本幀、0x2是二進(jìn)制幀、0x8是關(guān)閉幀、0x9和0xA分別是ping和pong幀。MASK1個(gè)bit標(biāo)識(shí)數(shù)據(jù)是否進(jìn)行了掩碼處理?？蛻舳税l(fā)給服務(wù)器的幀必須設(shè)置MASK為1服務(wù)器發(fā)給客戶端的幀可以不用。Payload length7位、16位或64位根據(jù)數(shù)據(jù)大小決定用幾個(gè)字節(jié)表示。Masking-key4字節(jié)配合掩碼算法使用。Payload data真正的業(yè)務(wù)數(shù)據(jù)。有一個(gè)細(xì)節(jié)值得多說(shuō)幾句為什么客戶端發(fā)給服務(wù)器的數(shù)據(jù)必須做掩碼處理RFC 6455的解釋是防止早期的代理服務(wù)器緩存投毒類攻擊通過(guò)改動(dòng)數(shù)據(jù)內(nèi)的關(guān)鍵字節(jié)來(lái)擾亂請(qǐng)求數(shù)據(jù)。雖然真實(shí)世界中這類攻擊現(xiàn)在已經(jīng)很罕見(jiàn)但這個(gè)設(shè)計(jì)仍然保留著。分片傳輸也是初學(xué)者容易迷惑的點(diǎn)。當(dāng)一個(gè)文本消息內(nèi)容很長(zhǎng)時(shí)發(fā)送方會(huì)把它拆成多個(gè)幀第一個(gè)幀的opcode是0x1文本幀類型FIN為0。中間幀的opcode是0x0延續(xù)幀F(xiàn)IN為0。最后一個(gè)延續(xù)幀的FIN為1。我用一個(gè)生活化的類比來(lái)解釋發(fā)一條長(zhǎng)消息就像寄一個(gè)大包裹。包裹裝不下分成了幾個(gè)小箱子。第一個(gè)箱子上寫(xiě)著“這是第一個(gè)箱子”中間的箱子上寫(xiě)著“繼續(xù)”最后一個(gè)箱子上寫(xiě)著“就此結(jié)束”。收件人把所有箱子拼在一起才得到完整的包裹。3. 心跳機(jī)制長(zhǎng)連接不“假死”的保障3.1 為什么明明連著網(wǎng)線卻收不到消息WebSocket連接建立以后如果長(zhǎng)時(shí)間沒(méi)有數(shù)據(jù)交互網(wǎng)絡(luò)鏈路中的某些設(shè)備可能把這條空閑連接判定為“不再使用”而默默回收掉?，F(xiàn)象就是客戶端和服務(wù)器都認(rèn)為連接還在實(shí)際上數(shù)據(jù)已經(jīng)送不到對(duì)方手里專業(yè)名詞叫“幽靈連接”。舉一個(gè)我踩過(guò)的真實(shí)例子。有個(gè)在線協(xié)作白板項(xiàng)目用戶畫(huà)了一筆前端通過(guò)WebSocket把數(shù)據(jù)發(fā)到后端后端廣播給其他端。中午休息時(shí)用戶離開(kāi)工位半小時(shí)回來(lái)再畫(huà)一筆前端連接一直沒(méi)有報(bào)錯(cuò)但其他端收不到。查了半天才發(fā)現(xiàn)網(wǎng)絡(luò)設(shè)備在連接空閑一段時(shí)間后靜默切斷了鏈路前端和服務(wù)器的TCP棧都沒(méi)有感知到斷開(kāi)。解決這個(gè)問(wèn)題的手段就是心跳機(jī)制通俗說(shuō)就是“定期發(fā)個(gè)信號(hào)告訴對(duì)方我還活著”。WebSocket協(xié)議本身提供了ping/pong幀作為協(xié)議層的心跳瀏覽器端WebSocket API沒(méi)有直接暴露ping/pong方法需要借助應(yīng)用層心跳來(lái)兜底。3.2 應(yīng)用層心跳與協(xié)議層心跳的取舍協(xié)議層ping/pong幀是標(biāo)準(zhǔn)的檢測(cè)方式服務(wù)端可以定時(shí)給客戶端發(fā)送ping幀客戶端如果遵守協(xié)議會(huì)自動(dòng)回一個(gè)pong幀。這是最干凈的方案不污染業(yè)務(wù)數(shù)據(jù)?？上g覽器端的WebSocket API到目前為止還沒(méi)有開(kāi)放直接發(fā)送ping幀的能力要做前端的心跳檢測(cè)只能用應(yīng)用層方案前端每隔N秒發(fā)送一個(gè)自定義文本消息比如{type:ping}收到后端回復(fù)的{type:pong}就算連接正常超過(guò)超時(shí)時(shí)間沒(méi)收到就主動(dòng)重連。我推薦的參數(shù)配置如下實(shí)測(cè)下來(lái)比較穩(wěn)參數(shù)推薦值原因心跳發(fā)送間隔25秒~30秒小于常見(jiàn)網(wǎng)絡(luò)設(shè)備空閑超時(shí)時(shí)間同時(shí)不會(huì)太頻繁超時(shí)閾值10秒連續(xù)兩個(gè)心跳周期未收到響應(yīng)判定連接異常重連最大次數(shù)5次避免服務(wù)端異常時(shí)前端無(wú)限重連打爆網(wǎng)關(guān)主動(dòng)關(guān)閉時(shí)間頁(yè)面可見(jiàn)性變化時(shí)切到后臺(tái)標(biāo)簽頁(yè)時(shí)暫停心跳回到前臺(tái)時(shí)立即檢測(cè)后端實(shí)現(xiàn)協(xié)議層心跳時(shí)要注意一點(diǎn)ping幀本身不攜帶業(yè)務(wù)數(shù)據(jù)不要依賴業(yè)務(wù)層去回復(fù)它。如果項(xiàng)目后續(xù)要接入多個(gè)客戶端類型包括小程序和原生App協(xié)議層心跳反而更可靠一些因?yàn)樗灰蕾嚇I(yè)務(wù)代碼。4. 實(shí)操環(huán)節(jié)用Django Channels從0到1搭建WebSocket推送服務(wù)4.1 Django Channels的基礎(chǔ)架構(gòu)與安裝配置Django默認(rèn)的WSGI模式只能處理HTTP請(qǐng)求跑不了WebSocket這種長(zhǎng)連接。Django Channels把Django的應(yīng)用模型從“請(qǐng)求-響應(yīng)”擴(kuò)展成了“事件-消費(fèi)者”天然支持WebSocket和異步任務(wù)。整體架構(gòu)可以這樣理解ASGI服務(wù)器比如Daphne或Uvicorn負(fù)責(zé)接收網(wǎng)絡(luò)請(qǐng)求區(qū)分HTTP請(qǐng)求和WebSocket連接。Channel Layer一個(gè)進(jìn)程間通信層通常用Redis實(shí)現(xiàn)負(fù)責(zé)把消息從一個(gè)消費(fèi)者轉(zhuǎn)發(fā)到另一個(gè)消費(fèi)者。Consumer處理WebSocket事件的異步代碼塊類似Django里的視圖函數(shù)。安裝依賴pip install channels channels-redis daphne在settings.py里配置INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, channels, myapp, ] ASGI_APPLICATION myproject.asgi.application CHANNEL_LAYERS { default: { BACKEND: channels_redis.core.RedisChannelLayer, CONFIG: { hosts: [(127.0.0.1, 6379)], }, }, }asgi.py文件需要調(diào)整成ASGI模式import os from django.core.asgi import get_asgi_application from channels.routing import ProtocolTypeRouter, URLRouter from django.urls import path from myapp.consumers import ChatConsumer os.environ.setdefault(DJANGO_SETTINGS_MODULE, myproject.settings) application ProtocolTypeRouter({ http: get_asgi_application(), websocket: URLRouter([ path(ws/chat/str:room_name/, ChatConsumer.as_asgi()), ]), })配置完成后啟動(dòng)服務(wù)要用Daphne而不是runserverdaphne -b 0.0.0.0 -p 8000 myproject.asgi:application如果還是用python manage.py runserver會(huì)走WSGI路徑WebSocket根本不會(huì)進(jìn)來(lái)。4.2 服務(wù)端消費(fèi)者代碼實(shí)現(xiàn)與消息廣播消費(fèi)者是整個(gè)WebSocket服務(wù)的核心。以群聊為例每個(gè)客戶端連接后加入一個(gè)分組消息進(jìn)來(lái)后通過(guò)Channel Layer廣播給同組其他客戶端。完整代碼import json from channels.generic.websocket import AsyncWebsocketConsumer class ChatConsumer(AsyncWebsocketConsumer): async def connect(self): self.room_name self.scope[url_route][kwargs][room_name] self.room_group_name fchat_{self.room_name} # 加入分組 await self.channel_layer.group_add( self.room_group_name, self.channel_name ) await self.accept() # 通知其他人新用戶加入 await self.channel_layer.group_send( self.room_group_name, { type: chat.message, message: json.dumps({sender: system, content: someone joined}), } ) async def disconnect(self, close_code): # 離開(kāi)分組 await self.channel_layer.group_discard( self.room_group_name, self.channel_name ) async def receive(self, text_data): data json.loads(text_data) message data[message] # 廣播給同組所有人包括自己 await self.channel_layer.group_send( self.room_group_name, { type: chat.message, message: json.dumps({sender: user, content: message}), } ) async def chat_message(self, event): # 這是group_send回調(diào)方法名字對(duì)應(yīng)type里的小數(shù)點(diǎn)后部分 await self.send(text_dataevent[message])有一個(gè)細(xì)節(jié)容易坑到新手group_send里的type字段值必須寫(xiě)成“chat.message”這樣的字符串然后Django Channels會(huì)自動(dòng)去找消費(fèi)者類里名為chat_message的方法把點(diǎn)號(hào)替換成下劃線。如果漏寫(xiě)了這個(gè)回調(diào)方法消息會(huì)靜默丟失不報(bào)錯(cuò)。后端有數(shù)據(jù)要主動(dòng)推送給前端時(shí)不需要經(jīng)過(guò)某個(gè)客戶端連接可以直接在普通視圖函數(shù)或異步任務(wù)里調(diào)用channel_layer.group_sendfrom asgiref.sync import async_to_sync from channels.layers import get_channel_layer def push_notification(room_name, payload): channel_layer get_channel_layer() async_to_sync(channel_layer.group_send)( fchat_{room_name}, { type: chat.message, message: json.dumps({sender: system, content: payload}), } )這就是熱搜里常說(shuō)的“后臺(tái)有數(shù)據(jù)前端推送”的標(biāo)準(zhǔn)解法。實(shí)際操作中我最常用的是在Celery任務(wù)結(jié)束時(shí)調(diào)用推送函數(shù)把處理結(jié)果實(shí)時(shí)告訴前端省掉了前端輪詢?nèi)蝿?wù)狀態(tài)的接口。4.3 前端接入與斷線重連的完整寫(xiě)法前端代碼看起來(lái)簡(jiǎn)單真正寫(xiě)好需要做不少細(xì)節(jié)處理。一個(gè)經(jīng)過(guò)線上驗(yàn)證的基礎(chǔ)模板class WSClient { constructor(url, options {}) { this.url url; this.ws null; this.heartbeatInterval options.heartbeatInterval || 25000; this.reconnectLimit options.reconnectLimit || 5; this.reconnectCount 0; this.handlerMap {}; this.connect(); } connect() { this.ws new WebSocket(this.url); this.ws.onopen () { console.log(WebSocket connected); this.reconnectCount 0; this.startHeartbeat(); this.emit(open); }; this.ws.onmessage (event) { let data; try { data JSON.parse(event.data); } catch (e) { console.warn(Invalid JSON message:, event.data); return; } if (data.type pong) { this.clearHeartbeatTimer(); } this.emit(data.type, data.payload); }; this.ws.onclose () { console.warn(WebSocket closed, attempting reconnect...); this.clearHeartbeatTimer(); if (this.reconnectCount this.reconnectLimit) { this.reconnectCount; setTimeout(() this.connect(), 3000 * this.reconnectCount); } }; this.ws.onerror (error) { console.error(WebSocket error:, error); this.ws.close(); }; } startHeartbeat() { this.heartbeatTimer setInterval(() { if (this.ws this.ws.readyState WebSocket.OPEN) { this.ws.send(JSON.stringify({ type: ping })); this.pongTimeout setTimeout(() { console.warn(Pong not received, closing connection.); this.ws.close(); }, 10000); } }, this.heartbeatInterval); } clearHeartbeatTimer() { if (this.heartbeatTimer) { clearInterval(this.heartbeatTimer); } if (this.pongTimeout) { clearTimeout(this.pongTimeout); } } on(type, callback) { this.handlerMap[type] callback; } emit(type, payload) { if (this.handlerMap[type]) { this.handlerMap[type](payload); } } send(type, payload) { if (this.ws this.ws.readyState WebSocket.OPEN) { this.ws.send(JSON.stringify({ type, payload })); } } } // 使用方式 const client new WSClient(ws://127.0.0.1:8000/ws/chat/lobby/); client.on(chat.message, (msg) { console.log(新消息:, msg); });斷線重連這里我踩過(guò)一個(gè)大坑如果直接調(diào)用new WSClient每次重連都會(huì)新建實(shí)例舊實(shí)例的定時(shí)器和回調(diào)容易重復(fù)注冊(cè)。正確做法是讓重連邏輯復(fù)用同一個(gè)實(shí)例只是重建底層的WebSocket對(duì)象像我上面代碼那樣在connect()里完成所有事件綁定。5. 實(shí)戰(zhàn)中高頻出現(xiàn)的問(wèn)題與排查技巧5.1 握手失敗從HTTP狀態(tài)碼反向定位問(wèn)題WebSocket接入過(guò)程中握著握著就斷了的情況十有八九出在握手階段。排查的時(shí)候先從瀏覽器開(kāi)發(fā)者工具的Network面板看WebSocket請(qǐng)求的狀態(tài)碼狀態(tài)碼404請(qǐng)求路徑不對(duì)。檢查前端URL里的路徑與后端路由是否完全一致包括大小寫(xiě)和尾斜杠。狀態(tài)碼403服務(wù)器拒絕了升級(jí)請(qǐng)求。常見(jiàn)原因是反向代理沒(méi)配置Upgrade相關(guān)頭或者跨域配置里允許的源列表不包含當(dāng)前來(lái)源。狀態(tài)碼500后端代碼拋異常了。把服務(wù)器日志打開(kāi)看看消費(fèi)里有沒(méi)有報(bào)錯(cuò)常見(jiàn)的是channel_layer配置有問(wèn)題Redis連接失敗。根本不發(fā)起WebSocket請(qǐng)求前端沒(méi)有正確使用ws://或wss://協(xié)議在HTTPS頁(yè)面上使用ws://會(huì)被瀏覽器直接攔截。我曾經(jīng)排查過(guò)一個(gè)Nginx代理場(chǎng)景下WebSocket連不上的問(wèn)題后端日志里一點(diǎn)錯(cuò)誤都沒(méi)有請(qǐng)求已經(jīng)到了Daphne但響應(yīng)就是回不去。最后定位到Nginx配置里缺了這兩個(gè)頭location /ws/ { proxy_pass http://backend_server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }5.2 連接穩(wěn)定但消息不推送連接還在心跳也正常就是收不到業(yè)務(wù)消息。這種問(wèn)題最讓人頭疼。按順序檢查三個(gè)地方Channel Layer的group是否一致消費(fèi)者加入的group名和視圖函數(shù)group_send時(shí)使用的group名必須完全相同字符串多一個(gè)空格都會(huì)靜默失敗。group_send回調(diào)是否存在urls路由里注冊(cè)的消費(fèi)者和group_send里type指向的方法名是否匹配。type是chat.message類里就要有chat_message方法。Redis連接是否正常如果用了Channels Redis可以先在命令行里執(zhí)行redis-cli ping確認(rèn)Redis沒(méi)有掛。Redis連接池耗盡也會(huì)導(dǎo)致group_send的延時(shí)增大表現(xiàn)為消息推送有幾十秒延遲。還有一類隱蔽問(wèn)題瀏覽器在同源策略下跨域WebSocket請(qǐng)求的Origin頭校驗(yàn)失敗。Django Channels默認(rèn)不校驗(yàn)Origin但如果前端和后端域名不一致還是建議在消費(fèi)者connect里自己加校驗(yàn)邏輯防止惡意站點(diǎn)消耗服務(wù)器連接資源。5.3 并發(fā)連接數(shù)上不去服務(wù)器內(nèi)存暴漲WebSocket和HTTP最大的區(qū)別在于HTTP請(qǐng)求處理完就釋放資源WebSocket則要為每個(gè)連接維持一個(gè)長(zhǎng)期的TCP連接和對(duì)應(yīng)的內(nèi)存緩沖。默認(rèn)的Daphne配置下每個(gè)連接會(huì)占用幾十KB到幾百KB的內(nèi)存如果連接數(shù)上千內(nèi)存和文件描述符都會(huì)成為瓶頸。適當(dāng)調(diào)低Daphne的worker數(shù)量避免線程切換開(kāi)銷過(guò)大。合理設(shè)置WebSocket消息大小限制防止客戶端一次發(fā)送超大幀拖垮服務(wù)端?？臻e連接及時(shí)清理通過(guò)心跳機(jī)制發(fā)現(xiàn)異常連接后立即關(guān)閉。使用多進(jìn)程部署時(shí)確保Channel Layer指向同一個(gè)Redis實(shí)例不同進(jìn)程間的消費(fèi)者才能互相轉(zhuǎn)發(fā)消息。5.4 React項(xiàng)目里SSE和WebSocket怎么選很多React項(xiàng)目需要監(jiān)聽(tīng)文件變化、任務(wù)狀態(tài)等連續(xù)事件。SSE和WebSocket都能做服務(wù)器推送但適用場(chǎng)景完全不同。特性SSEWebSocket協(xié)議HTTPWebSocket數(shù)據(jù)格式文本可跨域文本或二進(jìn)制雙向通信僅服務(wù)器到客戶端雙向自動(dòng)重連瀏覽器內(nèi)置需要自行實(shí)現(xiàn)兼容性現(xiàn)代瀏覽器基本可用同左如果只需要從服務(wù)器單向推數(shù)據(jù)比如日志流、文件變化通知SSE足夠?qū)崿F(xiàn)簡(jiǎn)單瀏覽器原生支持。如果需要雙向交互比如在線白板、聊天室、多人協(xié)同編輯就必須用WebSocket。我通常建議先想清楚數(shù)據(jù)流方向再?zèng)Q定方案不要為了用新技術(shù)而強(qiáng)行上WebSocket。6. 反向WebSocket、權(quán)限校驗(yàn)與長(zhǎng)連接管理6.1 反向WebSocket解決了什么問(wèn)題常規(guī)WebSocket場(chǎng)景是瀏覽器主動(dòng)連服務(wù)器但有些場(chǎng)景是服務(wù)器端的程序需要主動(dòng)向中心服務(wù)注冊(cè)并等待中心服務(wù)下達(dá)指令。典型的應(yīng)用是工控設(shè)備、邊緣計(jì)算節(jié)點(diǎn)、IoT設(shè)備它們處于內(nèi)網(wǎng)環(huán)境沒(méi)有公網(wǎng)IP外網(wǎng)服務(wù)無(wú)法直接連過(guò)去。此時(shí)設(shè)備主動(dòng)發(fā)起WebSocket連接保持長(zhǎng)連接中心服務(wù)就可以通過(guò)這條連接隨時(shí)給設(shè)備下發(fā)指令。這類連接常被稱為“反向WebSocket”或“設(shè)備主動(dòng)注冊(cè)模式”。實(shí)現(xiàn)思路和普通WebSocket一致區(qū)別在于連接的發(fā)起方不是瀏覽器而是服務(wù)端程序。Python里用websockets庫(kù)起一個(gè)常駐連接import asyncio import websockets import json async def device_worker(): uri wss://center.example.com/ws/device/register async with websockets.connect(uri) as websocket: # 注冊(cè)設(shè)備信息 await websocket.send(json.dumps({device_id: abc-123, action: register})) # 持續(xù)監(jiān)聽(tīng)中心下發(fā)的指令 async for message in websocket: cmd json.loads(message) print(receive command:, cmd) # 執(zhí)行指令并返回結(jié)果 await websocket.send(json.dumps({status: ok, result: done})) asyncio.run(device_worker())這種模式下心跳機(jī)制就顯得格外重要設(shè)備端如果連接斷開(kāi)必須盡快重連并重新注冊(cè)否則中心服務(wù)的指令就會(huì)丟失。6.2 連接校驗(yàn)與權(quán)限控制WebSocket連接建立后在第一個(gè)業(yè)務(wù)消息到來(lái)之前是校驗(yàn)身份的最佳時(shí)機(jī)。推薦兩種做法握手階段通過(guò)URL參數(shù)帶tokenws://example.com/ws/chat/?tokenxxx后端在connect方法里解析token驗(yàn)證失敗就調(diào)用close(code4401)拒絕連接。前端先把token放到子協(xié)議里后端在scope里讀取。這個(gè)方式稍微復(fù)雜一些但避免了token出現(xiàn)在URL里被日志記錄的風(fēng)險(xiǎn)。我實(shí)戰(zhàn)中更喜歡用第一種方式簡(jiǎn)單直觀配合JWT的過(guò)期時(shí)間做校驗(yàn)足夠用了。遇到需要頻繁刷新token的場(chǎng)景可以在心跳消息里攜帶最新的token后端發(fā)現(xiàn)token即將過(guò)期時(shí)主動(dòng)通知前端重新認(rèn)證。6.3 連接數(shù)監(jiān)控與容量規(guī)劃一個(gè)不常被提起但很重要的經(jīng)驗(yàn)給WebSocket服務(wù)和普通HTTP服務(wù)做監(jiān)控時(shí)關(guān)注點(diǎn)完全不同。HTTP服務(wù)關(guān)注QPS和響應(yīng)時(shí)間WebSocket服務(wù)則要重點(diǎn)關(guān)注當(dāng)前活躍連接數(shù)以及新增連接數(shù)、斷開(kāi)連接數(shù)的變化曲線。連接建立耗時(shí)和消息轉(zhuǎn)發(fā)耗時(shí)。文件描述符使用量這是WebSocket擴(kuò)容時(shí)最先觸碰到的瓶頸。實(shí)操中我會(huì)在Redis里維護(hù)一個(gè)連接計(jì)數(shù)器每次connect時(shí)加一disconnect時(shí)減一再通過(guò)一個(gè)定時(shí)任務(wù)把計(jì)數(shù)上報(bào)到監(jiān)控系統(tǒng)。配合告警規(guī)則連接數(shù)突增或突降都能第一時(shí)間發(fā)現(xiàn)。7. 協(xié)議擴(kuò)展與常見(jiàn)替代方案7.1 MQTT與WebSocket的關(guān)系做物聯(lián)網(wǎng)的同學(xué)經(jīng)常拿MQTT和WebSocket對(duì)比。兩者定位并不沖突WebSocket是傳輸層協(xié)議負(fù)責(zé)建立雙向通信通道MQTT是應(yīng)用層消息協(xié)議負(fù)責(zé)定義消息主題、發(fā)布訂閱語(yǔ)義、服務(wù)質(zhì)量等級(jí)。實(shí)際項(xiàng)目中兩者經(jīng)常結(jié)合使用瀏覽器通過(guò)WebSocket連接MQTT Broker的網(wǎng)關(guān)Broker內(nèi)部再用MQTT協(xié)議與設(shè)備通信。MQTT更適用于資源受限、網(wǎng)絡(luò)不穩(wěn)定的物聯(lián)網(wǎng)場(chǎng)景它有更細(xì)致的QoS等級(jí)和遺囑消息機(jī)制。WebSocket則更貼近Web生態(tài)直接在瀏覽器端使用。方案選型時(shí)考慮兩個(gè)問(wèn)題的答案是否跨網(wǎng)絡(luò)、是否要求消息可靠投遞比如設(shè)備掉線后的離線消息。7.2 從HTTP/2、gRPC到WebSocket有些團(tuán)隊(duì)會(huì)用HTTP/2 Server Push或gRPC Streaming來(lái)做實(shí)時(shí)通信。HTTP/2的Server Push主要是提前推送靜態(tài)資源用來(lái)做業(yè)務(wù)數(shù)據(jù)推送并不合適而且兼容性和復(fù)用邏輯都更復(fù)雜。gRPC基于HTTP/2雙工流能力很強(qiáng)適合后端服務(wù)之間的高吞吐通信。WebSocket的優(yōu)勢(shì)在于瀏覽器支持零依賴且協(xié)議簡(jiǎn)單、調(diào)試方便。不是性能不夠而是生態(tài)路徑更直接。從我這些年的實(shí)踐來(lái)看區(qū)分點(diǎn)通常是端到端鏈路兩端的角色。如果有一端確定是瀏覽器WebSocket基本是默認(rèn)選擇如果兩端都是后端服務(wù)gRPC和消息隊(duì)列方案往往比WebSocket更合適。個(gè)人處理實(shí)時(shí)推送類項(xiàng)目時(shí)我會(huì)先定一個(gè)基線方案瀏覽器端用WebSocket后端用Channel Layer廣播心跳間隔25秒連接超時(shí)10秒死連自動(dòng)重連。實(shí)踐證明這套配置可以覆蓋絕大多數(shù)業(yè)務(wù)場(chǎng)景。有特殊需求比如離線消息、消息可靠消費(fèi)再在應(yīng)用層做擴(kuò)展。實(shí)時(shí)通信這個(gè)領(lǐng)域真正的復(fù)雜度很少出現(xiàn)在協(xié)議本身更多在于連接管理和容錯(cuò)設(shè)計(jì)上把功夫花在后半部分是最值得的投入。