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