戰(zhàn)：從協(xié)議原理到線上排障的完整指南)
聊到后端實(shí)時(shí)通信WebSocket 是繞不開的一個(gè)坎。很多后端同學(xué)對(duì)它的認(rèn)知停留在“用來做聊天室”“比輪詢好用”這種層面但真到了線上連接閃斷、消息丟失、集群廣播失效、鑒權(quán)怎么做、nginx 要不要配 Upgrade 頭這些問題一個(gè)接一個(gè)冒出來才會(huì)發(fā)現(xiàn)自己對(duì)它的理解其實(shí)很淺。這篇筆記不是把官方文檔抄一遍而是把我從協(xié)議細(xì)節(jié)到代碼落地、再到線上排障的完整經(jīng)驗(yàn)梳理出來適合正在學(xué)后端、準(zhǔn)備面試、或者已經(jīng)在項(xiàng)目里被 WebSocket 折磨過的朋友。1. 為什么后端要單獨(dú)研究 WebSocket1.1 HTTP 的請(qǐng)求-響應(yīng)模型在實(shí)時(shí)場(chǎng)景下的尷尬HTTP 協(xié)議是典型的“一問一答”模式客戶端發(fā)請(qǐng)求服務(wù)端給響應(yīng)一次請(qǐng)求對(duì)應(yīng)一次響應(yīng)連接用完就斷。這種模型在普通的 CRUD 接口里沒有任何問題但放到實(shí)時(shí)性要求高的場(chǎng)景里就非常別扭。舉個(gè)最常見的例子網(wǎng)頁上的未讀消息提醒。如果只用 HTTP前端只能靠輪詢Polling來解決——每隔幾秒發(fā)一個(gè)請(qǐng)求問后端“有沒有新消息”。時(shí)間間隔短了服務(wù)端壓力巨大明明沒有新消息也要硬扛一堆無效請(qǐng)求時(shí)間間隔長(zhǎng)了消息延遲高用戶那邊體驗(yàn)很差。我在早期項(xiàng)目里就做過 3 秒輪詢的推送方案一個(gè) 500 人在線的后臺(tái)系統(tǒng)光輪詢請(qǐng)求就能把 Tomcat 的線程池打到快滿而真正有意義的業(yè)務(wù)請(qǐng)求反而被擠掉了。SSEServer-Sent Events能解決一部分問題它允許服務(wù)端單向推送數(shù)據(jù)給客戶端基于 HTTP 協(xié)議實(shí)現(xiàn)不需要額外協(xié)議。但 SSE 是單向的客戶端沒法通過同一條連接向服務(wù)端持續(xù)發(fā)送數(shù)據(jù)而且瀏覽器對(duì) HTTP/1.1 下 SSE 連接數(shù)也有限制。如果業(yè)務(wù)需要客戶端和服務(wù)端頻繁雙向交互比如實(shí)時(shí)協(xié)作編輯、股票行情雙向訂閱、在線客服SSE 的局限性就暴露了。1.2 WebSocket 到底改了什么WebSocket 本質(zhì)上是在 TCP 之上建立了一條全雙工的持久通道。握手階段借用 HTTP 的 101 Switching Protocols 完成協(xié)議升級(jí)之后雙方就在同一條 TCP 連接上雙向收發(fā)數(shù)據(jù)不再有請(qǐng)求-響應(yīng)的一一對(duì)應(yīng)關(guān)系。這意味著三件事第一實(shí)時(shí)性從“秒級(jí)延遲”降低到“消息一到立刻推送”不需要客戶端反復(fù)輪詢。第二連接復(fù)用服務(wù)端可以主動(dòng)向客戶端推送數(shù)據(jù)服務(wù)器資源消耗大幅下降。第三協(xié)議本身的數(shù)據(jù)幀開銷很小一個(gè)文本幀的控制頭只有幾十比特相比 HTTP 每次請(qǐng)求都要帶一堆 Header省了太多帶寬。對(duì)后端工程師來說WebSocket 不是一個(gè)“庫(kù)”或者“框架”層面的東西而是一個(gè)需要從協(xié)議層理解的通信機(jī)制。因?yàn)榫€上問題往往不在業(yè)務(wù)代碼里而在于連接管理、心跳保活、代理層透?jìng)鳌⒓合⒙酚蛇@些基礎(chǔ)設(shè)施層面的細(xì)節(jié)。把這些搞明白了你寫出來的推送服務(wù)才是真正能上線的而不是 demo 級(jí)別。2. 協(xié)議級(jí)的關(guān)鍵點(diǎn)后端必須吃透2.1 握手不是魔法從 HTTP Upgrade 說起很多人第一次接觸 WebSocket 都會(huì)困惑為什么瀏覽器的 WebSocket API 直接填一個(gè)ws://地址就能連上感覺跟 HTTP 沒關(guān)系。實(shí)際上WebSocket 連接的第一步就是一次普通的 HTTP 請(qǐng)求只是帶上了特殊的 Upgrade 頭。我抓包看過一次完整的握手過程客戶端發(fā)出去的請(qǐng)求長(zhǎng)這樣GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13 Origin: http://example.com服務(wù)端返回HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOo這里的Sec-WebSocket-Key是客戶端生成的一個(gè)隨機(jī) Base64 字符串服務(wù)端拿到后拼上一個(gè)固定的 GUID258EAFA5-E914-47DA-95CA-C5AB0DC85B11做 SHA-1 哈希再 Base64 編碼得到Sec-WebSocket-Accept返回給客戶端。客戶端會(huì)校驗(yàn)這個(gè)值確認(rèn)服務(wù)端真的懂 WebSocket 協(xié)議。這個(gè)機(jī)制不是擺樣子它的目的是防止一些緩存代理服務(wù)器誤把 WebSocket 請(qǐng)求當(dāng)成普通 HTTP 請(qǐng)求緩存下來導(dǎo)致連接異常。后端開發(fā)如果自己實(shí)現(xiàn)協(xié)議解析這段邏輯必須完全按規(guī)范來不能偷懶。2.2 數(shù)據(jù)幀格式和掩碼規(guī)則握手完成后數(shù)據(jù)就開始以幀F(xiàn)rame的形式在連接上傳輸了。WebSocket 的幀格式要比 HTTP 報(bào)文簡(jiǎn)單得多但有一個(gè)容易踩坑的細(xì)節(jié)——掩碼。數(shù)據(jù)幀的關(guān)鍵字段分布如下FIN1 bit標(biāo)記這是不是消息的最后一幀。消息可以分多個(gè)幀發(fā)送最后一片幀上 FIN 才置 1。opcode4 bits表示幀類型。0x1文本幀0x2二進(jìn)制幀0x8關(guān)閉幀0x9Ping0xAPong。MASK1 bit掩碼標(biāo)志位。Payload length7 bits 或擴(kuò)展表示數(shù)據(jù)長(zhǎng)度小數(shù)據(jù)用 7 位不夠就擴(kuò)展到 716 位或 764 位。Masking-key4 bytes僅在 MASK 為 1 時(shí)存在。Payload data實(shí)際業(yè)務(wù)數(shù)據(jù)。協(xié)議里有一個(gè)硬性規(guī)定客戶端發(fā)送給服務(wù)端的幀必須帶掩碼MASK1服務(wù)端發(fā)送給客戶端的幀必須不帶掩碼MASK0。這個(gè)設(shè)計(jì)的初衷是防止早期瀏覽器被惡意腳本用 WebSocket 連接攻擊內(nèi)網(wǎng)服務(wù)。服務(wù)端在實(shí)現(xiàn)時(shí)如果收到客戶端未掩碼的幀應(yīng)該按協(xié)議錯(cuò)誤處理。對(duì)于后端開發(fā)來說如果是用成熟的 WebSocket 庫(kù)比如 Spring 的 WebSocket 模塊、Netty、Node.js 的 ws 庫(kù)掩碼處理已經(jīng)被底層封裝好了不手寫解析的話通常碰不到。但一旦用原生 Socket 或者做網(wǎng)關(guān)轉(zhuǎn)發(fā)就必須自己處理這一步。2.3 幀類型文本、二進(jìn)制、Ping/Pong 與關(guān)閉幀實(shí)際開發(fā)里業(yè)務(wù)數(shù)據(jù)主要用文本幀或二進(jìn)制幀。文本幀要求數(shù)據(jù)必須是合法的 UTF-8發(fā)二進(jìn)制數(shù)據(jù)比如圖片上傳、文件流就要用二進(jìn)制幀。選擇哪種取決于業(yè)務(wù)場(chǎng)景聊天消息用文本幀就夠了要傳序列化對(duì)象或者文件分片就用二進(jìn)制幀省掉 Base64 編碼帶來的 33% 體積膨脹。Ping 和 Pong 幀的作用是?；?。WebSocket 連接底層是 TCPTCP 本身雖然有心跳機(jī)制但默認(rèn)關(guān)閉且探測(cè)周期很長(zhǎng)。如果客戶端和服務(wù)端之間長(zhǎng)時(shí)間沒有數(shù)據(jù)傳輸中間經(jīng)過的 NAT 網(wǎng)關(guān)、負(fù)載均衡、防火墻設(shè)備可能會(huì)把空閑連接回收掉連接就悄悄斷了而雙方都不知道。這時(shí)候就需要應(yīng)用層心跳一端發(fā) Ping 幀另一端收到后必須回 Pong 幀。很多庫(kù)也支持直接發(fā) Pong 幀作為對(duì) Ping 的響應(yīng)。如果發(fā)了 Ping 之后在超時(shí)時(shí)間內(nèi)沒收到 Pong就可以判定連接已經(jīng)死了主動(dòng)關(guān)閉然后觸發(fā)重連邏輯。關(guān)閉幀則用于正常關(guān)閉連接。關(guān)閉時(shí)可以帶一個(gè)狀態(tài)碼和原因說明。常見狀態(tài)碼比如 1000 表示正常關(guān)閉1001 表示服務(wù)端即將關(guān)停比如應(yīng)用重啟1008 表示策略違規(guī)比如鑒權(quán)失敗。提示如果服務(wù)端在收到關(guān)閉幀之后繼續(xù)往這條連接上寫數(shù)據(jù)很可能會(huì)觸發(fā)異常。正確的流程是收到關(guān)閉幀 - 回復(fù)關(guān)閉幀 - 雙方關(guān)閉 TCP 連接 - 釋放相關(guān)資源。3. 服務(wù)端實(shí)現(xiàn)與代碼落地3.1 在 Spring Boot 里寫一個(gè) WebSocket 服務(wù)端我平時(shí)主要用 Java 技術(shù)棧Spring Boot 項(xiàng)目里集成 WebSocket 非常順手。Spring 提供了兩套方式一套是基于ServerEndpoint的 Java WebSocket 標(biāo)準(zhǔn)JSR-356實(shí)現(xiàn)另一套是 Spring 自家的WebSocketHandlerWebSocketConfigurer。兩者對(duì)比下來我的習(xí)慣是用ServerEndpoint做業(yè)務(wù)接入因?yàn)樗谔幚磉B接生命周期、消息接收、異常處理時(shí)的代碼更直觀配合ConcurrentHashMap管理會(huì)話非常清晰。先加依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency然后有一個(gè)配置類注入ServerEndpointExporterConfiguration public class WebSocketConfig { Bean public ServerEndpointExporter serverEndpointExporter() { return new ServerEndpointExporter(); } }接下來是具體的 Endpoint 類我用一個(gè)通知推送服務(wù)來做示例Component ServerEndpoint(/notice/{userId}) Slf4j public class NoticeWebSocketServer { // 會(huì)話集合key 是用戶標(biāo)識(shí)value 是 Spring 封裝的 Session private static final MapString, Session SESSION_MAP new ConcurrentHashMap(); OnOpen public void onOpen(Session session, PathParam(userId) String userId) { SESSION_MAP.put(userId, session); log.info(用戶 {} 建立連接當(dāng)前在線數(shù){}, userId, SESSION_MAP.size()); } OnClose public void onClose(PathParam(userId) String userId) { SESSION_MAP.remove(userId); log.info(用戶 {} 斷開連接當(dāng)前在線數(shù){}, userId, SESSION_MAP.size()); } OnMessage public void onMessage(String message, Session session) { // 根據(jù)業(yè)務(wù)處理客戶端發(fā)來的消息比如回復(fù)確認(rèn)、上行指令 log.info(收到來自客戶端消息{}, message); } OnError public void onError(Session session, Throwable error) { log.error(連接異常: , error); } public static void sendToUser(String userId, String message) { Session session SESSION_MAP.get(userId); if (session ! null session.isOpen()) { try { session.getBasicRemote().sendText(message); } catch (IOException e) { log.error(推送消息失敗userId: {}, userId, e); } } } }注意SESSION_MAP要支持多線程并發(fā)訪問所以用ConcurrentHashMap。因?yàn)?WebSocket 的onOpen、onMessage、onClose是在不同線程里被調(diào)用的普通的HashMap在高并發(fā)下擴(kuò)容時(shí)可能出現(xiàn)死循環(huán)或者數(shù)據(jù)錯(cuò)亂。3.2 把連接對(duì)象管起來會(huì)話管理Session對(duì)象就是服務(wù)端和某個(gè)客戶端之間的一條持久通道。管理好這些 Session是 WebSocket 后端最核心的日常操作。會(huì)話管理的核心要點(diǎn)有三個(gè)第一選擇合適的 Key。上面示例用的是userId適用于一個(gè)用戶同時(shí)只維持一個(gè)連接的場(chǎng)景。如果是同一個(gè)用戶在多端登錄手機(jī)、瀏覽器、桌面應(yīng)用一個(gè)userId對(duì)應(yīng)多個(gè) Session就要用userId 端類型做 Key或者改成userId - SetSession的結(jié)構(gòu)推送時(shí)遍歷這個(gè)集合。第二及時(shí)清理失效連接?？蛻舳酥苯訑嗑W(wǎng)、斷電是不會(huì)有正常關(guān)閉幀發(fā)過來的服務(wù)端的onClose不一定被觸發(fā)。如果不做心跳檢測(cè)SESSION_MAP里會(huì)堆積大量僵尸 Session內(nèi)存和文件描述符都會(huì)泄漏。第三推送時(shí)要檢查session.isOpen()。連接可能已經(jīng)關(guān)閉了但對(duì)象還在 Map 里直接sendText會(huì)拋IllegalStateException。先判空再檢查 isOpen這是最基本的防御。3.3 服務(wù)端主動(dòng)推送消息的正確姿勢(shì)很多項(xiàng)目會(huì)通過業(yè)務(wù)線程主動(dòng)推送比如訂單支付成功給用戶發(fā)一個(gè)站內(nèi)信通知、告警系統(tǒng)推送異常信息。這里有一個(gè)很容易犯的錯(cuò)誤直接在業(yè)務(wù)線程里調(diào)用session.getBasicRemote().sendText()。getBasicRemote()是同步發(fā)送如果網(wǎng)絡(luò)慢或者客戶端處理慢會(huì)阻塞當(dāng)前業(yè)務(wù)線程。在秒殺、告警這種高并發(fā)推送場(chǎng)景這個(gè)操作會(huì)直接影響業(yè)務(wù)接口的響應(yīng)時(shí)間。我一般用getAsyncRemote()改異步發(fā)送或者干脆封裝一層推送服務(wù)把“發(fā)送消息”和“業(yè)務(wù)處理”解耦。另外一個(gè)實(shí)戰(zhàn)技巧是不要用單條 session 的鎖來同步批量推送。最典型的問題出現(xiàn)在群發(fā)場(chǎng)景——如果按用戶維度加鎖一個(gè)用戶的連接卡頓會(huì)導(dǎo)致整個(gè)循環(huán)推送阻塞。我在上一個(gè)項(xiàng)目里就是把“往單個(gè)客戶端發(fā)消息”和“遍歷所有用戶群發(fā)”拆成兩個(gè)方法單用戶發(fā)送失敗直接捕獲異常跳過絕對(duì)不讓一個(gè)壞連接拖垮整個(gè)群發(fā)。4. 線上一定會(huì)遇到的四個(gè)問題4.1 連接不穩(wěn)定心跳與重連機(jī)制WebSocket 連接在公網(wǎng)環(huán)境下很難保持長(zhǎng)期穩(wěn)定。運(yùn)營(yíng)商 NAT 映射有超時(shí)時(shí)間公司防火墻會(huì)回收閑置連接服務(wù)端應(yīng)用重啟也會(huì)斷掉所有連接。設(shè)計(jì)一個(gè)健壯的 WebSocket 服務(wù)心跳和重連是標(biāo)配。心跳機(jī)制通常是這樣設(shè)計(jì)的服務(wù)端維護(hù)一個(gè)定時(shí)任務(wù)每隔一段時(shí)間比如 30 秒主動(dòng)向客戶端發(fā) Ping 幀同時(shí)記錄每個(gè) Session 最近一次收到消息的時(shí)間。如果連續(xù) N 次 Ping 都沒有響應(yīng)就把這個(gè) Session 標(biāo)記為超時(shí)并關(guān)閉。還有一種常見做法是客戶端主動(dòng)心跳由前端每隔一段時(shí)間發(fā)一個(gè)業(yè)務(wù)心跳包服務(wù)端收到后重置空閑計(jì)時(shí)。這兩種方案可以組合服務(wù)端 Ping 客戶端業(yè)務(wù)心跳雙保險(xiǎn)。無論哪種方案關(guān)鍵點(diǎn)是服務(wù)端必須兜底清理超時(shí)連接不能依賴客戶端主動(dòng)斷。我在第一次做的時(shí)候就把這件事想簡(jiǎn)單了只做了服務(wù)端 Ping沒做超時(shí)清理。結(jié)果線上運(yùn)行三天后堆內(nèi)存里躺著幾萬個(gè)已經(jīng)不存在的 Session 對(duì)象連接數(shù)飆升到服務(wù)端文件描述符上限整個(gè)應(yīng)用直接拒連接。從那以后我所有的 WebSocket 服務(wù)都強(qiáng)制加超時(shí)清理邏輯。前端那邊的重連也很有講究。最簡(jiǎn)單的方案是斷線后固定延遲重連但服務(wù)端發(fā)布重啟時(shí)成百上千的客戶端會(huì)同時(shí)發(fā)起重連造成“驚群效應(yīng)”——服務(wù)端剛啟動(dòng)就被一輪重連請(qǐng)求打掛。我建議前端做指數(shù)退避重連從 1 秒開始每次失敗翻倍最長(zhǎng)不超過 30 秒并且加上隨機(jī)抖動(dòng)jitter避免客戶端的重連請(qǐng)求在同一時(shí)刻爆發(fā)。4.2 鑒權(quán)怎么做token 帶在哪WebSocket 握手走的是 HTTP所以鑒權(quán)理論上可以在握手階段完成。但 WebSocket API 在瀏覽器里有一個(gè)限制無法自定義 Header。new WebSocket(url)只能設(shè)置 URL 和協(xié)議列表不能像fetch那樣手動(dòng)帶Authorization頭。因此常用方案有三種方案一token 放進(jìn) URL Query 參數(shù)。比如ws://localhost:8080/notice/1001?tokenabc123。實(shí)現(xiàn)簡(jiǎn)單但 token 會(huì)出現(xiàn)在日志、瀏覽器歷史、反向代理的 access log 里有泄露風(fēng)險(xiǎn)務(wù)必做好日志脫敏。方案二token 放到子協(xié)議Subprotocol里。在握手時(shí)用Sec-WebSocket-Protocol字段攜帶 token服務(wù)端從 header 里取出來校驗(yàn)。這種方式相對(duì)隱蔽但協(xié)議本意是標(biāo)記應(yīng)用層協(xié)議拿它傳 token 屬于“擦邊球”需要團(tuán)隊(duì)統(tǒng)一約定。方案三先通過 HTTP 接口換取一次性票據(jù)再在握手時(shí)通過 Query 參數(shù)提交服務(wù)端校驗(yàn)通過后立即失效。適合對(duì)安全要求高的場(chǎng)景。我個(gè)人最常用的組合是token 放 Query 參數(shù) 服務(wù)端攔截器校驗(yàn) 對(duì)日志做脫敏處理。校驗(yàn)放在握手階段有一個(gè)巨大的好處——失敗的連接根本不會(huì)被OnOpen接收避免非法連接占用資源。4.3 多實(shí)例部署消息怎么廣播WebSocket 的連接是有狀態(tài)的Session 綁定在某個(gè)實(shí)例上。一旦服務(wù)做水平擴(kuò)容部署了多個(gè)實(shí)例用戶 A 連接在實(shí)例 1用戶 B 連接在實(shí)例 2A 要給 B 發(fā)消息直接遍歷本地 SESSION_MAP 根本找不到 B。解決思路不是讓每個(gè)實(shí)例共享 Session而是引入一個(gè)消息路由層。最經(jīng)典的做法是基于 Redis 的發(fā)布訂閱Pub/Sub實(shí)例 1 收到 A 的消息后把消息發(fā)到 Redis 的指定 Channel所有訂閱了這個(gè) Channel 的實(shí)例都能收到再由持有目標(biāo) Session 的實(shí)例完成推送。核心邏輯大致如下// 推送入口 public void pushMessage(String targetUserId, String message) { // 1. 先查本地 Session 是否存在 if (SESSION_MAP.containsKey(targetUserId)) { sendToLocalUser(targetUserId, message); return; } // 2. 本地不存在通過 Redis Pub/Sub 廣播出去 redisTemplate.convertAndSend(ws:notice, targetUserId : message); } // Redis 消息監(jiān)聽器里接收并處理 public void onMessage(String payload) { String[] parts payload.split(:, 2); String targetUserId parts[0]; String message parts[1]; // 消息可能是發(fā)給本實(shí)例的也可能是發(fā)給其他實(shí)例的統(tǒng)一走本地發(fā)送邏輯 if (SESSION_MAP.containsKey(targetUserId)) { sendToLocalUser(targetUserId, message); } }這樣每個(gè)實(shí)例只需要維護(hù)自己的本地 SESSION_MAP跨實(shí)例的消息通過 Redis 中轉(zhuǎn)。要注意的是Redis Pub/Sub 的消息是即發(fā)即棄的如果某個(gè)實(shí)例當(dāng)時(shí)不在線消息就丟了。對(duì)推送可靠性要求更高的場(chǎng)景可以考慮用 Redis Stream、RocketMQ 這類帶持久化的消息隊(duì)列從“訂閱推送”演進(jìn)為“先存儲(chǔ)后投遞”。還有一種方案是引入專門的網(wǎng)關(guān)層所有 WebSocket 連接都掛在網(wǎng)關(guān)層業(yè)務(wù)后端不直接持有連接網(wǎng)關(guān)負(fù)責(zé)把消息路由到目標(biāo)客戶端。這種架構(gòu)更徹底但實(shí)現(xiàn)成本也更高適合體量更大、微服務(wù)劃分更細(xì)的團(tuán)隊(duì)。4.4 網(wǎng)關(guān)/代理層nginx 配置與連接超時(shí)WebSocket 服務(wù)前面幾乎都會(huì)加一層 nginx 做負(fù)載均衡和域名轉(zhuǎn)發(fā)。nginx 默認(rèn)配置對(duì) WebSocket 并不友好因?yàn)樗枰С?HTTP 升級(jí)。在我的服務(wù)器上一個(gè)可用的 location 配置是這樣的map $http_upgrade $connection_upgrade { default upgrade; close; } upstream ws_backend { server 127.0.0.1:8080; server 127.0.0.1:8081; # 開啟長(zhǎng)連接復(fù)用避免每次握手都新建后端連接 keepalive 32; } server { listen 80; server_name ws.example.com; location /notice { proxy_pass http://ws_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 關(guān)鍵如果 60 秒內(nèi)沒有數(shù)據(jù)交互nginx 會(huì)主動(dòng)斷開連接 proxy_read_timeout 3600s; proxy_send_timeout 3600s; } }上面配置里有幾個(gè)坑都是我實(shí)際踩過的proxy_set_header Connection $connection_upgrade是必須的如果寫成固定的upgrade普通 HTTP 請(qǐng)求也會(huì)被當(dāng)作升級(jí)請(qǐng)求處理導(dǎo)致靜態(tài)資源接口異常。用map做動(dòng)態(tài)映射是最穩(wěn)妥的方式。proxy_read_timeout默認(rèn)是 60 秒如果不調(diào)大當(dāng)客戶端和服務(wù)端之間剛好沒有數(shù)據(jù)交換超過 60 秒nginx 就會(huì)先斷開連接?？蛻舳撕蛻?yīng)用層心跳的數(shù)據(jù)能覆蓋這個(gè)超時(shí)時(shí)間但保險(xiǎn)起見我會(huì)把超時(shí)時(shí)間設(shè)置為心跳間隔的好幾倍。另外負(fù)載均衡算法默認(rèn)是輪詢但 WebSocket 連接一旦建立后續(xù)幀都走同一條 TCP 連接所以 nginx 層不需要做會(huì)話保持sticky session只要保證握手中的 Upgrade 請(qǐng)求被轉(zhuǎn)發(fā)到正確后端即可之后的流量都跟著連接走。5. 常見問題與排查技巧實(shí)錄5.1 連接一打開就斷瀏覽器報(bào) 10061006 是 WebSocket 里最讓人頭疼的錯(cuò)誤碼因?yàn)樗恰斑B接非正常關(guān)閉”的統(tǒng)稱瀏覽器不會(huì)給任何具體原因。服務(wù)端日志和瀏覽器 Network 面板往往都沒有有效信息。我遇到這個(gè)問題的排查順序一般是這樣的第一步確認(rèn)握手是否成功。在瀏覽器 Network 面板看 WebSocket 那條請(qǐng)求的 Status Code 是不是 101。如果不是 101說明代理層或后端沒有正確返回升級(jí)響應(yīng)大概率是 nginx 配置少了 Upgrade 頭。第二步確認(rèn)服務(wù)端有沒有在握手之后立刻關(guān)閉連接。常見原因是鑒權(quán)失敗、Session 為空返回了異常。在OnOpen里處理完邏輯后打一條日志確認(rèn)連接是否真的注冊(cè)成功。第三步排查是不是代理層提前斷開了。如果前面有 nginx 或者云負(fù)載均衡先跳過它直連后端測(cè)試。直連沒問題就把焦點(diǎn)放到代理層配置上。第四步看服務(wù)端進(jìn)程是不是有 GC 停頓或者線程阻塞。Full GC 如果造成長(zhǎng)時(shí)間 Stop The World也會(huì)觸發(fā)底層 TCP 超時(shí)表現(xiàn)出來就是 1006。5.2 服務(wù)端消息推送不出去代碼里明明調(diào)用了sendText沒有拋異常但客戶端就是收不到。這種“靜默失敗”比報(bào)錯(cuò)更煩人。根據(jù)我的經(jīng)驗(yàn)先查session.isOpen()。如果連接已經(jīng)斷了但狀態(tài)沒來得及更新發(fā)送接口可能不報(bào)錯(cuò)消息卻發(fā)不出去。其次是檢查是否用了同一個(gè)BasicRemote實(shí)例在多個(gè)線程里同時(shí)發(fā)送。WebSocket 協(xié)議要求同一個(gè)連接的數(shù)據(jù)幀必須串行發(fā)送多個(gè)線程同時(shí)寫會(huì)導(dǎo)致數(shù)據(jù)幀交錯(cuò)發(fā)送接口會(huì)拋異?；蛘呦⒈粊G棄。正確的做法是把發(fā)送操作統(tǒng)一收口到一個(gè)方法里加鎖保證同一時(shí)刻只有一個(gè)線程在寫。在 Netty 或者 Spring 底層同一條連接本身是不允許并發(fā)寫的框架會(huì)在高并發(fā)下觸發(fā)異常。5.3 連接數(shù)持續(xù)增長(zhǎng)內(nèi)存和句柄被吃光這個(gè)問題幾乎每個(gè)做 WebSocket 的人都會(huì)遇到?，F(xiàn)象是線上連接數(shù)一直漲不下降最后服務(wù)端報(bào) “Too many open files” 或者堆內(nèi)存耗盡。原因大多是兩類。一類是客戶端異常斷開拔網(wǎng)線、App 閃退沒有發(fā)關(guān)閉幀服務(wù)端的onClose沒有被調(diào)用Session 一直留在 Map 里。另一類是服務(wù)端業(yè)務(wù)代碼持有 Session 引用即使底層連接已經(jīng)關(guān)閉對(duì)象仍然無法被 GC。方案只有一個(gè)也是最有效的一個(gè)定時(shí)清理。寫一個(gè)定時(shí)任務(wù)每隔一段時(shí)間遍歷SESSION_MAP檢查每個(gè) Session 的最后活動(dòng)時(shí)間。如果超過設(shè)定閾值比如 90 秒沒有收到任何幀就主動(dòng)調(diào)用session.close()并從 Map 中移除。需要注意的是清理任務(wù)本身就是對(duì)宿主機(jī)資源的消耗幾千個(gè)連接還好幾萬個(gè)連接的時(shí)候ConcurrentHashMap的遍歷也會(huì)帶來線程競(jìng)爭(zhēng)。我現(xiàn)在的做法是把 Session 按時(shí)間分桶存放清理時(shí)只掃最近超時(shí)的桶而不是全量掃描。5.4 谷歌瀏覽器高版本無法啟用 WebSocket有不少人遇到這類問題高版本瀏覽器里 WebSocket 連接始終建立不起來控制臺(tái)報(bào)錯(cuò)信息又很模糊。首先要澄清一點(diǎn)現(xiàn)代主流瀏覽器對(duì) WebSocket 的支持是非常成熟的不需要“啟用”什么開關(guān)。所謂“無法啟用”絕大多數(shù)情況下是頁面代碼把ws://和wss://寫錯(cuò)了。如果頁面是 HTTPS 環(huán)境瀏覽器會(huì)強(qiáng)制要求 WebSocket 使用 TLS 加密也就是wss://協(xié)議。如果用ws://瀏覽器會(huì)直接拒絕連接報(bào)錯(cuò)內(nèi)容可能只是WebSocket connection failed。開發(fā)環(huán)境用 HTTP 就配ws://生產(chǎn)環(huán)境只要上了 HTTPS就必須對(duì)應(yīng)改成wss://并且 nginx 層要配置 SSL 證書和代理。另外瀏覽器對(duì) WebSocket 連接數(shù)也有限制。HTTP/1.1 下單個(gè)域名最多 6 條并發(fā)連接如果頁面里同時(shí)開了多個(gè) WebSocket超出的連接會(huì)排隊(duì)甚至失敗。高版本瀏覽器在 HTTP/2 下的連接限制略有放寬但多路復(fù)用對(duì) WebSocket 的支持并不完美仍然建議控制同頁面的連接數(shù)量。5.5 常見問題速查表現(xiàn)象常見原因處理優(yōu)先級(jí)連接一直無法建立協(xié)議前綴錯(cuò)誤、nginx 沒配 Upgrade、端口不通先查 nginx 配置和瀏覽器 Network連接建立后秒斷報(bào) 1006鑒權(quán)失敗、代理層超時(shí)、后端異常關(guān)閉服務(wù)端日志 直連測(cè)試客戶端收不到推送Session 已失效、多線程并發(fā)寫、代理層緩沖檢查 isOpen、統(tǒng)一收口發(fā)送連接數(shù)只增不減沒有心跳清理、onClose 未觸發(fā)增加定時(shí)清理任務(wù)后端多實(shí)例時(shí)消息不互通缺少消息路由層引入 Redis Pub/Sub 或消息隊(duì)列服務(wù)端 CPU 飆升心跳頻繁、全量掃描 Session、同步阻塞發(fā)送優(yōu)化心跳策略、異步發(fā)送把這些場(chǎng)景都過一遍之后再回頭看 WebSocket會(huì)發(fā)現(xiàn)它其實(shí)就是一個(gè)“長(zhǎng)連接 幀協(xié)議 連接管理”的組合體。協(xié)議本身不復(fù)雜復(fù)雜的是把它放進(jìn)真實(shí)系統(tǒng)里的各種約束。我在最初學(xué)習(xí)的時(shí)候總想著把協(xié)議背熟、代碼寫好就萬事大吉后來發(fā)現(xiàn)真正拉開差距的是連接斷沒斷、消息丟沒丟、服務(wù)掛沒掛這幾個(gè)在生產(chǎn)環(huán)境逃不掉的工程問題?，F(xiàn)在手邊每一個(gè) WebSocket 項(xiàng)目我上手第一件事就是先問清楚心跳怎么做、斷線重連怎么設(shè)計(jì)、集群節(jié)點(diǎn)掛了消息怎么兜底這比磨任何框架 API 都重要。 WebSocket后端實(shí)戰(zhàn)：從協(xié)議原理到線上排障的完整指南
聊到后端實(shí)時(shí)通信WebSocket 是繞不開的一個(gè)坎。很多后端同學(xué)對(duì)它的認(rèn)知停留在“用來做聊天室”“比輪詢好用”這種層面但真到了線上連接閃斷、消息丟失、集群廣播失效、鑒權(quán)怎么做、nginx 要不要配 Upgrade 頭這些問題一個(gè)接一個(gè)冒出來才會(huì)發(fā)現(xiàn)自己對(duì)它的理解其實(shí)很淺。這篇筆記不是把官方文檔抄一遍而是把我從協(xié)議細(xì)節(jié)到代碼落地、再到線上排障的完整經(jīng)驗(yàn)梳理出來適合正在學(xué)后端、準(zhǔn)備面試、或者已經(jīng)在項(xiàng)目里被 WebSocket 折磨過的朋友。1. 為什么后端要單獨(dú)研究 WebSocket1.1 HTTP 的請(qǐng)求-響應(yīng)模型在實(shí)時(shí)場(chǎng)景下的尷尬HTTP 協(xié)議是典型的“一問一答”模式客戶端發(fā)請(qǐng)求服務(wù)端給響應(yīng)一次請(qǐng)求對(duì)應(yīng)一次響應(yīng)連接用完就斷。這種模型在普通的 CRUD 接口里沒有任何問題但放到實(shí)時(shí)性要求高的場(chǎng)景里就非常別扭。舉個(gè)最常見的例子網(wǎng)頁上的未讀消息提醒。如果只用 HTTP前端只能靠輪詢Polling來解決——每隔幾秒發(fā)一個(gè)請(qǐng)求問后端“有沒有新消息”。時(shí)間間隔短了服務(wù)端壓力巨大明明沒有新消息也要硬扛一堆無效請(qǐng)求時(shí)間間隔長(zhǎng)了消息延遲高用戶那邊體驗(yàn)很差。我在早期項(xiàng)目里就做過 3 秒輪詢的推送方案一個(gè) 500 人在線的后臺(tái)系統(tǒng)光輪詢請(qǐng)求就能把 Tomcat 的線程池打到快滿而真正有意義的業(yè)務(wù)請(qǐng)求反而被擠掉了。SSEServer-Sent Events能解決一部分問題它允許服務(wù)端單向推送數(shù)據(jù)給客戶端基于 HTTP 協(xié)議實(shí)現(xiàn)不需要額外協(xié)議。但 SSE 是單向的客戶端沒法通過同一條連接向服務(wù)端持續(xù)發(fā)送數(shù)據(jù)而且瀏覽器對(duì) HTTP/1.1 下 SSE 連接數(shù)也有限制。如果業(yè)務(wù)需要客戶端和服務(wù)端頻繁雙向交互比如實(shí)時(shí)協(xié)作編輯、股票行情雙向訂閱、在線客服SSE 的局限性就暴露了。1.2 WebSocket 到底改了什么WebSocket 本質(zhì)上是在 TCP 之上建立了一條全雙工的持久通道。握手階段借用 HTTP 的 101 Switching Protocols 完成協(xié)議升級(jí)之后雙方就在同一條 TCP 連接上雙向收發(fā)數(shù)據(jù)不再有請(qǐng)求-響應(yīng)的一一對(duì)應(yīng)關(guān)系。這意味著三件事第一實(shí)時(shí)性從“秒級(jí)延遲”降低到“消息一到立刻推送”不需要客戶端反復(fù)輪詢。第二連接復(fù)用服務(wù)端可以主動(dòng)向客戶端推送數(shù)據(jù)服務(wù)器資源消耗大幅下降。第三協(xié)議本身的數(shù)據(jù)幀開銷很小一個(gè)文本幀的控制頭只有幾十比特相比 HTTP 每次請(qǐng)求都要帶一堆 Header省了太多帶寬。對(duì)后端工程師來說WebSocket 不是一個(gè)“庫(kù)”或者“框架”層面的東西而是一個(gè)需要從協(xié)議層理解的通信機(jī)制。因?yàn)榫€上問題往往不在業(yè)務(wù)代碼里而在于連接管理、心跳保活、代理層透?jìng)鳌⒓合⒙酚蛇@些基礎(chǔ)設(shè)施層面的細(xì)節(jié)。把這些搞明白了你寫出來的推送服務(wù)才是真正能上線的而不是 demo 級(jí)別。2. 協(xié)議級(jí)的關(guān)鍵點(diǎn)后端必須吃透2.1 握手不是魔法從 HTTP Upgrade 說起很多人第一次接觸 WebSocket 都會(huì)困惑為什么瀏覽器的 WebSocket API 直接填一個(gè)ws://地址就能連上感覺跟 HTTP 沒關(guān)系。實(shí)際上WebSocket 連接的第一步就是一次普通的 HTTP 請(qǐng)求只是帶上了特殊的 Upgrade 頭。我抓包看過一次完整的握手過程客戶端發(fā)出去的請(qǐng)求長(zhǎng)這樣GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13 Origin: http://example.com服務(wù)端返回HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOo這里的Sec-WebSocket-Key是客戶端生成的一個(gè)隨機(jī) Base64 字符串服務(wù)端拿到后拼上一個(gè)固定的 GUID258EAFA5-E914-47DA-95CA-C5AB0DC85B11做 SHA-1 哈希再 Base64 編碼得到Sec-WebSocket-Accept返回給客戶端。客戶端會(huì)校驗(yàn)這個(gè)值確認(rèn)服務(wù)端真的懂 WebSocket 協(xié)議。這個(gè)機(jī)制不是擺樣子它的目的是防止一些緩存代理服務(wù)器誤把 WebSocket 請(qǐng)求當(dāng)成普通 HTTP 請(qǐng)求緩存下來導(dǎo)致連接異常。后端開發(fā)如果自己實(shí)現(xiàn)協(xié)議解析這段邏輯必須完全按規(guī)范來不能偷懶。2.2 數(shù)據(jù)幀格式和掩碼規(guī)則握手完成后數(shù)據(jù)就開始以幀F(xiàn)rame的形式在連接上傳輸了。WebSocket 的幀格式要比 HTTP 報(bào)文簡(jiǎn)單得多但有一個(gè)容易踩坑的細(xì)節(jié)——掩碼。數(shù)據(jù)幀的關(guān)鍵字段分布如下FIN1 bit標(biāo)記這是不是消息的最后一幀。消息可以分多個(gè)幀發(fā)送最后一片幀上 FIN 才置 1。opcode4 bits表示幀類型。0x1文本幀0x2二進(jìn)制幀0x8關(guān)閉幀0x9Ping0xAPong。MASK1 bit掩碼標(biāo)志位。Payload length7 bits 或擴(kuò)展表示數(shù)據(jù)長(zhǎng)度小數(shù)據(jù)用 7 位不夠就擴(kuò)展到 716 位或 764 位。Masking-key4 bytes僅在 MASK 為 1 時(shí)存在。Payload data實(shí)際業(yè)務(wù)數(shù)據(jù)。協(xié)議里有一個(gè)硬性規(guī)定客戶端發(fā)送給服務(wù)端的幀必須帶掩碼MASK1服務(wù)端發(fā)送給客戶端的幀必須不帶掩碼MASK0。這個(gè)設(shè)計(jì)的初衷是防止早期瀏覽器被惡意腳本用 WebSocket 連接攻擊內(nèi)網(wǎng)服務(wù)。服務(wù)端在實(shí)現(xiàn)時(shí)如果收到客戶端未掩碼的幀應(yīng)該按協(xié)議錯(cuò)誤處理。對(duì)于后端開發(fā)來說如果是用成熟的 WebSocket 庫(kù)比如 Spring 的 WebSocket 模塊、Netty、Node.js 的 ws 庫(kù)掩碼處理已經(jīng)被底層封裝好了不手寫解析的話通常碰不到。但一旦用原生 Socket 或者做網(wǎng)關(guān)轉(zhuǎn)發(fā)就必須自己處理這一步。2.3 幀類型文本、二進(jìn)制、Ping/Pong 與關(guān)閉幀實(shí)際開發(fā)里業(yè)務(wù)數(shù)據(jù)主要用文本幀或二進(jìn)制幀。文本幀要求數(shù)據(jù)必須是合法的 UTF-8發(fā)二進(jìn)制數(shù)據(jù)比如圖片上傳、文件流就要用二進(jìn)制幀。選擇哪種取決于業(yè)務(wù)場(chǎng)景聊天消息用文本幀就夠了要傳序列化對(duì)象或者文件分片就用二進(jìn)制幀省掉 Base64 編碼帶來的 33% 體積膨脹。Ping 和 Pong 幀的作用是?；?。WebSocket 連接底層是 TCPTCP 本身雖然有心跳機(jī)制但默認(rèn)關(guān)閉且探測(cè)周期很長(zhǎng)。如果客戶端和服務(wù)端之間長(zhǎng)時(shí)間沒有數(shù)據(jù)傳輸中間經(jīng)過的 NAT 網(wǎng)關(guān)、負(fù)載均衡、防火墻設(shè)備可能會(huì)把空閑連接回收掉連接就悄悄斷了而雙方都不知道。這時(shí)候就需要應(yīng)用層心跳一端發(fā) Ping 幀另一端收到后必須回 Pong 幀。很多庫(kù)也支持直接發(fā) Pong 幀作為對(duì) Ping 的響應(yīng)。如果發(fā)了 Ping 之后在超時(shí)時(shí)間內(nèi)沒收到 Pong就可以判定連接已經(jīng)死了主動(dòng)關(guān)閉然后觸發(fā)重連邏輯。關(guān)閉幀則用于正常關(guān)閉連接。關(guān)閉時(shí)可以帶一個(gè)狀態(tài)碼和原因說明。常見狀態(tài)碼比如 1000 表示正常關(guān)閉1001 表示服務(wù)端即將關(guān)停比如應(yīng)用重啟1008 表示策略違規(guī)比如鑒權(quán)失敗。提示如果服務(wù)端在收到關(guān)閉幀之后繼續(xù)往這條連接上寫數(shù)據(jù)很可能會(huì)觸發(fā)異常。正確的流程是收到關(guān)閉幀 - 回復(fù)關(guān)閉幀 - 雙方關(guān)閉 TCP 連接 - 釋放相關(guān)資源。3. 服務(wù)端實(shí)現(xiàn)與代碼落地3.1 在 Spring Boot 里寫一個(gè) WebSocket 服務(wù)端我平時(shí)主要用 Java 技術(shù)棧Spring Boot 項(xiàng)目里集成 WebSocket 非常順手。Spring 提供了兩套方式一套是基于ServerEndpoint的 Java WebSocket 標(biāo)準(zhǔn)JSR-356實(shí)現(xiàn)另一套是 Spring 自家的WebSocketHandlerWebSocketConfigurer。兩者對(duì)比下來我的習(xí)慣是用ServerEndpoint做業(yè)務(wù)接入因?yàn)樗谔幚磉B接生命周期、消息接收、異常處理時(shí)的代碼更直觀配合ConcurrentHashMap管理會(huì)話非常清晰。先加依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency然后有一個(gè)配置類注入ServerEndpointExporterConfiguration public class WebSocketConfig { Bean public ServerEndpointExporter serverEndpointExporter() { return new ServerEndpointExporter(); } }接下來是具體的 Endpoint 類我用一個(gè)通知推送服務(wù)來做示例Component ServerEndpoint(/notice/{userId}) Slf4j public class NoticeWebSocketServer { // 會(huì)話集合key 是用戶標(biāo)識(shí)value 是 Spring 封裝的 Session private static final MapString, Session SESSION_MAP new ConcurrentHashMap(); OnOpen public void onOpen(Session session, PathParam(userId) String userId) { SESSION_MAP.put(userId, session); log.info(用戶 {} 建立連接當(dāng)前在線數(shù){}, userId, SESSION_MAP.size()); } OnClose public void onClose(PathParam(userId) String userId) { SESSION_MAP.remove(userId); log.info(用戶 {} 斷開連接當(dāng)前在線數(shù){}, userId, SESSION_MAP.size()); } OnMessage public void onMessage(String message, Session session) { // 根據(jù)業(yè)務(wù)處理客戶端發(fā)來的消息比如回復(fù)確認(rèn)、上行指令 log.info(收到來自客戶端消息{}, message); } OnError public void onError(Session session, Throwable error) { log.error(連接異常: , error); } public static void sendToUser(String userId, String message) { Session session SESSION_MAP.get(userId); if (session ! null session.isOpen()) { try { session.getBasicRemote().sendText(message); } catch (IOException e) { log.error(推送消息失敗userId: {}, userId, e); } } } }注意SESSION_MAP要支持多線程并發(fā)訪問所以用ConcurrentHashMap。因?yàn)?WebSocket 的onOpen、onMessage、onClose是在不同線程里被調(diào)用的普通的HashMap在高并發(fā)下擴(kuò)容時(shí)可能出現(xiàn)死循環(huán)或者數(shù)據(jù)錯(cuò)亂。3.2 把連接對(duì)象管起來會(huì)話管理Session對(duì)象就是服務(wù)端和某個(gè)客戶端之間的一條持久通道。管理好這些 Session是 WebSocket 后端最核心的日常操作。會(huì)話管理的核心要點(diǎn)有三個(gè)第一選擇合適的 Key。上面示例用的是userId適用于一個(gè)用戶同時(shí)只維持一個(gè)連接的場(chǎng)景。如果是同一個(gè)用戶在多端登錄手機(jī)、瀏覽器、桌面應(yīng)用一個(gè)userId對(duì)應(yīng)多個(gè) Session就要用userId 端類型做 Key或者改成userId - SetSession的結(jié)構(gòu)推送時(shí)遍歷這個(gè)集合。第二及時(shí)清理失效連接?？蛻舳酥苯訑嗑W(wǎng)、斷電是不會(huì)有正常關(guān)閉幀發(fā)過來的服務(wù)端的onClose不一定被觸發(fā)。如果不做心跳檢測(cè)SESSION_MAP里會(huì)堆積大量僵尸 Session內(nèi)存和文件描述符都會(huì)泄漏。第三推送時(shí)要檢查session.isOpen()。連接可能已經(jīng)關(guān)閉了但對(duì)象還在 Map 里直接sendText會(huì)拋IllegalStateException。先判空再檢查 isOpen這是最基本的防御。3.3 服務(wù)端主動(dòng)推送消息的正確姿勢(shì)很多項(xiàng)目會(huì)通過業(yè)務(wù)線程主動(dòng)推送比如訂單支付成功給用戶發(fā)一個(gè)站內(nèi)信通知、告警系統(tǒng)推送異常信息。這里有一個(gè)很容易犯的錯(cuò)誤直接在業(yè)務(wù)線程里調(diào)用session.getBasicRemote().sendText()。getBasicRemote()是同步發(fā)送如果網(wǎng)絡(luò)慢或者客戶端處理慢會(huì)阻塞當(dāng)前業(yè)務(wù)線程。在秒殺、告警這種高并發(fā)推送場(chǎng)景這個(gè)操作會(huì)直接影響業(yè)務(wù)接口的響應(yīng)時(shí)間。我一般用getAsyncRemote()改異步發(fā)送或者干脆封裝一層推送服務(wù)把“發(fā)送消息”和“業(yè)務(wù)處理”解耦。另外一個(gè)實(shí)戰(zhàn)技巧是不要用單條 session 的鎖來同步批量推送。最典型的問題出現(xiàn)在群發(fā)場(chǎng)景——如果按用戶維度加鎖一個(gè)用戶的連接卡頓會(huì)導(dǎo)致整個(gè)循環(huán)推送阻塞。我在上一個(gè)項(xiàng)目里就是把“往單個(gè)客戶端發(fā)消息”和“遍歷所有用戶群發(fā)”拆成兩個(gè)方法單用戶發(fā)送失敗直接捕獲異常跳過絕對(duì)不讓一個(gè)壞連接拖垮整個(gè)群發(fā)。4. 線上一定會(huì)遇到的四個(gè)問題4.1 連接不穩(wěn)定心跳與重連機(jī)制WebSocket 連接在公網(wǎng)環(huán)境下很難保持長(zhǎng)期穩(wěn)定。運(yùn)營(yíng)商 NAT 映射有超時(shí)時(shí)間公司防火墻會(huì)回收閑置連接服務(wù)端應(yīng)用重啟也會(huì)斷掉所有連接。設(shè)計(jì)一個(gè)健壯的 WebSocket 服務(wù)心跳和重連是標(biāo)配。心跳機(jī)制通常是這樣設(shè)計(jì)的服務(wù)端維護(hù)一個(gè)定時(shí)任務(wù)每隔一段時(shí)間比如 30 秒主動(dòng)向客戶端發(fā) Ping 幀同時(shí)記錄每個(gè) Session 最近一次收到消息的時(shí)間。如果連續(xù) N 次 Ping 都沒有響應(yīng)就把這個(gè) Session 標(biāo)記為超時(shí)并關(guān)閉。還有一種常見做法是客戶端主動(dòng)心跳由前端每隔一段時(shí)間發(fā)一個(gè)業(yè)務(wù)心跳包服務(wù)端收到后重置空閑計(jì)時(shí)。這兩種方案可以組合服務(wù)端 Ping 客戶端業(yè)務(wù)心跳雙保險(xiǎn)。無論哪種方案關(guān)鍵點(diǎn)是服務(wù)端必須兜底清理超時(shí)連接不能依賴客戶端主動(dòng)斷。我在第一次做的時(shí)候就把這件事想簡(jiǎn)單了只做了服務(wù)端 Ping沒做超時(shí)清理。結(jié)果線上運(yùn)行三天后堆內(nèi)存里躺著幾萬個(gè)已經(jīng)不存在的 Session 對(duì)象連接數(shù)飆升到服務(wù)端文件描述符上限整個(gè)應(yīng)用直接拒連接。從那以后我所有的 WebSocket 服務(wù)都強(qiáng)制加超時(shí)清理邏輯。前端那邊的重連也很有講究。最簡(jiǎn)單的方案是斷線后固定延遲重連但服務(wù)端發(fā)布重啟時(shí)成百上千的客戶端會(huì)同時(shí)發(fā)起重連造成“驚群效應(yīng)”——服務(wù)端剛啟動(dòng)就被一輪重連請(qǐng)求打掛。我建議前端做指數(shù)退避重連從 1 秒開始每次失敗翻倍最長(zhǎng)不超過 30 秒并且加上隨機(jī)抖動(dòng)jitter避免客戶端的重連請(qǐng)求在同一時(shí)刻爆發(fā)。4.2 鑒權(quán)怎么做token 帶在哪WebSocket 握手走的是 HTTP所以鑒權(quán)理論上可以在握手階段完成。但 WebSocket API 在瀏覽器里有一個(gè)限制無法自定義 Header。new WebSocket(url)只能設(shè)置 URL 和協(xié)議列表不能像fetch那樣手動(dòng)帶Authorization頭。因此常用方案有三種方案一token 放進(jìn) URL Query 參數(shù)。比如ws://localhost:8080/notice/1001?tokenabc123。實(shí)現(xiàn)簡(jiǎn)單但 token 會(huì)出現(xiàn)在日志、瀏覽器歷史、反向代理的 access log 里有泄露風(fēng)險(xiǎn)務(wù)必做好日志脫敏。方案二token 放到子協(xié)議Subprotocol里。在握手時(shí)用Sec-WebSocket-Protocol字段攜帶 token服務(wù)端從 header 里取出來校驗(yàn)。這種方式相對(duì)隱蔽但協(xié)議本意是標(biāo)記應(yīng)用層協(xié)議拿它傳 token 屬于“擦邊球”需要團(tuán)隊(duì)統(tǒng)一約定。方案三先通過 HTTP 接口換取一次性票據(jù)再在握手時(shí)通過 Query 參數(shù)提交服務(wù)端校驗(yàn)通過后立即失效。適合對(duì)安全要求高的場(chǎng)景。我個(gè)人最常用的組合是token 放 Query 參數(shù) 服務(wù)端攔截器校驗(yàn) 對(duì)日志做脫敏處理。校驗(yàn)放在握手階段有一個(gè)巨大的好處——失敗的連接根本不會(huì)被OnOpen接收避免非法連接占用資源。4.3 多實(shí)例部署消息怎么廣播WebSocket 的連接是有狀態(tài)的Session 綁定在某個(gè)實(shí)例上。一旦服務(wù)做水平擴(kuò)容部署了多個(gè)實(shí)例用戶 A 連接在實(shí)例 1用戶 B 連接在實(shí)例 2A 要給 B 發(fā)消息直接遍歷本地 SESSION_MAP 根本找不到 B。解決思路不是讓每個(gè)實(shí)例共享 Session而是引入一個(gè)消息路由層。最經(jīng)典的做法是基于 Redis 的發(fā)布訂閱Pub/Sub實(shí)例 1 收到 A 的消息后把消息發(fā)到 Redis 的指定 Channel所有訂閱了這個(gè) Channel 的實(shí)例都能收到再由持有目標(biāo) Session 的實(shí)例完成推送。核心邏輯大致如下// 推送入口 public void pushMessage(String targetUserId, String message) { // 1. 先查本地 Session 是否存在 if (SESSION_MAP.containsKey(targetUserId)) { sendToLocalUser(targetUserId, message); return; } // 2. 本地不存在通過 Redis Pub/Sub 廣播出去 redisTemplate.convertAndSend(ws:notice, targetUserId : message); } // Redis 消息監(jiān)聽器里接收并處理 public void onMessage(String payload) { String[] parts payload.split(:, 2); String targetUserId parts[0]; String message parts[1]; // 消息可能是發(fā)給本實(shí)例的也可能是發(fā)給其他實(shí)例的統(tǒng)一走本地發(fā)送邏輯 if (SESSION_MAP.containsKey(targetUserId)) { sendToLocalUser(targetUserId, message); } }這樣每個(gè)實(shí)例只需要維護(hù)自己的本地 SESSION_MAP跨實(shí)例的消息通過 Redis 中轉(zhuǎn)。要注意的是Redis Pub/Sub 的消息是即發(fā)即棄的如果某個(gè)實(shí)例當(dāng)時(shí)不在線消息就丟了。對(duì)推送可靠性要求更高的場(chǎng)景可以考慮用 Redis Stream、RocketMQ 這類帶持久化的消息隊(duì)列從“訂閱推送”演進(jìn)為“先存儲(chǔ)后投遞”。還有一種方案是引入專門的網(wǎng)關(guān)層所有 WebSocket 連接都掛在網(wǎng)關(guān)層業(yè)務(wù)后端不直接持有連接網(wǎng)關(guān)負(fù)責(zé)把消息路由到目標(biāo)客戶端。這種架構(gòu)更徹底但實(shí)現(xiàn)成本也更高適合體量更大、微服務(wù)劃分更細(xì)的團(tuán)隊(duì)。4.4 網(wǎng)關(guān)/代理層nginx 配置與連接超時(shí)WebSocket 服務(wù)前面幾乎都會(huì)加一層 nginx 做負(fù)載均衡和域名轉(zhuǎn)發(fā)。nginx 默認(rèn)配置對(duì) WebSocket 并不友好因?yàn)樗枰С?HTTP 升級(jí)。在我的服務(wù)器上一個(gè)可用的 location 配置是這樣的map $http_upgrade $connection_upgrade { default upgrade; close; } upstream ws_backend { server 127.0.0.1:8080; server 127.0.0.1:8081; # 開啟長(zhǎng)連接復(fù)用避免每次握手都新建后端連接 keepalive 32; } server { listen 80; server_name ws.example.com; location /notice { proxy_pass http://ws_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 關(guān)鍵如果 60 秒內(nèi)沒有數(shù)據(jù)交互nginx 會(huì)主動(dòng)斷開連接 proxy_read_timeout 3600s; proxy_send_timeout 3600s; } }上面配置里有幾個(gè)坑都是我實(shí)際踩過的proxy_set_header Connection $connection_upgrade是必須的如果寫成固定的upgrade普通 HTTP 請(qǐng)求也會(huì)被當(dāng)作升級(jí)請(qǐng)求處理導(dǎo)致靜態(tài)資源接口異常。用map做動(dòng)態(tài)映射是最穩(wěn)妥的方式。proxy_read_timeout默認(rèn)是 60 秒如果不調(diào)大當(dāng)客戶端和服務(wù)端之間剛好沒有數(shù)據(jù)交換超過 60 秒nginx 就會(huì)先斷開連接?？蛻舳撕蛻?yīng)用層心跳的數(shù)據(jù)能覆蓋這個(gè)超時(shí)時(shí)間但保險(xiǎn)起見我會(huì)把超時(shí)時(shí)間設(shè)置為心跳間隔的好幾倍。另外負(fù)載均衡算法默認(rèn)是輪詢但 WebSocket 連接一旦建立后續(xù)幀都走同一條 TCP 連接所以 nginx 層不需要做會(huì)話保持sticky session只要保證握手中的 Upgrade 請(qǐng)求被轉(zhuǎn)發(fā)到正確后端即可之后的流量都跟著連接走。5. 常見問題與排查技巧實(shí)錄5.1 連接一打開就斷瀏覽器報(bào) 10061006 是 WebSocket 里最讓人頭疼的錯(cuò)誤碼因?yàn)樗恰斑B接非正常關(guān)閉”的統(tǒng)稱瀏覽器不會(huì)給任何具體原因。服務(wù)端日志和瀏覽器 Network 面板往往都沒有有效信息。我遇到這個(gè)問題的排查順序一般是這樣的第一步確認(rèn)握手是否成功。在瀏覽器 Network 面板看 WebSocket 那條請(qǐng)求的 Status Code 是不是 101。如果不是 101說明代理層或后端沒有正確返回升級(jí)響應(yīng)大概率是 nginx 配置少了 Upgrade 頭。第二步確認(rèn)服務(wù)端有沒有在握手之后立刻關(guān)閉連接。常見原因是鑒權(quán)失敗、Session 為空返回了異常。在OnOpen里處理完邏輯后打一條日志確認(rèn)連接是否真的注冊(cè)成功。第三步排查是不是代理層提前斷開了。如果前面有 nginx 或者云負(fù)載均衡先跳過它直連后端測(cè)試。直連沒問題就把焦點(diǎn)放到代理層配置上。第四步看服務(wù)端進(jìn)程是不是有 GC 停頓或者線程阻塞。Full GC 如果造成長(zhǎng)時(shí)間 Stop The World也會(huì)觸發(fā)底層 TCP 超時(shí)表現(xiàn)出來就是 1006。5.2 服務(wù)端消息推送不出去代碼里明明調(diào)用了sendText沒有拋異常但客戶端就是收不到。這種“靜默失敗”比報(bào)錯(cuò)更煩人。根據(jù)我的經(jīng)驗(yàn)先查session.isOpen()。如果連接已經(jīng)斷了但狀態(tài)沒來得及更新發(fā)送接口可能不報(bào)錯(cuò)消息卻發(fā)不出去。其次是檢查是否用了同一個(gè)BasicRemote實(shí)例在多個(gè)線程里同時(shí)發(fā)送。WebSocket 協(xié)議要求同一個(gè)連接的數(shù)據(jù)幀必須串行發(fā)送多個(gè)線程同時(shí)寫會(huì)導(dǎo)致數(shù)據(jù)幀交錯(cuò)發(fā)送接口會(huì)拋異?；蛘呦⒈粊G棄。正確的做法是把發(fā)送操作統(tǒng)一收口到一個(gè)方法里加鎖保證同一時(shí)刻只有一個(gè)線程在寫。在 Netty 或者 Spring 底層同一條連接本身是不允許并發(fā)寫的框架會(huì)在高并發(fā)下觸發(fā)異常。5.3 連接數(shù)持續(xù)增長(zhǎng)內(nèi)存和句柄被吃光這個(gè)問題幾乎每個(gè)做 WebSocket 的人都會(huì)遇到?，F(xiàn)象是線上連接數(shù)一直漲不下降最后服務(wù)端報(bào) “Too many open files” 或者堆內(nèi)存耗盡。原因大多是兩類。一類是客戶端異常斷開拔網(wǎng)線、App 閃退沒有發(fā)關(guān)閉幀服務(wù)端的onClose沒有被調(diào)用Session 一直留在 Map 里。另一類是服務(wù)端業(yè)務(wù)代碼持有 Session 引用即使底層連接已經(jīng)關(guān)閉對(duì)象仍然無法被 GC。方案只有一個(gè)也是最有效的一個(gè)定時(shí)清理。寫一個(gè)定時(shí)任務(wù)每隔一段時(shí)間遍歷SESSION_MAP檢查每個(gè) Session 的最后活動(dòng)時(shí)間。如果超過設(shè)定閾值比如 90 秒沒有收到任何幀就主動(dòng)調(diào)用session.close()并從 Map 中移除。需要注意的是清理任務(wù)本身就是對(duì)宿主機(jī)資源的消耗幾千個(gè)連接還好幾萬個(gè)連接的時(shí)候ConcurrentHashMap的遍歷也會(huì)帶來線程競(jìng)爭(zhēng)。我現(xiàn)在的做法是把 Session 按時(shí)間分桶存放清理時(shí)只掃最近超時(shí)的桶而不是全量掃描。5.4 谷歌瀏覽器高版本無法啟用 WebSocket有不少人遇到這類問題高版本瀏覽器里 WebSocket 連接始終建立不起來控制臺(tái)報(bào)錯(cuò)信息又很模糊。首先要澄清一點(diǎn)現(xiàn)代主流瀏覽器對(duì) WebSocket 的支持是非常成熟的不需要“啟用”什么開關(guān)。所謂“無法啟用”絕大多數(shù)情況下是頁面代碼把ws://和wss://寫錯(cuò)了。如果頁面是 HTTPS 環(huán)境瀏覽器會(huì)強(qiáng)制要求 WebSocket 使用 TLS 加密也就是wss://協(xié)議。如果用ws://瀏覽器會(huì)直接拒絕連接報(bào)錯(cuò)內(nèi)容可能只是WebSocket connection failed。開發(fā)環(huán)境用 HTTP 就配ws://生產(chǎn)環(huán)境只要上了 HTTPS就必須對(duì)應(yīng)改成wss://并且 nginx 層要配置 SSL 證書和代理。另外瀏覽器對(duì) WebSocket 連接數(shù)也有限制。HTTP/1.1 下單個(gè)域名最多 6 條并發(fā)連接如果頁面里同時(shí)開了多個(gè) WebSocket超出的連接會(huì)排隊(duì)甚至失敗。高版本瀏覽器在 HTTP/2 下的連接限制略有放寬但多路復(fù)用對(duì) WebSocket 的支持并不完美仍然建議控制同頁面的連接數(shù)量。5.5 常見問題速查表現(xiàn)象常見原因處理優(yōu)先級(jí)連接一直無法建立協(xié)議前綴錯(cuò)誤、nginx 沒配 Upgrade、端口不通先查 nginx 配置和瀏覽器 Network連接建立后秒斷報(bào) 1006鑒權(quán)失敗、代理層超時(shí)、后端異常關(guān)閉服務(wù)端日志 直連測(cè)試客戶端收不到推送Session 已失效、多線程并發(fā)寫、代理層緩沖檢查 isOpen、統(tǒng)一收口發(fā)送連接數(shù)只增不減沒有心跳清理、onClose 未觸發(fā)增加定時(shí)清理任務(wù)后端多實(shí)例時(shí)消息不互通缺少消息路由層引入 Redis Pub/Sub 或消息隊(duì)列服務(wù)端 CPU 飆升心跳頻繁、全量掃描 Session、同步阻塞發(fā)送優(yōu)化心跳策略、異步發(fā)送把這些場(chǎng)景都過一遍之后再回頭看 WebSocket會(huì)發(fā)現(xiàn)它其實(shí)就是一個(gè)“長(zhǎng)連接 幀協(xié)議 連接管理”的組合體。協(xié)議本身不復(fù)雜復(fù)雜的是把它放進(jìn)真實(shí)系統(tǒng)里的各種約束。我在最初學(xué)習(xí)的時(shí)候總想著把協(xié)議背熟、代碼寫好就萬事大吉后來發(fā)現(xiàn)真正拉開差距的是連接斷沒斷、消息丟沒丟、服務(wù)掛沒掛這幾個(gè)在生產(chǎn)環(huán)境逃不掉的工程問題?，F(xiàn)在手邊每一個(gè) WebSocket 項(xiàng)目我上手第一件事就是先問清楚心跳怎么做、斷線重連怎么設(shè)計(jì)、集群節(jié)點(diǎn)掛了消息怎么兜底這比磨任何框架 API 都重要。