搞WebSocket這幾年我最大的感受是很多人不是不會(huì)用而是沒(méi)搞清楚自己真正需要解決的到底是“連接”還是“推送”。WebSocket是一個(gè)協(xié)議但日常里我們用它的理由幾乎都是同一件事——服務(wù)端隨時(shí)有數(shù)據(jù)要往瀏覽器推。這篇文章我不打算寫(xiě)成文檔翻譯而是把我在實(shí)際項(xiàng)目里驗(yàn)證過(guò)的東西、踩過(guò)的坑、反復(fù)調(diào)過(guò)的參數(shù)都攤開(kāi)講。前后端都會(huì)有從最小可用的連接寫(xiě)法到Django Channels實(shí)時(shí)推送、反向WebSocket、心跳機(jī)制再到React里的選型和“連接正常但收不到消息”的排查思路一條線(xiàn)走完。1. 先想清楚你要的到底是“連接”還是“推送”1.1 WebSocket到底解決了我什么問(wèn)題先說(shuō)最底層的邏輯。HTTP協(xié)議是請(qǐng)求-響應(yīng)模型客戶(hù)端不發(fā)請(qǐng)求服務(wù)端就沒(méi)有合法理由往客戶(hù)端發(fā)數(shù)據(jù)。早期做實(shí)時(shí)功能只能輪詢(xún)前端每隔幾秒發(fā)一個(gè)請(qǐng)求問(wèn)“有數(shù)據(jù)嗎”服務(wù)端要么返回空要么返回新數(shù)據(jù)。這種做法浪費(fèi)請(qǐng)求、延遲不可控而且服務(wù)器壓力很大。后來(lái)有了長(zhǎng)輪詢(xún)、SSE再后來(lái)就是WebSocket。WebSocket的本質(zhì)是在一次HTTP升級(jí)握手之后把連接升級(jí)成一條全雙工的TCP長(zhǎng)連接。全雙工的意思是客戶(hù)端和服務(wù)端都能隨時(shí)往這條通道里寫(xiě)數(shù)據(jù)不用等對(duì)方先說(shuō)話(huà)。你可以把它想成HTTP是“打電話(huà)問(wèn)一句答一句”而WebSocket是“電話(huà)一直掛著誰(shuí)想起什么隨時(shí)說(shuō)”。所以WebSocket真正解決的問(wèn)題不是“推送”這個(gè)概念本身——SSE也能單向推送——而是“雙向”“低延遲”“長(zhǎng)期連接”這幾個(gè)特性的組合。在在線(xiàn)聊天、協(xié)同編輯、行情推送、游戲?qū)?zhàn)、服務(wù)端日志實(shí)時(shí)輸出這些場(chǎng)景里它是目前最順手的選擇。1.2 WebSocket、SSE、輪詢(xún)?cè)趺催x不是所有實(shí)時(shí)場(chǎng)景都該上WebSocket。選型之前先確認(rèn)你的需求到底落在哪個(gè)象限數(shù)據(jù)流向是不是雙向的消息頻率高不高客戶(hù)端環(huán)境是否可控方案方向連接類(lèi)型自動(dòng)重連適用場(chǎng)景輪詢(xún)只能客戶(hù)端主動(dòng)問(wèn)HTTP短連接天然自愈低頻、低延遲不敏感、方案最簡(jiǎn)單的場(chǎng)景長(zhǎng)輪詢(xún)服務(wù)端掛起請(qǐng)求等待數(shù)據(jù)HTTP“半長(zhǎng)”連接每次結(jié)束后要重建兼容老環(huán)境的中間態(tài)方案SSE服務(wù)端單向推送HTTP長(zhǎng)連接瀏覽器EventSource自帶服務(wù)端到客戶(hù)端的單向通知WebSocket雙向?qū)崟r(shí)通信升級(jí)后的TCP長(zhǎng)連接需要自己實(shí)現(xiàn)聊天、協(xié)同、行情、遠(yuǎn)程控制等很多項(xiàng)目里“實(shí)時(shí)推送數(shù)據(jù)”其實(shí)只是服務(wù)端到前端單向比如文件變更監(jiān)聽(tīng)、構(gòu)建進(jìn)度、訂單狀態(tài)更新。這種場(chǎng)景我優(yōu)先用SSE因?yàn)镋ventSource自帶重連和事件ID實(shí)現(xiàn)成本極低。WebSocket雖然也能做但你自己要handle斷線(xiàn)重連、心跳、消息格式統(tǒng)一性?xún)r(jià)比不夠。前端要雙向交互才值得選WebSocket。比如一個(gè)監(jiān)控頁(yè)面不僅要看構(gòu)建日志還要能隨時(shí)點(diǎn)“暫?！薄扒袚Q分支”那就用WebSocket。因?yàn)镾SE只有“服務(wù)端推瀏覽器”一條路瀏覽器想給服務(wù)端發(fā)指令還是要發(fā)HTTP請(qǐng)求兩邊來(lái)回跳協(xié)議很別扭。1.3 握手與消息幀連接建立后發(fā)生了什么很多人調(diào)了幾天連不上問(wèn)題往往出在握手階段。WebSocket連接的第一步不是TCP直連而是通過(guò)HTTP發(fā)起一個(gè)升級(jí)請(qǐng)求。請(qǐng)求頭里有一個(gè)關(guān)鍵字段Sec-WebSocket-Key服務(wù)端拿到后拼接一個(gè)固定GUID做SHA-1哈希再加Base64編碼得到Sec-WebSocket-Accept返回給客戶(hù)端同時(shí)返回狀態(tài)碼101 Switching Protocols。這一步完成之后HTTP這個(gè)“殼”就丟掉了剩下的全是WebSocket幀。幀里面有幾個(gè)字段決定了消息怎么解讀FIN標(biāo)記是不是最后一幀Opcode決定是文本幀、二進(jìn)制幀還是Ping/Pong控制幀客戶(hù)端發(fā)給服務(wù)端的幀必須做掩碼處理這是協(xié)議強(qiáng)制要求。這些細(xì)節(jié)平時(shí)寫(xiě)業(yè)務(wù)代碼用不到但抓包和排查問(wèn)題時(shí)非常有用。我可以很負(fù)責(zé)地說(shuō)協(xié)議層真正讓初學(xué)者卡住的不是幀格式而是“服務(wù)端不知道該怎么發(fā)消息給某個(gè)特定客戶(hù)端”。這個(gè)問(wèn)題在實(shí)際工程里要靠連接標(biāo)識(shí)、路由、房間分組來(lái)解決后面第三章講Django推送時(shí)會(huì)展開(kāi)。2. 從零搭一個(gè)能用的WebSocket前端接入與后端實(shí)現(xiàn)2.1 前端最小可用代碼別急著上框架先別碰那些封裝好的庫(kù)原生WebSocket對(duì)象其實(shí)已經(jīng)足夠完成八成業(yè)務(wù)需求。瀏覽器端的用法非常固定創(chuàng)建實(shí)例、掛四個(gè)事件、用send()發(fā)消息、用close()關(guān)閉。const socket new WebSocket(ws://localhost:8000/ws/chat/); socket.addEventListener(open, () { console.log(連接打開(kāi)); socket.send(JSON.stringify({ type: chat.message, content: hello server })); }); socket.addEventListener(message, (event) { // event.data 可能是字符串或 Blob取決于服務(wù)端發(fā)的是文本幀還是二進(jìn)制幀 const data JSON.parse(event.data); console.log(收到消息:, data); }); socket.addEventListener(close, (event) { console.log(連接關(guān)閉, event.code, event.reason); }); socket.addEventListener(error, (err) { console.error(連接出錯(cuò), err); });這里有個(gè)很容易踩的坑error事件之后通常緊跟著close事件很多人只在error里打日志、沒(méi)在close里做重連導(dǎo)致排查時(shí)只看到“報(bào)錯(cuò)了”但不知道連接已徹底斷開(kāi)。真正的狀態(tài)判斷應(yīng)該看readyState0是正在連接1是已打開(kāi)2是正在關(guān)閉3是已關(guān)閉。生產(chǎn)環(huán)境一定要用wss://而不是ws://。瀏覽器在HTTPS頁(yè)面里發(fā)起明文WebSocket會(huì)被直接攔截這個(gè)問(wèn)題在本地開(kāi)發(fā)時(shí)不明顯一上測(cè)試環(huán)境就“莫名其妙連不上”。2.2 后端實(shí)現(xiàn)Node.js和Python兩條路后端要快速搭一個(gè)可用的WebSocket服務(wù)我的首選分別是Node.js的ws庫(kù)和Python的websockets庫(kù)兩個(gè)都很成熟踩坑少。// Node.js ws const { WebSocketServer } require(ws); const wss new WebSocketServer({ port: 8080 }); wss.on(connection, (ws, req) { console.log(客戶(hù)端連接, req.headers[sec-websocket-protocol]); ws.on(message, (data) { console.log(收到:, String(data)); ws.send(pong: data); }); ws.on(close, () { console.log(客戶(hù)端斷開(kāi)); }); });# Python websockets 庫(kù) import asyncio import websockets async def handler(websocket): async for message in websocket: print(收到:, message) await websocket.send(pong: message) async def main(): async with websockets.serve(handler, 0.0.0.0, 8765): await asyncio.Future() if __name__ __main__: asyncio.run(main())兩個(gè)示例的套路是一樣的監(jiān)聽(tīng)連接、處理消息、回發(fā)數(shù)據(jù)。區(qū)別在于語(yǔ)言生態(tài)。Node.js做實(shí)時(shí)服務(wù)的并發(fā)處理能力在長(zhǎng)連接場(chǎng)景下表現(xiàn)很好Python則勝在和數(shù)據(jù)開(kāi)發(fā)、機(jī)器學(xué)習(xí)鏈路銜接方便。如果你的業(yè)務(wù)棧已經(jīng)是Django想在不脫離ORM、不拆微服務(wù)的前提下加實(shí)時(shí)能力那就直接看第三章的Django Channels。2.3 websocket test client測(cè)連接是第一步我調(diào)試WebSocket時(shí)幾乎從不用“先寫(xiě)兩端代碼再聯(lián)調(diào)”的方式一定是先用一個(gè)獨(dú)立的測(cè)試客戶(hù)端把服務(wù)端連接驗(yàn)證通了再去寫(xiě)前端頁(yè)面。這能把“協(xié)議問(wèn)題”和“代碼問(wèn)題”分開(kāi)。命令行工具wscat是最快的選擇npm install -g wscat wscat -c ws://localhost:8080 # 連接成功后直接輸入消息 hello pong: hello如果沒(méi)有Node環(huán)境用Python也能快速寫(xiě)一個(gè)測(cè)試腳本import asyncio import websockets async def test(): async with websockets.connect(ws://localhost:8765) as ws: await ws.send(hello) response await ws.recv() print(收到:, response) if __name__ __main__: asyncio.run(test())瀏覽器調(diào)試也有個(gè)很省事的辦法直接打開(kāi)控制臺(tái)手動(dòng)new WebSocket(...)然后挨個(gè)在控制臺(tái)調(diào)用send()觀(guān)察onmessage回調(diào)有沒(méi)有觸發(fā)。這樣不用修改任何業(yè)務(wù)代碼就能驗(yàn)證服務(wù)端能不能連通。注意ws://echo.websocket.org這類(lèi)公共測(cè)試服務(wù)現(xiàn)在很不穩(wěn)定時(shí)好時(shí)壞。你別拿它當(dāng)服務(wù)端可用性的依據(jù)最好本地起一個(gè)簡(jiǎn)單的echo服務(wù)或者就用上面兩個(gè)腳本直接測(cè)你自己的后端。3. Python Django 實(shí)時(shí)推送實(shí)戰(zhàn)后臺(tái)有數(shù)據(jù)就往前端推3.1 Django Channels給同步世界打開(kāi)的異步窗口Django本身的請(qǐng)求-響應(yīng)模型里沒(méi)有“長(zhǎng)連接”這個(gè)概念一個(gè)請(qǐng)求進(jìn)來(lái)處理完響應(yīng)返回連接結(jié)束。要在Django里跑WebSocket就得引入channels。它的核心思路是把Django從WSGI的世界推進(jìn)到ASGI的世界ASGI允許一個(gè)進(jìn)程同時(shí)處理HTTP和WebSocket還能在事件循環(huán)里跑異步任務(wù)。先看項(xiàng)目里最基礎(chǔ)的配置長(zhǎng)什么樣。asgi.py里要配置一個(gè)協(xié)議類(lèi)型路由器告訴服務(wù)器HTTP請(qǐng)求走原來(lái)的Django處理邏輯WebSocket連接走URL路由。# asgi.py import os from django.core.asgi import get_asgi_application os.environ.setdefault(DJANGO_SETTINGS_MODULE, myproject.settings) django_asgi_app get_asgi_application() from channels.routing import ProtocolTypeRouter, URLRouter from chat import routing application ProtocolTypeRouter({ http: django_asgi_app, websocket: URLRouter(routing.websocket_urlpatterns), })對(duì)應(yīng)的routing.py負(fù)責(zé)把WebSocket路徑映射到Consumer# routing.py from django.urls import path from chat.consumers import ChatConsumer websocket_urlpatterns [ path(ws/chat/, ChatConsumer.as_asgi()), ]Consumer是處理WebSocket連接的視圖層里面通過(guò)connect、receive、disconnect三個(gè)回調(diào)管理生命周期。和普通視圖最大的區(qū)別是它可以寫(xiě)異步代碼可以使用channel_layer做多客戶(hù)端之間的消息路由。3.2 后臺(tái)數(shù)據(jù)推送到前端從任務(wù)到瀏覽器的完整鏈路我見(jiàn)過(guò)太多Django項(xiàng)目“后臺(tái)有數(shù)據(jù)但前端收不到”的場(chǎng)景根因幾乎都是不理解channel_layer的用法。channel_layer可以理解成一套跨進(jìn)程消息總線(xiàn)常見(jiàn)實(shí)現(xiàn)是Redis。它的核心操作是group_add和group_send先把某個(gè)WebSocket連接加到一個(gè)組然后往整個(gè)組廣播消息。一個(gè)從后臺(tái)任務(wù)推數(shù)據(jù)到前端的完整鏈路應(yīng)該這樣設(shè)計(jì)# consumers.py import json import asyncio from channels.generic.websocket import AsyncWebsocketConsumer class StreamConsumer(AsyncWebsocketConsumer): async def connect(self): self.group_name stream await self.channel_layer.group_add(self.group_name, self.channel_name) await self.accept() async def disconnect(self, close_code): await self.channel_layer.group_discard(self.group_name, self.channel_name) async def receive(self, text_dataNone, bytes_dataNone): # 前端如果發(fā)消息可以在這里處理控制指令 pass async def data_push(self, event): # 注意方法名必須是 data_push對(duì)應(yīng) group_send 消息里的 type await self.send(text_datajson.dumps(event[payload]))往前端推送的動(dòng)作可以由Celery任務(wù)、Redis訂閱、定時(shí)腳本、甚至是另一個(gè)WebSocket客戶(hù)端觸發(fā)。通過(guò)Celery任務(wù)推送的寫(xiě)法如下# tasks.py from celery import shared_task from asgiref.sync import async_to_sync from channels.layers import get_channel_layer shared_task def push_stream_data(payload): channel_layer get_channel_layer() async_to_sync(channel_layer.group_send)( stream, { type: data.push, payload: payload, } )這就把“后臺(tái)有數(shù)據(jù)”和“前端收到數(shù)據(jù)”之間的縫隙補(bǔ)上了。后臺(tái)任務(wù)不管來(lái)自隊(duì)列還是定時(shí)器只要調(diào)一次group_send所有連接了stream組的WebSocket都會(huì)收到消息。一個(gè)新手特別容易犯的錯(cuò)誤把推送邏輯寫(xiě)在Consumer的receive里以為前端發(fā)一條消息后服務(wù)端就能“順便”推別的數(shù)據(jù)。這樣做在單連接單進(jìn)程時(shí)好像能跑但一旦多實(shí)例部署消息就亂了。推送必須通過(guò)channel_layer走組的廣播機(jī)制不要依賴(lài)某個(gè)具體的連接對(duì)象。3.3 反向WebSocket讓Django后臺(tái)去連接外部推送服務(wù)熱詞里有個(gè)“python反向websocket”這個(gè)叫法其實(shí)不太嚴(yán)謹(jǐn)?shù)馑己苊鞔_你的后端不是WebSocket的服務(wù)端而是作為客戶(hù)端去連接另一個(gè)WebSocket服務(wù)然后把收到的數(shù)據(jù)再轉(zhuǎn)發(fā)給瀏覽器。典型場(chǎng)景是行情推送、第三方事件流、IoT網(wǎng)關(guān)數(shù)據(jù)接入。import asyncio import websockets import json from channels.generic.websocket import AsyncWebsocketConsumer class ExternalBridgeConsumer(AsyncWebsocketConsumer): async def connect(self): self.group_name bridge await self.channel_layer.group_add(self.group_name, self.channel_name) await self.accept() self.external_task asyncio.create_task(self.listen_external()) async def disconnect(self, close_code): if hasattr(self, external_task): self.external_task.cancel() await self.channel_layer.group_discard(self.group_name, self.channel_name) async def listen_external(self): uri wss://example.com/events while True: try: async with websockets.connect(uri) as ws: async for raw in ws: await self.channel_layer.group_send( self.group_name, {type: external.event, raw: raw} ) except Exception as exc: # 斷線(xiàn)重連千萬(wàn)不要裸奔 print(外部連接斷開(kāi)3秒后重連:, exc) await asyncio.sleep(3) async def external_event(self, event): await self.send(text_dataevent[raw])這段代碼的核心思路是每個(gè)瀏覽器連接進(jìn)來(lái)后后端在同一個(gè)Consumer里額外開(kāi)一個(gè)協(xié)程去連外部服務(wù)外部服務(wù)推來(lái)的消息經(jīng)過(guò)channel_layer轉(zhuǎn)發(fā)給組內(nèi)所有瀏覽器。簡(jiǎn)單項(xiàng)目這樣演示夠用但真要上生產(chǎn)強(qiáng)烈建議把“外部連接”抽成獨(dú)立的守護(hù)進(jìn)程不要讓一個(gè)外部連接跟著瀏覽器連接一起銷(xiāo)毀。否則每多一個(gè)瀏覽器就多一條外向連接服務(wù)端壓力會(huì)成倍上漲。4. 心跳機(jī)制為什么連接總是“假死”4.1 心跳到底防的是什么三種典型的“靜默死亡”一個(gè)WebSocket連接看起來(lái)是通的實(shí)際上早就“死”了這種問(wèn)題在真實(shí)環(huán)境里非常常見(jiàn)因?yàn)橹虚g隔著太多東西。第一種是網(wǎng)絡(luò)設(shè)備超時(shí)清理。辦公室路由器、云廠(chǎng)商的負(fù)載均衡、Nginx反代默認(rèn)都可能把空閑太久的TCP連接默默回收掉?？臻e時(shí)間通常在2到5分鐘超過(guò)這個(gè)時(shí)間連接就從設(shè)備狀態(tài)表里被刪了但對(duì)兩端來(lái)說(shuō)這個(gè)斷開(kāi)動(dòng)作根本沒(méi)被感知因?yàn)闆](méi)有任何一端主動(dòng)發(fā)RST。第二種是半開(kāi)連接。一端宕機(jī)、斷電、斷網(wǎng)另一端不會(huì)立刻收到消息。TCP是“盡力而為”的只有你試著發(fā)送數(shù)據(jù)并且等不到ACK你才會(huì)發(fā)現(xiàn)對(duì)方?jīng)]了。如果業(yè)務(wù)里一直沒(méi)人說(shuō)話(huà)兩端會(huì)永遠(yuǎn)維持一個(gè)看似健康但實(shí)際已經(jīng)斷裂的連接。第三種是服務(wù)端主動(dòng)清理。很多框架會(huì)把長(zhǎng)時(shí)間不活動(dòng)的連接標(biāo)記為僵尸連接定時(shí)清理。如果你的客戶(hù)端沒(méi)有任何保活機(jī)制服務(wù)端就會(huì)覺(jué)得這個(gè)客戶(hù)端“不活躍”直接踢掉。所以心跳不是可選項(xiàng)而是長(zhǎng)連接的必需品。它的目的只有一個(gè)讓雙方定期確認(rèn)“對(duì)方還活著”。4.2 誰(shuí)來(lái)ping誰(shuí)來(lái)pong協(xié)議層和業(yè)務(wù)層的心跳實(shí)現(xiàn)WebSocket協(xié)議本身定義了Ping和Pong控制幀但這里有個(gè)絕大多數(shù)前端開(kāi)發(fā)者不知道的坑瀏覽器的WebSocket API沒(méi)有暴露發(fā)Ping幀的方法。服務(wù)端可以向?yàn)g覽器發(fā)Ping瀏覽器必須自動(dòng)回Pong這是協(xié)議強(qiáng)制行為但瀏覽器不能主動(dòng)發(fā)Ping想發(fā)只能通過(guò)業(yè)務(wù)層自己定義一套“心跳消息”。所以形成了兩套方案。方案一是服務(wù)端發(fā)起協(xié)議層心跳服務(wù)端每隔一段時(shí)間發(fā)一個(gè)Ping幀瀏覽器由協(xié)議棧自動(dòng)回復(fù)Pong。方案二是業(yè)務(wù)層心跳前后端約定一種消息類(lèi)型比如前端發(fā){type:ping}后端回{type:pong}。我在Django Channels里實(shí)踐比較多的是業(yè)務(wù)層心跳因?yàn)镃hannels對(duì)底層控制幀的接入沒(méi)有直接暴露業(yè)務(wù)層心跳反而最可控。import asyncio import json from channels.generic.websocket import AsyncWebsocketConsumer class HeartbeatConsumer(AsyncWebsocketConsumer): async def connect(self): await self.accept() self.last_seen asyncio.get_event_loop().time() self.hb_task asyncio.create_task(self.heartbeat_loop()) async def disconnect(self, close_code): if hasattr(self, hb_task): self.hb_task.cancel() async def heartbeat_loop(self): while True: await asyncio.sleep(20) if asyncio.get_event_loop().time() - self.last_seen 45: # 超過(guò)45秒沒(méi)收到任何消息認(rèn)為連接已死 await self.close(code4001, reasonheartbeat timeout) return await self.send(text_datajson.dumps({type: ping})) async def receive(self, text_dataNone, bytes_dataNone): data json.loads(text_data or {}) if data.get(type) pong: self.last_seen asyncio.get_event_loop().time() else: # 處理正常業(yè)務(wù)消息 pass前端對(duì)應(yīng)的心跳代碼let heartbeatTimer null; const HEARTBEAT_INTERVAL 20000; socket.addEventListener(open, () { heartbeatTimer setInterval(() { if (socket.readyState WebSocket.OPEN) { socket.send(JSON.stringify({ type: pong, ts: Date.now() })); } }, HEARTBEAT_INTERVAL); }); socket.addEventListener(close, () { clearInterval(heartbeatTimer); });我這里的實(shí)現(xiàn)邏輯是后端發(fā)ping前端收到后回復(fù)pong后端通過(guò)last_seen判斷是否超時(shí)。其實(shí)也可以反過(guò)來(lái)設(shè)計(jì)前端主動(dòng)發(fā)心跳、后端被動(dòng)響應(yīng)甚至什么都不響應(yīng)只要超時(shí)能檢測(cè)出來(lái)就行。關(guān)鍵在于心跳消息本身要輕消息體不要塞業(yè)務(wù)數(shù)據(jù)心跳定時(shí)器要管理好連接關(guān)閉后一定要清理否則會(huì)泄漏。4.3 心跳參數(shù)與重連策略心跳參數(shù)沒(méi)有銀彈但有兩個(gè)參考區(qū)間。時(shí)間間隔一般選20到30秒比中間網(wǎng)絡(luò)設(shè)備的空閑超時(shí)時(shí)間短一半以上太長(zhǎng)起不到?；钚Ч虅t白白消耗帶寬和CPU。超時(shí)判斷不要只看一次Pong沒(méi)回就斷建議連續(xù)2到3次無(wú)響應(yīng)再斷開(kāi)避免網(wǎng)絡(luò)抖動(dòng)誤殺正常連接。重連不能用“斷線(xiàn)后立刻重連”因?yàn)槿绻?wù)端正在重啟或網(wǎng)絡(luò)正在故障立刻重連只會(huì)連續(xù)失敗。指數(shù)退避是常見(jiàn)做法第一次等1秒第二次2秒第三次4秒最多30秒封頂同時(shí)加入隨機(jī)抖動(dòng)避免大量客戶(hù)端同時(shí)重連造成服務(wù)端沖擊。function connectWithRetry(url, maxDelay 30) { let attempt 0; function connect() { const socket new WebSocket(url); socket.addEventListener(close, () { const delay Math.min(maxDelay, Math.pow(2, attempt)) Math.random() * 1000; attempt 1; setTimeout(connect, delay); }); socket.addEventListener(open, () { attempt 0; }); } connect(); }注意一個(gè)連接只能有一個(gè)心跳任務(wù)。我曾經(jīng)在重連邏輯里沒(méi)有取消舊心跳導(dǎo)致同一個(gè)瀏覽器連接上出現(xiàn)兩個(gè)心跳循環(huán)服務(wù)端收到的pong頻率翻倍嚇壞了一堆監(jiān)控告警。重連成功時(shí)一定要把舊的定時(shí)器清干凈。5. 真實(shí)項(xiàng)目里的推送場(chǎng)景與異常排查5.1 React WebSocket/SSE輪詢(xún)文件變化到底怎么選很多人搜“react sse/websocket 輪詢(xún)文件變化”其實(shí)想要的場(chǎng)景很清晰前端要展示文件系統(tǒng)的變化、構(gòu)建過(guò)程的狀態(tài)或者CI任務(wù)里的日志輸出。這種場(chǎng)景數(shù)據(jù)流向是服務(wù)端到前端單向首選應(yīng)該是SSE。用EventSource的好處是瀏覽器自動(dòng)重連后端斷開(kāi)時(shí)會(huì)自動(dòng)嘗試重新建立連接不需要前端寫(xiě)任何心跳邏輯。服務(wù)端往客戶(hù)端推事件時(shí)還可以帶上事件ID瀏覽器斷線(xiàn)重連后能基于ID做增量補(bǔ)發(fā)這是WebSocket方案里要自己實(shí)現(xiàn)的。const eventSource new EventSource(/api/file-change-stream); eventSource.addEventListener(file-change, (event) { const data JSON.parse(event.data); console.log(文件變化:, data.path); }); eventSource.onerror () { // 瀏覽器會(huì)自動(dòng)重連這里只需要處理UI提示 console.log(連接已斷開(kāi)瀏覽器正在重試); };如果這個(gè)頁(yè)面還需要“暫停監(jiān)聽(tīng)”“只監(jiān)聽(tīng)某個(gè)目錄”“手動(dòng)觸發(fā)一次掃描”這類(lèi)雙向控制那就改回WebSocket。因?yàn)檫@時(shí)候前端的每個(gè)控制操作都是要發(fā)給服務(wù)端的一條指令SSE沒(méi)有上行能力。React里用WebSocket有個(gè)非常經(jīng)典的坑useEffect的依賴(lài)數(shù)組導(dǎo)致事件監(jiān)聽(tīng)器拿著舊閉包。解決方法是把消息處理函數(shù)放進(jìn)useRef或者在useEffect里重新掛監(jiān)聽(tīng)的時(shí)候一并更新。function useWebSocket(url, onMessage) { const socketRef useRef(null); const onMessageRef useRef(onMessage); onMessageRef.current onMessage; useEffect(() { const socket new WebSocket(url); socketRef.current socket; socket.onmessage (event) { onMessageRef.current(event.data); }; socket.onclose () { console.log(連接關(guān)閉); }; return () socket.close(); }, [url]); return socketRef; }SSE和WebSocket邊界其實(shí)不復(fù)雜單向推送選SSE雙向交互選WebSocket輪詢(xún)留給低頻場(chǎng)景。不要因?yàn)閃ebSocket聽(tīng)起來(lái)“更實(shí)時(shí)”就盲目選它選型不是炫技是減少長(zhǎng)期維護(hù)成本。5.2 連接上了但收不到消息7個(gè)排查點(diǎn)“WebSocket連接成功但前端就是收不到消息”這個(gè)現(xiàn)象是后臺(tái)開(kāi)發(fā)里出現(xiàn)頻率極高的問(wèn)題我自己的排查順序基本是下面這張表排查點(diǎn)可能原因檢查方式連接狀態(tài)連接其實(shí)沒(méi)進(jìn)入OPEN狀態(tài)頁(yè)面誤判看readyState是否等于1服務(wù)端發(fā)送目標(biāo)消息發(fā)到了別的group或channel_name看group_send里的組名是否和group_add一致代理層緩沖Nginx/CDN緩沖了消息客戶(hù)端沒(méi)及時(shí)收到檢查反代配置里是否禁用緩沖、是否正確配置Upgrade頭前端監(jiān)聽(tīng)onmessage未注冊(cè)或被后續(xù)代碼覆蓋確認(rèn)只有一個(gè)addEventListener(message)消息幀類(lèi)型服務(wù)端發(fā)二進(jìn)制幀前端按文本解析檢查event.data的類(lèi)型Blob需要轉(zhuǎn)文本服務(wù)端并發(fā)單事件循環(huán)被阻塞消息堆積看服務(wù)端日志確認(rèn)send是否真實(shí)執(zhí)行業(yè)務(wù)側(cè)握手消息連接后必須等某條業(yè)務(wù)消息才開(kāi)始推數(shù)據(jù)抓包看首條業(yè)務(wù)消息是否已經(jīng)發(fā)出最有效的定位手段是拉一個(gè)獨(dú)立的命令行客戶(hù)端比如wscat掛同一個(gè)地址。如果wscat能收到而瀏覽器收不到問(wèn)題大概率在前端代碼如果wscat也收不到問(wèn)題就在服務(wù)端或代理層。遇到過(guò)最奇怪的一例是Nginx代理WebSocket時(shí)沒(méi)有設(shè)置proxy_read_timeout默認(rèn)60秒超時(shí)后Nginx主動(dòng)斷開(kāi)連接頁(yè)面表現(xiàn)就是“連上了一會(huì)兒之后就徹底靜默”。這種問(wèn)題從瀏覽器端看就是連接被關(guān)閉從業(yè)務(wù)日志看又沒(méi)有任何異常。排查時(shí)一定要把代理層的超時(shí)時(shí)間一并納入考慮。5.3 “通過(guò)WebSocket發(fā)送POST請(qǐng)求”到底是什么玩法這個(gè)熱詞很有意思。正常的WebSocket消息本質(zhì)上是“事件”不是“請(qǐng)求-響應(yīng)”但確實(shí)有很強(qiáng)的需求想把HTTP語(yǔ)義搬到長(zhǎng)連接里復(fù)用已有的REST接口用WebSocket統(tǒng)一進(jìn)出通道甚至解決部分受限環(huán)境下HTTP請(qǐng)求不方便的問(wèn)題。實(shí)現(xiàn)思路是在WebSocket消息里規(guī)范化封裝一個(gè)“HTTP請(qǐng)求”{ id: req-20240520-001, action: http.request, method: POST, url: /api/order, headers: { Authorization: Bearer eyJhbGciOi... }, body: { sku: A100, count: 2 } }服務(wù)端收到后解析出method、url、headers、body調(diào)用內(nèi)部HTTP API再把響應(yīng)通過(guò)WebSocket發(fā)回去。這里有個(gè)關(guān)鍵設(shè)計(jì)必須帶id因?yàn)閃ebSocket是異步的客戶(hù)端發(fā)多個(gè)請(qǐng)求時(shí)響應(yīng)可能亂序回來(lái)只有通過(guò)id才能把響應(yīng)和請(qǐng)求對(duì)上。import httpx import json async def handle_http_request(self, message): async with httpx.AsyncClient(base_urlhttps://internal.api) as client: resp await client.request( message[method], message[url], jsonmessage.get(body), headersmessage.get(headers, {}), ) await self.send(text_datajson.dumps({ id: message[id], status: resp.status_code, body: resp.text, }))這種方式看著很爽但有幾個(gè)坑要提前說(shuō)清楚。第一是不要把大文件、長(zhǎng)輪詢(xún)接口塞進(jìn)WebSocket因?yàn)橐粭l消息被卡住會(huì)阻塞這條連接后續(xù)所有消息。第二是要做好超時(shí)管理客戶(hù)端發(fā)的請(qǐng)求如果服務(wù)端遲遲不返回要有對(duì)應(yīng)的timeout和取消機(jī)制。第三是鑒權(quán)不要只依賴(lài)首條消息因?yàn)閃ebSocket連接建立之后很少重新鑒權(quán)Token有效期管理會(huì)比HTTP請(qǐng)求復(fù)雜得多。6. 項(xiàng)目中最容易翻車(chē)的地方與我的經(jīng)驗(yàn)6.1 連接數(shù)上去了一切開(kāi)始變慢長(zhǎng)連接服務(wù)和短連接服務(wù)最大的不同在于連接的生命周期。HTTP短連接處理完就釋放天然沒(méi)壓力WebSocket一旦建立就長(zhǎng)期占據(jù)一個(gè)文件描述符和一部分內(nèi)存。當(dāng)連接數(shù)超過(guò)幾千甚至上萬(wàn)的時(shí)候最先扛不住的不一定是應(yīng)用進(jìn)程而是操作系統(tǒng)的文件描述符上限和負(fù)載均衡的連接數(shù)上限。排查思路是先把ulimit -n、Nginx的worker_connections、云廠(chǎng)商負(fù)載均衡的連接數(shù)配額全查一遍。我見(jiàn)過(guò)一個(gè)項(xiàng)目線(xiàn)上突然大面積連不上最后發(fā)現(xiàn)是Nginx默認(rèn)worker_connections只有1024而前端頁(yè)面每個(gè)標(biāo)簽頁(yè)都開(kāi)了兩個(gè)WebSocket兩個(gè)標(biāo)簽頁(yè)就把一臺(tái)機(jī)器的連接額度吃完了。6.2 短連接轟炸比長(zhǎng)連接更可怕長(zhǎng)連接建立時(shí)有HTTP升級(jí)握手CPU消耗比普通HTTP請(qǐng)求高。如果前端代碼有“斷線(xiàn)立刻重連”的邏輯服務(wù)端重啟時(shí)會(huì)迎來(lái)一波重連風(fēng)暴幾千個(gè)客戶(hù)端同時(shí)發(fā)起握手瞬間把服務(wù)端CPU占滿(mǎn)結(jié)果就是服務(wù)端根本起不來(lái)形成惡性循環(huán)。應(yīng)對(duì)方法就是前面講的指數(shù)退避必須把重連間隔拉開(kāi)。哪怕只是簡(jiǎn)單的“1秒、2秒、4秒、8秒”也能把瞬時(shí)壓力攤開(kāi)。服務(wù)端側(cè)還可以加握手頻率限制對(duì)同一個(gè)IP做并發(fā)連接數(shù)限制。6.3 日志里要有“連接生命周期”不要只看收到消息排WebSocket的問(wèn)題最怕日志里只有“收到消息”沒(méi)有連接建立和關(guān)閉的記錄。后來(lái)我在所有Consumer里都會(huì)打三條日志connect時(shí)記錄channel_name、客戶(hù)端IP、連接時(shí)間disconnect時(shí)記錄close_code和在線(xiàn)時(shí)長(zhǎng)receive時(shí)記錄關(guān)鍵業(yè)務(wù)事件而不是每條心跳都打。這個(gè)習(xí)慣幫了大忙。有一次前端反饋“推送偶爾延遲”我看日志發(fā)現(xiàn)某個(gè)連接的channel_name在很長(zhǎng)一段時(shí)間內(nèi)只出現(xiàn)在disconnect里說(shuō)明它建連極短不斷重連。順著這個(gè)線(xiàn)索查下去發(fā)現(xiàn)是前端在頁(yè)面切換時(shí)沒(méi)有正確關(guān)閉舊連接。如果沒(méi)有連接生命周期的日志這個(gè)問(wèn)題可能還要排查很久。WebSocket做熟練之后你會(huì)發(fā)現(xiàn)真正的成本不在建立連接的那幾行代碼而在連接建立之后怎么維護(hù)它、怎么管理它、怎么發(fā)現(xiàn)問(wèn)題。心跳參數(shù)調(diào)一調(diào)連接生命周期記一記重連策略做做退避這些才是撐起一個(gè)穩(wěn)定長(zhǎng)連接服務(wù)的關(guān)鍵。