網(wǎng)上搜“websorket詳解”大概率是手滑把WebSocket打錯(cuò)了但點(diǎn)進(jìn)來的朋友應(yīng)該都是想搞懂這個(gè)協(xié)議到底是怎么回事。我先說結(jié)論WebSocket就是跑在TCP之上的一條全雙工通道客戶端和服務(wù)端完成一次握手之后兩邊隨時(shí)都可以往對(duì)面懟數(shù)據(jù)不用像HTTP那樣每次請(qǐng)求都重新建立連接。它解決的核心痛點(diǎn)就是——HTTP的“請(qǐng)求-響應(yīng)”模型沒法讓服務(wù)器主動(dòng)找客戶端說話而現(xiàn)實(shí)里聊天、推送、協(xié)同編輯、實(shí)時(shí)行情這類場景恰恰最需要的就是“服務(wù)器主動(dòng)開口”。這篇東西我會(huì)從協(xié)議原理講到代碼實(shí)現(xiàn)再到生產(chǎn)環(huán)境的坑適合兩種人看一是剛準(zhǔn)備做實(shí)時(shí)功能、想知道WebSocket和輪詢?cè)趺催x的小白二是用了很久但老在斷線重連、心跳?；钌显愿^的實(shí)戰(zhàn)派。1. WebSocket到底解決了什么問題1.1 從輪詢地獄到長連接在WebSocket出現(xiàn)之前想做實(shí)時(shí)功能基本就三條路短輪詢前端每隔幾秒發(fā)一次HTTP請(qǐng)求問“有消息沒”。實(shí)現(xiàn)最簡單但消息延遲取決于輪詢間隔間隔調(diào)短了服務(wù)端壓力成倍翻。我見過一個(gè)項(xiàng)目把輪詢間隔從5秒改到1秒數(shù)據(jù)庫連接池直接被打滿最后只能加機(jī)器。長輪詢請(qǐng)求發(fā)過去之后服務(wù)端先hold住有數(shù)據(jù)再返回。比短輪詢省請(qǐng)求但每個(gè)未完成的請(qǐng)求都會(huì)占用一個(gè)連接連接數(shù)上去之后網(wǎng)關(guān)和服務(wù)器都得跟著調(diào)參數(shù)而且請(qǐng)求超時(shí)、中間鏈路斷掉的問題排查起來特別累。SSEServer-Sent Events服務(wù)端單向推送瀏覽器端用EventSource就能接比WebSocket簡單但只能服務(wù)端往客戶端推客戶端想給服務(wù)端傳數(shù)據(jù)還得另開一條HTTP通道。這三條路各有各的憋屈。短輪詢的延遲和服務(wù)器負(fù)載互相矛盾長輪詢?cè)陂L連接數(shù)量大的時(shí)候?qū)Υ韺雍瓦B接池極不友好SSE又天生是半雙工。WebSocket的思路完全不一樣——它把“建立連接”和“傳輸數(shù)據(jù)”拆開先用HTTP協(xié)議完成一次升級(jí)握手然后保持這條TCP連接不關(guān)閉后續(xù)所有數(shù)據(jù)都在這條連接上雙向流動(dòng)。下面這張對(duì)比表可以直觀看到差別方案實(shí)時(shí)性服務(wù)端壓力雙向通信短輪詢?nèi)Q于間隔秒級(jí)起步高支持長輪詢有改善但仍受超時(shí)影響中高支持SSE高低不支持WebSocket毫秒級(jí)推送低支持這個(gè)設(shè)計(jì)的直接收益是通信雙方不需要再花時(shí)間在連接建立、請(qǐng)求頭解析這些重復(fù)勞動(dòng)上實(shí)時(shí)性從“秒級(jí)輪詢”直接拉到了“毫秒級(jí)推送”。同一臺(tái)服務(wù)器同樣的配置用WebSocket支撐的連接數(shù)往往是輪詢方案的數(shù)倍因?yàn)槭〉袅撕Ａ恐貜?fù)的HTTP握手開銷。1.2 協(xié)議設(shè)計(jì)的核心思路一次握手雙向通信很多人誤以為WebSocket是HTTP的升級(jí)版其實(shí)它跟HTTP是平級(jí)的關(guān)系。WebSocket握手走的是HTTP的Upgrade機(jī)制但握手完成之后協(xié)議就切換成了RFC 6455定義的獨(dú)立協(xié)議后續(xù)的幀格式、掩碼規(guī)則、控制幀這些跟HTTP沒有任何關(guān)系。那為什么非要借HTTP來握手因?yàn)閷?shí)際工程里客戶端到服務(wù)端之間往往隔著一堆基礎(chǔ)設(shè)施——負(fù)載均衡、反向代理、防火墻、網(wǎng)關(guān)。這些設(shè)施大部分只認(rèn)HTTP如果WebSocket上來就自己搞一套握手協(xié)議所有中間層都得跟著改。借道HTTP升級(jí)意味著現(xiàn)有的80/443端口、SSL證書、域名配置還有那些按HTTP路由分發(fā)請(qǐng)求的代理全部可以復(fù)用落地成本低得多。所以協(xié)議設(shè)計(jì)的核心思路就一句話用HTTP的殼完成升級(jí)用獨(dú)立協(xié)議做傳輸。這個(gè)妥協(xié)換來了巨大的工程收益也讓W(xué)ebSocket在瀏覽器、App、服務(wù)端之間幾乎成了實(shí)時(shí)通信的默認(rèn)選項(xiàng)。后面不管你用哪種語言的庫底層走的都是這套流程理解了這個(gè)思路看任何WebSocket框架的文檔都會(huì)快很多。2. 協(xié)議層的關(guān)鍵機(jī)制弄清楚這些才算真正入門2.1 握手階段到底發(fā)生了什么握手過程其實(shí)就是兩條HTTP報(bào)文但有幾個(gè)細(xì)節(jié)值得單獨(dú)摳一摳?？蛻舳税l(fā)起請(qǐng)求大致長這樣GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13注意兩個(gè)頭缺一不可Upgrade: websocket表示要升級(jí)協(xié)議Connection: Upgrade則告訴中間設(shè)備別把連接關(guān)掉。Sec-WebSocket-Key是一個(gè)隨機(jī)的Base64編碼字符串原始數(shù)據(jù)長度16字節(jié)它的作用是觸發(fā)服務(wù)端校驗(yàn)防止老式緩存代理把后續(xù)WebSocket數(shù)據(jù)錯(cuò)誤地當(dāng)HTTP響應(yīng)緩存或轉(zhuǎn)發(fā)。服務(wù)端收到之后會(huì)把這個(gè)Key拼上一個(gè)固定的魔數(shù)GUID這個(gè)字符串在RFC 6455里寫死了258EAFA5-E914-47DA-95CA-C5AB0DC85B11然后做一次SHA-1哈希再Base64編碼作為Sec-WebSocket-Accept返回HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOo這個(gè)Accept值是可以自己驗(yàn)證的別把它當(dāng)黑盒。我調(diào)試自研服務(wù)端時(shí)就經(jīng)常用Node.js的crypto先算一遍確認(rèn)自己實(shí)現(xiàn)的握手邏輯和庫的行為一致const crypto require(crypto); function computeAccept(key) { const GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11; const hash crypto.createHash(sha1); hash.update(key GUID); return hash.digest(base64); }如果你在做跨語言對(duì)接拿著客戶端發(fā)來的Sec-WebSocket-Key用這段邏輯算一遍跟服務(wù)端返回的Accept比對(duì)就知道握手到底有沒有走對(duì)。這里有一個(gè)容易忽略的工程細(xì)節(jié)握手之后原始HTTP連接就被“奪走”了不能再往這條連接上發(fā)任何HTTP響應(yīng)。有些新人在握手完成后試圖通過同一個(gè)socket返回一段JSON數(shù)據(jù)結(jié)果客戶端直接報(bào)協(xié)議錯(cuò)誤原因就是沒理解“協(xié)議切換”這件事。另外如果客戶端需要攜帶子協(xié)議標(biāo)識(shí)比如聊天走JSON、文件走二進(jìn)制可以加Sec-WebSocket-Protocol頭服務(wù)端在響應(yīng)里選一個(gè)返回這是業(yè)務(wù)層的協(xié)議協(xié)商跟前文的協(xié)議升級(jí)是兩碼事別搞混。2.2 數(shù)據(jù)幀格式一個(gè)字節(jié)一個(gè)字節(jié)拆給你看WebSocket傳輸數(shù)據(jù)的基本單位是“幀”frame。一個(gè)幀從前往后依次是FIN1 bit標(biāo)志這一幀是不是消息的最后一幀。大消息可以拆成多幀發(fā)送最后一幀的FIN置1。RSV1-3各1 bit一般不用只有協(xié)商了擴(kuò)展比如壓縮才會(huì)用到收到非0值且沒協(xié)商對(duì)應(yīng)擴(kuò)展時(shí)必須斷開連接。opcode4 bits幀類型。0x1是文本幀0x2是二進(jìn)制幀0x8是關(guān)閉幀0x9是Ping0xA是Pong。MASK1 bit客戶端發(fā)往服務(wù)端的幀這一位必須為1服務(wù)端發(fā)往客戶端的幀這一位必須為0。就這么一個(gè)不對(duì)稱規(guī)則坑了無數(shù)人。Payload length7 bits/16 bits/64 bits載荷長度。前7位小于126時(shí)就是實(shí)際長度等于126則后面2字節(jié)才是長度等于127則后面8字節(jié)才是長度。Masking key4字節(jié)MASK為1時(shí)這里帶上隨機(jī)掩碼密鑰。Payload data實(shí)際數(shù)據(jù)。其中opcode的取值是排查問題時(shí)的關(guān)鍵信息整理成表格方便對(duì)照opcode含義說明0x1文本幀載荷按UTF-8編碼0x2二進(jìn)制幀載荷原樣傳輸0x8關(guān)閉幀帶關(guān)閉碼和原因文本0x9Ping心跳探測(cè)0xAPong收到Ping后必須回復(fù)載荷原樣復(fù)制理解了幀格式最大的收獲是能看懂“為什么短字符串抓包出來幀頭挺長”——因?yàn)橐獛?字節(jié)掩碼和幀頭本身的開銷。消息越短這個(gè)固定開銷占比越明顯。實(shí)測(cè)一條5字節(jié)的消息實(shí)際線上傳輸大約是10到14字節(jié)批量發(fā)送大量短消息時(shí)這個(gè)開銷積少成多會(huì)直接影響吞吐量。2.3 掩碼規(guī)則為什么客戶端必須加掩碼而服務(wù)端不用這是很多教程一筆帶過但面試和實(shí)戰(zhàn)都愛考的點(diǎn)。RFC規(guī)定客戶端發(fā)送的幀必須設(shè)置MASK位并用隨機(jī)Masking key對(duì)載荷做掩碼服務(wù)端發(fā)送的幀則不允許設(shè)置MASK位。掩碼不是加密算法非常簡單——把載荷的每個(gè)字節(jié)與Masking key循環(huán)異或masked[i] payload[i] ^ maskingKey[i % 4]那為什么非要這樣設(shè)計(jì)核心原因是防御一種叫做“緩存投毒”cache poisoning的攻擊場景。早期WebSocket在公網(wǎng)環(huán)境可能經(jīng)過某些中間代理代理會(huì)基于HTTP語義去解析流量。如果沒有掩碼攻擊者可以通過偽造報(bào)文讓代理把一段精心構(gòu)造的HTTP響應(yīng)“緩存”下來進(jìn)而污染其他用戶拿到的內(nèi)容。加一層隨機(jī)掩碼之后代理無法可靠解析和預(yù)測(cè)數(shù)據(jù)內(nèi)容這種攻擊基本就失效了。明白這層邏輯你就知道為什么自己寫服務(wù)端時(shí)解析客戶端幀必須做“取消掩碼”而往客戶端回消息時(shí)直接明文發(fā)送即可。很多人第一次抓包發(fā)現(xiàn)客戶端發(fā)過來的數(shù)據(jù)跟實(shí)際文本對(duì)不上十有八九就是忘了處理掩碼。2.4 心跳與?；頟ing/Pong的正確姿勢(shì)TCP長連接本身不會(huì)自動(dòng)保持活躍。如果一段時(shí)間沒有數(shù)據(jù)傳輸中間的路由器、NAT網(wǎng)關(guān)、負(fù)載均衡都可能因?yàn)榭臻e超時(shí)把連接靜默回收。連接“假死”之后兩端在真正發(fā)數(shù)據(jù)之前是感知不到的于是就會(huì)出現(xiàn)“看起來連著一發(fā)消息就失敗”的詭異現(xiàn)象。WebSocket協(xié)議內(nèi)置了Ping/Pong控制幀一端發(fā)Ping另一端收到后必須回一個(gè)Pong載荷數(shù)據(jù)原樣復(fù)制。這套機(jī)制在協(xié)議層面提供了合規(guī)的探活方式應(yīng)用層只需要在合理的時(shí)間間隔內(nèi)發(fā)Ping并記錄上一次Pong回來的時(shí)間就能判斷連接是否真的活著。實(shí)際落地時(shí)心跳不是“發(fā)個(gè)Ping”這么簡單。間隔太短高頻Ping幀本身就成了不小負(fù)擔(dān)間隔太長又起不到及時(shí)發(fā)現(xiàn)問題的作用。我一般以60秒為基準(zhǔn)30秒發(fā)一個(gè)Ping連續(xù)兩次未收到Pong就主動(dòng)斷開重連。但這不是固定值需要根據(jù)你所在網(wǎng)絡(luò)環(huán)境、代理超時(shí)時(shí)間、服務(wù)端負(fù)載綜合調(diào)整具體怎么校準(zhǔn)我在第四節(jié)細(xì)講。3. 手把手搭一個(gè)完整的WebSocket服務(wù)3.1 技術(shù)選型不同語言和庫怎么選WebSocket在服務(wù)端幾乎是標(biāo)配能力各語言都有成熟庫。Node.js生態(tài)里最常見的兩個(gè)ws輕量、性能好底層就是純WebSocket實(shí)現(xiàn)沒有多余的開銷我搭內(nèi)部服務(wù)時(shí)首選它。socket.io自帶斷線重連、事件廣播、rooms等功能適合快速開發(fā)但它不是純WebSocket協(xié)議握手和數(shù)據(jù)格式都有自己的封裝真要深入調(diào)協(xié)議時(shí)會(huì)多一層黑盒。Java那邊常用Netty生態(tài)成熟Go有g(shù)orilla/websocket寫起來很舒服Python的websockets庫也不錯(cuò)。選型建議很簡單先看團(tuán)隊(duì)熟悉度再看你是想“開箱即用”還是“要掌控每一個(gè)字節(jié)”。前者選帶封裝、帶重連的庫后者選純協(xié)議實(shí)現(xiàn)。下面我用Node.js的ws庫走一遍完整流程。這套代碼我直接用在內(nèi)部消息推送服務(wù)上邏輯不復(fù)雜但很完整可以直接抄。提示如果你當(dāng)前用的框架本身帶了WebSocket支持可以先基于內(nèi)置能力跑通再考慮引入獨(dú)立庫。沒必要為了“用庫”而多加一層依賴。3.2 服務(wù)端實(shí)現(xiàn)核心步驟第一步初始化一個(gè)HttpServer掛到同一個(gè)端口上。WebSocket握手走的是HTTP Upgrade所以需要先有一個(gè)HTTP服務(wù)去接住握手請(qǐng)求再升級(jí)成WebSocket連接const http require(http); const WebSocket require(ws); const server http.createServer((req, res) { res.writeHead(200, { Content-Type: text/plain }); res.end(WebSocket server is running\n); }); const wss new WebSocket.Server({ server, path: /ws });注意path參數(shù)它規(guī)定只有訪問/ws的請(qǐng)求才會(huì)被升級(jí)其他路徑仍走普通HTTP邏輯。這個(gè)設(shè)計(jì)很方便做“HTTP WebSocket 共用一個(gè)端口”生產(chǎn)環(huán)境里一個(gè)8000端口既能提供REST接口又能提供實(shí)時(shí)通道省得再多開一個(gè)端口去應(yīng)付防火墻策略。第二步監(jiān)聽連接事件維護(hù)客戶端集合處理消息和關(guān)閉邏輯const clients new Map(); wss.on(connection, (socket, req) { const id ${Date.now()}-${Math.random().toString(16).slice(2, 8)}; clients.set(id, socket); socket.id id; socket.on(message, (data) { const text data.toString(); // 這里解析業(yè)務(wù)消息比如 { type: chat, payload: {...} } handleMessage(id, text); }); socket.on(close, () { clients.delete(id); console.log(client ${id} closed, current${clients.size}); }); socket.on(error, (err) { console.error(socket ${id} error:, err.message); }); });這里有兩個(gè)細(xì)節(jié)值得說。一是用Map而不是數(shù)組管理客戶端連接頻繁上下線時(shí)Map的增刪都是O(1)而且每個(gè)連接有獨(dú)立ID做定向推送特別方便。二是error事件一定要監(jiān)聽。Node.js的EventEmitter如果沒監(jiān)聽error一旦socket異常直接會(huì)把整個(gè)進(jìn)程帶崩這是新手最常見的翻車點(diǎn)。第三步實(shí)現(xiàn)廣播和定向推送。WebSocket本身沒有“房間”概念所有業(yè)務(wù)上的分組、私聊、群聊都是應(yīng)用層用Map、Set這些數(shù)據(jù)結(jié)構(gòu)自己維護(hù)的function broadcast(json, exceptId null) { const text JSON.stringify(json); for (const [id, socket] of clients) { if (id ! exceptId socket.readyState WebSocket.OPEN) { socket.send(text); } } } function sendTo(id, json) { const socket clients.get(id); if (socket socket.readyState WebSocket.OPEN) { socket.send(JSON.stringify(json)); } }發(fā)送前檢查readyState OPEN是必須的。TCP斷開的通知往往有延遲Map里存的連接可能已經(jīng)死亡但還沒觸發(fā)close事件不加這個(gè)判斷就會(huì)往死連接上寫數(shù)據(jù)進(jìn)而觸發(fā)error嚴(yán)重時(shí)導(dǎo)致內(nèi)存堆積。服務(wù)端寫完還要處理優(yōu)雅退出進(jìn)程收到SIGTERM時(shí)先給所有客戶端發(fā)一個(gè)關(guān)閉幀opcode 0x8并帶上規(guī)范關(guān)閉碼再關(guān)閉服務(wù)。這個(gè)細(xì)節(jié)很多人不做但做了之后客戶端重連的日志會(huì)干凈很多排錯(cuò)也更省心。3.3 客戶端接入與消息協(xié)議設(shè)計(jì)瀏覽器端幾乎不用引任何庫直接用原生WebSocket對(duì)象const ws new WebSocket(ws://localhost:8000/ws); ws.onopen () { console.log(connected); ws.send(JSON.stringify({ type: join, room: general })); }; ws.onmessage (event) { const msg JSON.parse(event.data); // 按 type 分發(fā)處理 handleMsg(msg); }; ws.onclose () { console.log(disconnected, will retry in 3s...); setTimeout(connect, 3000); };這里我要單獨(dú)強(qiáng)調(diào)“消息協(xié)議設(shè)計(jì)”。很多人直接ws.send(hello)裸發(fā)字符串demo沒問題但業(yè)務(wù)一復(fù)雜無結(jié)構(gòu)的字符串會(huì)讓服務(wù)端解析邏輯變成一個(gè)巨大的if-else沼澤改一個(gè)字段要翻半天代碼。我的習(xí)慣是統(tǒng)一用JSON封裝消息至少包含兩個(gè)字段type表示消息類型payload表示具體數(shù)據(jù)。比如聊天消息是{ type: chat, payload: { from: u1, content: hi } }心跳是{ type: ping }服務(wù)端通知是{ type: notice, payload: {...} }。前端收到消息先看type再分發(fā)后端處理也只需要一個(gè)switch新增功能時(shí)改動(dòng)的局部性很好。如果涉及二進(jìn)制傳文件、傳圖片可以用type區(qū)分文本和二進(jìn)制通道或者約定二進(jìn)制幀的第一個(gè)字節(jié)表示類型。這種做法在工程里比“協(xié)議文檔寫一套、代碼實(shí)現(xiàn)套另一套”靠譜得多因?yàn)轭愋妥侄尉驮跀?shù)據(jù)里連文檔都不用翻。4. 生產(chǎn)環(huán)境實(shí)測(cè)那些不得不踩的坑4.1 斷線重連別用定時(shí)器硬懟WebSocket連接在弱網(wǎng)、移動(dòng)網(wǎng)絡(luò)切換、服務(wù)端重啟、代理超時(shí)這些場景下斷線幾乎是必然的。生產(chǎn)環(huán)境必須實(shí)現(xiàn)斷線重連但重連不是setInterval每3秒連一次那么粗暴。無腦定時(shí)重連有兩個(gè)問題一是服務(wù)端宕機(jī)期間客戶端同時(shí)高頻重連可以把服務(wù)端“重連風(fēng)暴”打到雪崩二是客戶端重試太頻繁在弱網(wǎng)下會(huì)消耗大量電量和流量后臺(tái)掛著幾十個(gè)連接無限重試用戶手機(jī)直接發(fā)燙。我的做法是指數(shù)退避加隨機(jī)抖動(dòng)function connect(attempt 1) { const ws new WebSocket(url); ws.onclose () { const delay Math.min(30000, 1000 * Math.pow(2, attempt - 1)); const jitter Math.floor(Math.random() * 1000); setTimeout(() connect(attempt 1), delay jitter); }; }從1秒起步每次翻倍上限30秒每次加一個(gè)隨機(jī)抖動(dòng)。抖動(dòng)的意義在于打散客戶端的重連時(shí)刻避免成百上千個(gè)客戶端同時(shí)發(fā)起連接請(qǐng)求。這個(gè)策略一般項(xiàng)目直接抄就行。另外給重連設(shè)一個(gè)“冷靜期”連續(xù)重連多次后停止自動(dòng)重連提示用戶手動(dòng)刷新或點(diǎn)按鈕避免客戶端在后臺(tái)無限重試、白白耗電。4.2 心跳超時(shí)參數(shù)怎么調(diào)前面說過Ping/Pong的機(jī)制這里給一組我在實(shí)戰(zhàn)中校準(zhǔn)過的經(jīng)驗(yàn)值。服務(wù)端主動(dòng)Ping間隔建議設(shè)在30到60秒超時(shí)閾值設(shè)為間隔的2倍。比如60秒發(fā)一次Ping120秒沒收到Pong就斷開。如果服務(wù)部署在云廠商負(fù)載均衡后面一定要先查LB的空閑超時(shí)時(shí)間這個(gè)值通常在60秒左右。心跳間隔必須比它短不然LB先把連接掐了你的心跳探活反而成了擺設(shè)。我遇到過線上WebSocket每過幾分鐘就批量斷開日志全是1006最后發(fā)現(xiàn)就是心跳間隔跟LB超時(shí)卡在同一臨界點(diǎn)兩邊在打架?？蛻舳藗?cè)的心跳邏輯要更謹(jǐn)慎。移動(dòng)端App切后臺(tái)時(shí)系統(tǒng)隨時(shí)可能凍結(jié)網(wǎng)絡(luò)這時(shí)候發(fā)Ping也沒意義。有的客戶端干脆在切后臺(tái)時(shí)主動(dòng)斷開回到前臺(tái)再重連。這個(gè)策略聽起來粗暴但在移動(dòng)網(wǎng)絡(luò)下體驗(yàn)反而更好省掉了無數(shù)“假死連接”的維護(hù)成本。注意不要把Ping和業(yè)務(wù)消息混在一起。業(yè)務(wù)消息密集時(shí)確實(shí)能順帶?；畹珮I(yè)務(wù)一減少連接就裸奔了。心跳一定要用獨(dú)立的Ping/Pong幀來做。4.3 代理層、負(fù)載均衡和網(wǎng)關(guān)配置WebSocket長連接最大的敵人就是中間層的空閑超時(shí)和并發(fā)限制。我踩過的一個(gè)典型坑是服務(wù)端部署在內(nèi)網(wǎng)前端通過反向代理訪問線上跑著跑著連接就斷客戶端日志全是1006。查了半天才定位到反代默認(rèn)的空閑超時(shí)是60秒心跳間隔剛好也壓著60秒結(jié)果兩邊在臨界點(diǎn)上打架。解決辦法是把反代的proxy_read_timeout調(diào)大到比如300秒同時(shí)把心跳間隔壓到30秒。這兩個(gè)參數(shù)配合好之后斷線問題立刻消失。如果你用的是云LB同理去控制臺(tái)把“空閑超時(shí)”調(diào)到合理值同時(shí)保證心跳周期小于該值留出余量。另外還要注意HTTP/2的問題。很多反代默認(rèn)開啟HTTP/2而HTTP/2和WebSocket的兼容性在早期并不好部分老版本反代甚至不支持在HTTP/2連接上做Upgrade。遇到“客戶端能連上但升級(jí)總是失敗”的情況優(yōu)先檢查反代是不是把HTTP/2的流量劫走了需要關(guān)閉HTTP/2或?qū)ebSocket路徑做特殊處理。這個(gè)坑排查起來相當(dāng)隱蔽因?yàn)轫撁嫫渌涌谌钦５闹挥袑?shí)時(shí)通道不通。4.4 連接堆積與內(nèi)存泄漏排查WebSocket是長連接意味著每個(gè)客戶端在服務(wù)端都占著一個(gè)socket對(duì)象和對(duì)應(yīng)的網(wǎng)絡(luò)緩沖。連接數(shù)上來之后內(nèi)存和句柄數(shù)的增長是線性的管理不好很容易把服務(wù)器內(nèi)存吃爆。我排查內(nèi)存泄漏有一套固定動(dòng)作先用process.memoryUsage()或系統(tǒng)自帶的監(jiān)控工具觀察堆內(nèi)存曲線的斜率再看clients這個(gè)Map的size是不是在持續(xù)增長如果是就檢查是否有連接沒有觸發(fā)close事件。常見原因是客戶端異常斷電TCP的FIN包沒發(fā)出來服務(wù)端感知不到連接死亡只能靠心跳超時(shí)兜底。所以生產(chǎn)環(huán)境里“服務(wù)端主動(dòng)心跳 超時(shí)斷開未響應(yīng)連接”不是可選項(xiàng)而是必須項(xiàng)。每次心跳都會(huì)過濾掉一批僵尸連接Map的size才會(huì)穩(wěn)定在一個(gè)正常水位。我算過一筆賬一個(gè)僵尸連接大約占幾十KB內(nèi)存一萬條僵尸連接就能吃掉幾百M(fèi)B內(nèi)存在云服務(wù)器上這不是小數(shù)目。還有一個(gè)隱蔽問題消息發(fā)送太頻繁客戶端處理不過來網(wǎng)絡(luò)緩沖不斷堆積最后服務(wù)端發(fā)送延遲飆升。這時(shí)候需要做背壓處理——把發(fā)送操作放進(jìn)隊(duì)列當(dāng)隊(duì)列超過閾值時(shí)主動(dòng)斷開最慢的那個(gè)客戶端防止整個(gè)服務(wù)的發(fā)送延遲被拖垮。這個(gè)在消息量大的聊天室和行情推送場景里非常關(guān)鍵不做的話一個(gè)慢客戶端能把全房間的推送速度都帶下來。寫在最后WebSocket這個(gè)協(xié)議原理講起來就那些東西但真正把它用穩(wěn)靠的是工程里一個(gè)個(gè)細(xì)節(jié)。我自己的體會(huì)是先把握手和幀格式吃透遇到問題能自己抓包分析再把心跳和重連做成標(biāo)配別指望網(wǎng)絡(luò)永遠(yuǎn)可靠最后是消息協(xié)議一定要結(jié)構(gòu)化不然項(xiàng)目越改越亂。如果你正準(zhǔn)備在項(xiàng)目里上實(shí)時(shí)通信建議先別急著引入消息隊(duì)列那一套重裝備用WebSocket加一個(gè)簡單的消息分發(fā)就能覆蓋絕大多數(shù)場景。等真到了需要跨服務(wù)推送、消息持久化、多端同步的時(shí)候再考慮在WebSocket之上加一層業(yè)務(wù)消息總線那時(shí)候你會(huì)感謝當(dāng)初把協(xié)議底層搞明白的自己。最后再分享一個(gè)小技巧調(diào)試WebSocket問題抓包工具比日志好用得多因?yàn)槟隳苤苯涌吹轿帐謭?bào)錯(cuò)、幀類型、掩碼位這些底層信息?？蛻舳巳罩局桓嬖V你“斷了”抓包才能告訴你“為什么斷”。把這個(gè)習(xí)慣養(yǎng)成以后遇到再詭異的連接問題都不會(huì)慌。