議詳解：從實時數(shù)據(jù)推送到解決瀏覽器連接限制)
1. 從輪詢到長連接為什么我們需要SSE如果你做過Web實時數(shù)據(jù)展示比如一個后臺的實時監(jiān)控大盤或者一個聊天應用的“對方正在輸入...”狀態(tài)那你肯定對“數(shù)據(jù)如何從服務器實時推送到瀏覽器”這個問題頭疼過。早期最樸素的做法是輪詢Polling就是讓瀏覽器每隔幾秒就發(fā)個請求去問服務器“有新數(shù)據(jù)嗎”。這就像你每隔五分鐘就跑去問前臺有沒有你的快遞效率低下不說還浪費體力網(wǎng)絡帶寬和服務器資源。后來有了長輪詢Long Polling瀏覽器發(fā)一個請求服務器如果沒新數(shù)據(jù)就“掛起”這個請求直到有數(shù)據(jù)了或者超時了才返回。這好比你讓前臺一有快遞就立刻打電話通知你但每次通知完你又得馬上再打一次電話去“訂閱”下一次通知連接無法復用。于是HTML5帶來了兩種更優(yōu)雅的“服務器主動推送”方案WebSocket 和 Server-Sent Events (SSE)。WebSocket是雙向的像打電話建立連接后雙方可以隨時暢聊適合游戲、聊天等強交互場景。而SSE是單向的服務器向客戶端的單向廣播就像你訂閱了一個新聞頻道服務器有新聞就推給你但你沒法通過這個頻道回話。它基于普通的HTTP協(xié)議因此比WebSocket更簡單、更輕量天然支持斷線重連、事件ID等機制。最近隨著大模型和AI應用的爆發(fā)SSE突然又火了起來。因為它正是實現(xiàn)“流式輸出”的絕佳載體。當你向ChatGPT提問時你肯定不希望等它完全生成一大段文字后再一次性顯示給你而是希望看到一個字一個字“流”出來的效果。這種體驗的背后很多場景用的就是SSE協(xié)議。它讓服務器可以持續(xù)不斷地向瀏覽器發(fā)送數(shù)據(jù)片段而瀏覽器則能實時地渲染這些片段。所以無論你是想做一個實時股票報價系統(tǒng)、一個日志監(jiān)控面板還是一個AI對話界面SSE都是一個必須掌握的核心技術。然而當你興致勃勃地按照教程搭建好SSE服務打開心愛的Chrome瀏覽器測試時可能會遭遇一盆冷水頁面一片空白F12打開控制臺發(fā)現(xiàn)Fetch請求狀態(tài)一直是“pending”或者干脆報錯。更詭異的是同一個頁面在Firefox或者Safari里可能工作正常。這個問題十有八九就是撞上了“瀏覽器的HTTP/1.1連接限制”這堵隱形的墻。今天我們就來徹底搞懂SSE并親手拆掉這堵墻。2. SSE協(xié)議深度拆解不止是“流”那么簡單很多人以為SSE就是服務器一直不關閉HTTP響應然后往里面寫數(shù)據(jù)。這么說對但不全對。SSE有一套輕量但嚴謹?shù)囊?guī)范理解這些細節(jié)是你寫出健壯代碼和解決奇葩問題的前提。2.1 核心基于文本的事件流格式SSE的響應內容類型是text/event-stream。服務器發(fā)送的數(shù)據(jù)不是任意格式而必須遵循特定格式。一個最基本的SSE響應體看起來是這樣的HTTP/1.1 200 OK Content-Type: text/event-stream Cache-Control: no-cache Connection: keep-alive data: 這是第一條消息\n\n data: 這是第二條消息的第一行 data: 這是第二條消息的第二行\(zhòng)n\n event: customEvent data: 這是一個自定義事件的消息\n\n id: 123 data: 這條消息帶有一個ID\n\n我們來拆解一下關鍵指令data: 這是消息內容字段。一行data:定義一行消息內容。如果消息有多行就用多個data:字段。一個消息塊以兩個換行符\n\n結束。瀏覽器端的EventSourceAPI 會將所有data:字段的值用換行符連接起來作為最終的消息內容。event: 定義事件類型。默認類型是message。如果指定了自定義事件如event: update那么瀏覽器端就需要用addEventListener(update, ...)來監(jiān)聽而不是用默認的onmessage。id: 為消息設置一個ID。這個ID會被瀏覽器記錄下來。如果連接意外中斷當瀏覽器自動重連時會在HTTP請求頭中帶上Last-Event-ID: 123服務器可以根據(jù)這個ID決定從哪條消息開始重新發(fā)送實現(xiàn)斷點續(xù)傳。retry: 指定重連間隔毫秒。例如retry: 10000告訴瀏覽器如果連接失敗10秒后再嘗試重連。注意 消息的結束標志是連續(xù)的兩個換行符\n\n。很多新手在服務端拼接字符串時只寫了一個\n導致瀏覽器一直等待消息結束數(shù)據(jù)無法被正常解析和觸發(fā)。這是最常見的編碼錯誤之一。2.2 瀏覽器端EventSource API的功與過在瀏覽器端使用SSE簡單得令人發(fā)指const eventSource new EventSource(/your-sse-endpoint); // 監(jiān)聽默認的 message 事件 eventSource.onmessage (event) { console.log(收到數(shù)據(jù):, event.data); }; // 監(jiān)聽自定義事件 eventSource.addEventListener(customEvent, (event) { console.log(自定義事件數(shù)據(jù):, event.data); }); // 監(jiān)聽連接打開事件 eventSource.onopen () { console.log(SSE連接已建立); }; // 監(jiān)聽錯誤事件 eventSource.onerror (error) { console.error(SSE連接錯誤:, error); // 根據(jù)eventSource.readyState判斷狀態(tài) // 0: CONNECTING, 1: OPEN, 2: CLOSED }; // 關閉連接 // eventSource.close();EventSourceAPI 的優(yōu)點在于其簡潔和自動化的能力自動重連、自動解析事件流、自動處理連接狀態(tài)。但它也有明顯的缺點只支持GET請求 這意味著你不能用POST發(fā)送大量初始數(shù)據(jù)。如果需要通常的做法是在URL參數(shù)中傳遞或者先通過一個普通API建立會話再將會話ID通過SSE連接傳遞。不支持自定義請求頭 這是最致命的限制之一。在現(xiàn)代Web應用中我們通常使用Authorization: Bearer token這樣的頭部來進行身份驗證。原生的EventSource不支持設置任何請求頭。社區(qū)有使用fetch模擬EventSource的方案但這失去了自動重連等原生特性。單向通信 只能服務器向客戶端發(fā)客戶端不能通過這個連接回傳數(shù)據(jù)。2.3 服務端實現(xiàn)要點保持連接活躍服務端的核心任務是創(chuàng)建一個保持打開的HTTP響應并周期性地向其中寫入格式正確的SSE數(shù)據(jù)。這里以Node.js (Express) 和 Python (Flask) 為例Node.js Express 示例const express require(express); const app express(); app.get(/stream, (req, res) { // 1. 設置SSE必需的響應頭 res.writeHead(200, { Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive, // CORS 頭如果需要 Access-Control-Allow-Origin: * }); // 2. 立即發(fā)送一個注釋行可選有助于防止代理緩沖 res.write(:ok\n\n); // 3. 定期發(fā)送數(shù)據(jù) const clientId Date.now(); const intervalId setInterval(() { const data 服務器時間: ${new Date().toISOString()}; // 注意格式data: 內容\n\n res.write(id: ${clientId}\n); res.write(data: ${data}\n\n); // 測試10秒后發(fā)送一個自定義事件 // if (條件) { // res.write(event: special\n); // res.write(data: 特殊通知\n\n); // } }, 2000); // 每2秒發(fā)送一次 // 4. 客戶端斷開連接時清理資源 req.on(close, () { console.log(客戶端 ${clientId} 斷開連接); clearInterval(intervalId); res.end(); }); }); app.listen(3000, () console.log(SSE服務運行在 3000 端口));Python Flask 示例from flask import Flask, Response, request import time, json app Flask(__name__) def generate_events(): client_id int(time.time()) count 0 try: while True: count 1 # 構建SSE格式數(shù)據(jù) data f服務器時間: {time.ctime()}, 計數(shù): {count} # 使用 yield 生成器持續(xù)輸出 yield fid: {client_id}\ndata: {data}\n\n time.sleep(2) # 每2秒發(fā)送一次 except GeneratorExit: print(f客戶端 {client_id} 連接已關閉) app.route(/stream) def sse_stream(): # 返回一個流式響應 return Response( generate_events(), mimetypetext/event-stream, headers{ Cache-Control: no-cache, Connection: keep-alive, X-Accel-Buffering: no # 對Nginx代理特別重要禁用緩沖 } ) if __name__ __main__: app.run(threadedTrue, port5000)實操心得 在服務端尤其是 behind 反向代理如 Nginx時必須注意代理的緩沖行為。默認情況下Nginx會緩沖后端應用的響應以達到優(yōu)化目的但這會破壞SSE的實時性。務必在SSE響應頭或Nginx配置中加上X-Accel-Buffering: no;或proxy_buffering off;。3. 瀏覽器連接限制HTTP/1.1時代的“遺產(chǎn)”與應對之策現(xiàn)在我們來到最核心的難題。你寫好了服務端和客戶端代碼在本地用Firefox測試一切正常。但一用Chrome或基于Chromium的Edge、Thorium等瀏覽器打開連接就卡住了。打開開發(fā)者工具的“網(wǎng)絡”(Network)標簽你會發(fā)現(xiàn)那個/stream請求一直處于“待處理”(Pending)狀態(tài)而同一標簽頁下的其他API請求也無法發(fā)出。3.1 問題根源同一個域名下的HTTP/1.1連接數(shù)限制這個問題的根源是HTTP/1.1協(xié)議規(guī)范和瀏覽器廠商對其的實現(xiàn)優(yōu)化。在HTTP/1.1中同一個域名hostport下瀏覽器允許同時建立的**持久連接(Persistent Connection)**數(shù)量是有限制的。這個限制不是標準強制規(guī)定的而是瀏覽器為了性能和安全做出的實現(xiàn)決策。一個經(jīng)典的數(shù)值是6。這意味著同一個標簽頁甚至整個瀏覽器進程對https://api.your-app.com這個域名最多只能有6個HTTP/1.1連接同時處于活躍狀態(tài)。SSE連接是一個長連接它會長期占用一個連接“名額”。如果你的頁面在打開SSE連接的同時還需要加載大量其他資源如圖片、CSS、JS文件或并發(fā)調用多個API那么很容易就會把這6個名額占滿。一旦占滿后續(xù)的所有請求包括新的API調用、圖片加載都會被放入隊列等待直到有連接被釋放。這就是為什么你的SSE請求和頁面其他請求都“卡住”了。為什么Firefox/Safari可能沒事不同瀏覽器對這個限制的實現(xiàn)略有不同。有的瀏覽器可能將限制放寬到每個標簽頁有的則是全局的。Firefox的默認限制曾經(jīng)是每個服務器6個但新版本可能有所調整。Safari的行為也可能不同。而Chrome系瀏覽器對此限制的執(zhí)行非常嚴格因此問題暴露得最為明顯。為什么HTTP/2能解決這個問題HTTP/2引入了“多路復用”(Multiplexing)特性。在同一個TCP連接上可以并行交錯地傳輸多個請求和響應而不會互相阻塞。因此一個SSE流和其他幾十個API請求可以共享同一個連接從根本上避免了連接數(shù)限制的問題。如果你的前端和后端都部署在支持HTTP/2的服務器/CDN上并且使用HTTPS那么這個問題幾乎不會出現(xiàn)。3.2 解決方案一為SSE使用獨立的域名或子域名這是最經(jīng)典、最有效的解決方案。既然限制是針對“同一域名”的那我們就把SSE服務放到另一個域名下。主應用域名www.your-app.com(或app.your-app.com)SSE專用域名sse.your-app.com或stream.your-app.com這樣瀏覽器對www.your-app.com有最多6個連接限制對sse.your-app.com也有另外6個連接限制。SSE長連接只會占用它自己域名的連接池不會影響主應用的資源加載和API調用。實施步驟在DNS服務商處為你的服務器IP添加一個A記錄或CNAME記錄指向sse.your-app.com。在后端服務器配置中確保你的SSE端點可以通過這個新域名訪問。這通常意味著在Web服務器如Nginx中配置一個新的server塊或者在你的應用框架中配置路由。前端代碼中將EventSource的連接地址改為新的域名。// 之前 // const eventSource new EventSource(/api/stream); // 之后 const eventSource new EventSource(https://sse.your-app.com/api/stream);處理跨域問題 因為域名不同會觸發(fā)CORS。你需要在SSE服務的響應頭中添加正確的CORS頭。Access-Control-Allow-Origin: https://www.your-app.com Access-Control-Allow-Credentials: true # 如果需要攜帶Cookie注意 對于EventSource如果設置了withCredentials服務器端的Access-Control-Allow-Origin不能是通配符*必須是具體的域名。3.3 解決方案二升級到HTTP/2如果條件允許將你的整個網(wǎng)站升級到HTTP/2或HTTP/3。這不僅是解決SSE連接限制的終極方案也能極大提升網(wǎng)站整體性能。前提 HTTP/2通常要求使用HTTPS。你需要為你的域名配置SSL/TLS證書現(xiàn)在有很多免費證書如Let‘s Encrypt。服務端支持 確保你的Web服務器Nginx 1.9.5, Apache 2.4.17或后端運行時Node.js的spdy/http2模塊啟用了HTTP/2支持。驗證 在瀏覽器開發(fā)者工具的“網(wǎng)絡”標簽中查看請求的“協(xié)議”列如果顯示h2就說明正在使用HTTP/2。一旦啟用HTTP/2所有請求都在一個連接上多路復用SSE連接將不再占用額外的連接“名額”問題迎刃而解。3.4 解決方案三優(yōu)化頁面資源加載策略如果暫時無法使用新域名或HTTP/2可以通過優(yōu)化來緩解問題減少初始并發(fā)請求 合并CSS/JS文件使用雪碧圖減少圖片請求懶加載非首屏資源。域名分片 這是一個HTTP/1.1時代的經(jīng)典優(yōu)化技巧。將靜態(tài)資源圖片、字體、樣式放在另一個或多個子域名下如static1.your-app.com,static2.your-app.com以利用瀏覽器對每個域名的連接限制。但這會增加DNS查詢和TCP連接建立的成本在HTTP/2環(huán)境下反而是反模式。延遲建立SSE連接 不要在頁面加載伊始就建立SSE連接?？梢缘却撁嬷饕Y源加載完畢監(jiān)聽DOMContentLoaded事件或用戶執(zhí)行某個操作如點擊標簽頁后再建立連接。3.5 診斷與驗證如何確認是連接限制問題當SSE不工作時按以下步驟排查打開瀏覽器開發(fā)者工具 - 網(wǎng)絡(Network)標簽。清空記錄刷新頁面。觀察/stream或其他SSE請求的狀態(tài)。如果它一直處于“待處理”(Pending)狀態(tài)且同一時間有很多其他對同一域名的請求也處于Pending狀態(tài)接近6個那么基本可以斷定是連接數(shù)限制。嘗試在瀏覽器地址欄打開一個新的隱私窗口無痕模式測試。因為隱私窗口的會話是隔離的可能不受其他標簽頁連接的影響。嘗試使用不同的瀏覽器Firefox, Safari進行測試對比結果。4. 進階實踐與常見陷阱解決了連接限制SSE的征途才走完一半。在實際生產(chǎn)環(huán)境中還有更多細節(jié)需要打磨。4.1 身份驗證與自定義頭部如前所述原生EventSource不支持設置請求頭。對于需要Token驗證的場景有幾種變通方案方案AURL查詢參數(shù)將認證Token作為URL的查詢參數(shù)傳遞。這是最簡單的方法但Token會暴露在瀏覽器歷史記錄、服務器日志和Referer頭中安全性較低僅適用于低敏感場景。const token getAuthToken(); const eventSource new EventSource(/api/stream?token${encodeURIComponent(token)});方案B使用Cookie如果SSE服務與主站同域或設置了正確的CORS和Cookie域可以將認證信息放在Cookie中。瀏覽器會自動攜帶Cookie。這種方式更安全但需要處理CSRF等安全問題。方案C使用fetch API模擬EventSource這是功能最強大的方案。你可以用fetch發(fā)起請求然后手動讀取流、解析事件、實現(xiàn)重連邏輯。雖然復雜但可以完全控制請求頭。async function createCustomEventSource(url, options {}) { const { headers {}, onMessage, onError, onOpen } options; async function connect() { try { const response await fetch(url, { method: GET, headers: { Accept: text/event-stream, ...headers // 可以在這里傳入 Authorization 等自定義頭 }, credentials: include // 如果需要Cookie }); if (!response.ok || !response.body) { throw new Error(SSE連接失敗: ${response.status}); } onOpen?.(); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 最后一行可能是不完整的放回緩沖區(qū) let event { id: null, event: message, data: }; for (const line of lines) { if (line.startsWith(id:)) event.id line.substring(3).trim(); else if (line.startsWith(event:)) event.event line.substring(6).trim(); else if (line.startsWith(data:)) event.data line.substring(5).trim() \n; else if (line ) { // 空行表示一個消息結束 if (event.data) { event.data event.data.trimEnd(); onMessage?.(event); } event { id: null, event: message, data: }; } } } } catch (err) { onError?.(err); // 實現(xiàn)重連邏輯 setTimeout(() connect(), 3000); } } connect(); // 返回一個關閉函數(shù) return () { /* 關閉邏輯 */ }; }4.2 連接穩(wěn)定性與生產(chǎn)環(huán)境考量心跳機制 為了防止代理或防火墻因長時間無數(shù)據(jù)而斷開空閑連接服務器應定期發(fā)送“心跳”消息。這可以是一個只包含冒號的注釋行:keepalive\n\n或者一個不包含實際數(shù)據(jù)的普通消息。錯誤處理與重連 雖然EventSource有自動重連但生產(chǎn)環(huán)境需要更精細的控制。例如在onerror事件中根據(jù)eventSource.readyState判斷錯誤類型實現(xiàn)指數(shù)退避重連策略避免網(wǎng)絡抖動時頻繁重連沖擊服務器。服務端連接管理 當有成千上萬個客戶端保持長連接時服務端資源管理至關重要。你需要一個機制來存儲和管理所有活躍的連接對象如放在Map中并在客戶端斷開時監(jiān)聽req.on(close)或res.on(close)及時清理防止內存泄漏。負載均衡與粘性會話 如果你的服務端是多實例部署SSE連接必須通過負載均衡器。由于SSE是長連接負載均衡器必須支持“粘性會話”Session Affinity確保來自同一客戶端的后續(xù)請求包括重連能被路由到之前那個持有連接的后端實例。否則重連后會找不到之前的連接上下文。4.3 與WebSocket的選型對比最后我們再來明確一下SSE和WebSocket的選型邊界這能幫你避免用錯技術。特性Server-Sent Events (SSE)WebSocket通信方向單向(服務器 - 客戶端)雙向(全雙工)協(xié)議普通 HTTP/HTTPS獨立的ws://或wss://協(xié)議數(shù)據(jù)格式文本 (UTF-8)格式固定(data:,id:,event:)文本或二進制格式完全自定義瀏覽器APIEventSource(簡單功能有限)WebSocket(功能強大)自動重連內置支持(帶Last-Event-ID)需手動實現(xiàn)自定義請求頭不支持(原生API)支持適用場景實時通知、新聞推送、監(jiān)控數(shù)據(jù)流、日志流、AI流式輸出在線聊天、協(xié)同編輯、實時游戲、股票交易終端簡單決策樹如果你的場景主要是服務器向客戶端推送數(shù)據(jù)且客戶端不需要頻繁地向服務器發(fā)送消息或者可以通過普通的HTTP API發(fā)送那么SSE是更簡單、更輕量的選擇。AI對話的流式輸出就是典型場景。如果你需要真正的雙向、低延遲、高頻次通信比如構建一個聊天室或在線游戲那么WebSocket是唯一的選擇。我個人在構建后臺數(shù)據(jù)監(jiān)控大屏和AI功能的前端流式輸出時首選SSE。它的實現(xiàn)成本低基于HTTP的特性使其更容易集成到現(xiàn)有架構中并且自動重連等特性非常省心。而遇到連接限制問題時使用獨立子域名是最快最穩(wěn)的解決方案。 SSE協(xié)議詳解：從實時數(shù)據(jù)推送到解決瀏覽器連接限制
1. 從輪詢到長連接為什么我們需要SSE如果你做過Web實時數(shù)據(jù)展示比如一個后臺的實時監(jiān)控大盤或者一個聊天應用的“對方正在輸入...”狀態(tài)那你肯定對“數(shù)據(jù)如何從服務器實時推送到瀏覽器”這個問題頭疼過。早期最樸素的做法是輪詢Polling就是讓瀏覽器每隔幾秒就發(fā)個請求去問服務器“有新數(shù)據(jù)嗎”。這就像你每隔五分鐘就跑去問前臺有沒有你的快遞效率低下不說還浪費體力網(wǎng)絡帶寬和服務器資源。后來有了長輪詢Long Polling瀏覽器發(fā)一個請求服務器如果沒新數(shù)據(jù)就“掛起”這個請求直到有數(shù)據(jù)了或者超時了才返回。這好比你讓前臺一有快遞就立刻打電話通知你但每次通知完你又得馬上再打一次電話去“訂閱”下一次通知連接無法復用。于是HTML5帶來了兩種更優(yōu)雅的“服務器主動推送”方案WebSocket 和 Server-Sent Events (SSE)。WebSocket是雙向的像打電話建立連接后雙方可以隨時暢聊適合游戲、聊天等強交互場景。而SSE是單向的服務器向客戶端的單向廣播就像你訂閱了一個新聞頻道服務器有新聞就推給你但你沒法通過這個頻道回話。它基于普通的HTTP協(xié)議因此比WebSocket更簡單、更輕量天然支持斷線重連、事件ID等機制。最近隨著大模型和AI應用的爆發(fā)SSE突然又火了起來。因為它正是實現(xiàn)“流式輸出”的絕佳載體。當你向ChatGPT提問時你肯定不希望等它完全生成一大段文字后再一次性顯示給你而是希望看到一個字一個字“流”出來的效果。這種體驗的背后很多場景用的就是SSE協(xié)議。它讓服務器可以持續(xù)不斷地向瀏覽器發(fā)送數(shù)據(jù)片段而瀏覽器則能實時地渲染這些片段。所以無論你是想做一個實時股票報價系統(tǒng)、一個日志監(jiān)控面板還是一個AI對話界面SSE都是一個必須掌握的核心技術。然而當你興致勃勃地按照教程搭建好SSE服務打開心愛的Chrome瀏覽器測試時可能會遭遇一盆冷水頁面一片空白F12打開控制臺發(fā)現(xiàn)Fetch請求狀態(tài)一直是“pending”或者干脆報錯。更詭異的是同一個頁面在Firefox或者Safari里可能工作正常。這個問題十有八九就是撞上了“瀏覽器的HTTP/1.1連接限制”這堵隱形的墻。今天我們就來徹底搞懂SSE并親手拆掉這堵墻。2. SSE協(xié)議深度拆解不止是“流”那么簡單很多人以為SSE就是服務器一直不關閉HTTP響應然后往里面寫數(shù)據(jù)。這么說對但不全對。SSE有一套輕量但嚴謹?shù)囊?guī)范理解這些細節(jié)是你寫出健壯代碼和解決奇葩問題的前提。2.1 核心基于文本的事件流格式SSE的響應內容類型是text/event-stream。服務器發(fā)送的數(shù)據(jù)不是任意格式而必須遵循特定格式。一個最基本的SSE響應體看起來是這樣的HTTP/1.1 200 OK Content-Type: text/event-stream Cache-Control: no-cache Connection: keep-alive data: 這是第一條消息\n\n data: 這是第二條消息的第一行 data: 這是第二條消息的第二行\(zhòng)n\n event: customEvent data: 這是一個自定義事件的消息\n\n id: 123 data: 這條消息帶有一個ID\n\n我們來拆解一下關鍵指令data: 這是消息內容字段。一行data:定義一行消息內容。如果消息有多行就用多個data:字段。一個消息塊以兩個換行符\n\n結束。瀏覽器端的EventSourceAPI 會將所有data:字段的值用換行符連接起來作為最終的消息內容。event: 定義事件類型。默認類型是message。如果指定了自定義事件如event: update那么瀏覽器端就需要用addEventListener(update, ...)來監(jiān)聽而不是用默認的onmessage。id: 為消息設置一個ID。這個ID會被瀏覽器記錄下來。如果連接意外中斷當瀏覽器自動重連時會在HTTP請求頭中帶上Last-Event-ID: 123服務器可以根據(jù)這個ID決定從哪條消息開始重新發(fā)送實現(xiàn)斷點續(xù)傳。retry: 指定重連間隔毫秒。例如retry: 10000告訴瀏覽器如果連接失敗10秒后再嘗試重連。注意 消息的結束標志是連續(xù)的兩個換行符\n\n。很多新手在服務端拼接字符串時只寫了一個\n導致瀏覽器一直等待消息結束數(shù)據(jù)無法被正常解析和觸發(fā)。這是最常見的編碼錯誤之一。2.2 瀏覽器端EventSource API的功與過在瀏覽器端使用SSE簡單得令人發(fā)指const eventSource new EventSource(/your-sse-endpoint); // 監(jiān)聽默認的 message 事件 eventSource.onmessage (event) { console.log(收到數(shù)據(jù):, event.data); }; // 監(jiān)聽自定義事件 eventSource.addEventListener(customEvent, (event) { console.log(自定義事件數(shù)據(jù):, event.data); }); // 監(jiān)聽連接打開事件 eventSource.onopen () { console.log(SSE連接已建立); }; // 監(jiān)聽錯誤事件 eventSource.onerror (error) { console.error(SSE連接錯誤:, error); // 根據(jù)eventSource.readyState判斷狀態(tài) // 0: CONNECTING, 1: OPEN, 2: CLOSED }; // 關閉連接 // eventSource.close();EventSourceAPI 的優(yōu)點在于其簡潔和自動化的能力自動重連、自動解析事件流、自動處理連接狀態(tài)。但它也有明顯的缺點只支持GET請求 這意味著你不能用POST發(fā)送大量初始數(shù)據(jù)。如果需要通常的做法是在URL參數(shù)中傳遞或者先通過一個普通API建立會話再將會話ID通過SSE連接傳遞。不支持自定義請求頭 這是最致命的限制之一。在現(xiàn)代Web應用中我們通常使用Authorization: Bearer token這樣的頭部來進行身份驗證。原生的EventSource不支持設置任何請求頭。社區(qū)有使用fetch模擬EventSource的方案但這失去了自動重連等原生特性。單向通信 只能服務器向客戶端發(fā)客戶端不能通過這個連接回傳數(shù)據(jù)。2.3 服務端實現(xiàn)要點保持連接活躍服務端的核心任務是創(chuàng)建一個保持打開的HTTP響應并周期性地向其中寫入格式正確的SSE數(shù)據(jù)。這里以Node.js (Express) 和 Python (Flask) 為例Node.js Express 示例const express require(express); const app express(); app.get(/stream, (req, res) { // 1. 設置SSE必需的響應頭 res.writeHead(200, { Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive, // CORS 頭如果需要 Access-Control-Allow-Origin: * }); // 2. 立即發(fā)送一個注釋行可選有助于防止代理緩沖 res.write(:ok\n\n); // 3. 定期發(fā)送數(shù)據(jù) const clientId Date.now(); const intervalId setInterval(() { const data 服務器時間: ${new Date().toISOString()}; // 注意格式data: 內容\n\n res.write(id: ${clientId}\n); res.write(data: ${data}\n\n); // 測試10秒后發(fā)送一個自定義事件 // if (條件) { // res.write(event: special\n); // res.write(data: 特殊通知\n\n); // } }, 2000); // 每2秒發(fā)送一次 // 4. 客戶端斷開連接時清理資源 req.on(close, () { console.log(客戶端 ${clientId} 斷開連接); clearInterval(intervalId); res.end(); }); }); app.listen(3000, () console.log(SSE服務運行在 3000 端口));Python Flask 示例from flask import Flask, Response, request import time, json app Flask(__name__) def generate_events(): client_id int(time.time()) count 0 try: while True: count 1 # 構建SSE格式數(shù)據(jù) data f服務器時間: {time.ctime()}, 計數(shù): {count} # 使用 yield 生成器持續(xù)輸出 yield fid: {client_id}\ndata: {data}\n\n time.sleep(2) # 每2秒發(fā)送一次 except GeneratorExit: print(f客戶端 {client_id} 連接已關閉) app.route(/stream) def sse_stream(): # 返回一個流式響應 return Response( generate_events(), mimetypetext/event-stream, headers{ Cache-Control: no-cache, Connection: keep-alive, X-Accel-Buffering: no # 對Nginx代理特別重要禁用緩沖 } ) if __name__ __main__: app.run(threadedTrue, port5000)實操心得 在服務端尤其是 behind 反向代理如 Nginx時必須注意代理的緩沖行為。默認情況下Nginx會緩沖后端應用的響應以達到優(yōu)化目的但這會破壞SSE的實時性。務必在SSE響應頭或Nginx配置中加上X-Accel-Buffering: no;或proxy_buffering off;。3. 瀏覽器連接限制HTTP/1.1時代的“遺產(chǎn)”與應對之策現(xiàn)在我們來到最核心的難題。你寫好了服務端和客戶端代碼在本地用Firefox測試一切正常。但一用Chrome或基于Chromium的Edge、Thorium等瀏覽器打開連接就卡住了。打開開發(fā)者工具的“網(wǎng)絡”(Network)標簽你會發(fā)現(xiàn)那個/stream請求一直處于“待處理”(Pending)狀態(tài)而同一標簽頁下的其他API請求也無法發(fā)出。3.1 問題根源同一個域名下的HTTP/1.1連接數(shù)限制這個問題的根源是HTTP/1.1協(xié)議規(guī)范和瀏覽器廠商對其的實現(xiàn)優(yōu)化。在HTTP/1.1中同一個域名hostport下瀏覽器允許同時建立的**持久連接(Persistent Connection)**數(shù)量是有限制的。這個限制不是標準強制規(guī)定的而是瀏覽器為了性能和安全做出的實現(xiàn)決策。一個經(jīng)典的數(shù)值是6。這意味著同一個標簽頁甚至整個瀏覽器進程對https://api.your-app.com這個域名最多只能有6個HTTP/1.1連接同時處于活躍狀態(tài)。SSE連接是一個長連接它會長期占用一個連接“名額”。如果你的頁面在打開SSE連接的同時還需要加載大量其他資源如圖片、CSS、JS文件或并發(fā)調用多個API那么很容易就會把這6個名額占滿。一旦占滿后續(xù)的所有請求包括新的API調用、圖片加載都會被放入隊列等待直到有連接被釋放。這就是為什么你的SSE請求和頁面其他請求都“卡住”了。為什么Firefox/Safari可能沒事不同瀏覽器對這個限制的實現(xiàn)略有不同。有的瀏覽器可能將限制放寬到每個標簽頁有的則是全局的。Firefox的默認限制曾經(jīng)是每個服務器6個但新版本可能有所調整。Safari的行為也可能不同。而Chrome系瀏覽器對此限制的執(zhí)行非常嚴格因此問題暴露得最為明顯。為什么HTTP/2能解決這個問題HTTP/2引入了“多路復用”(Multiplexing)特性。在同一個TCP連接上可以并行交錯地傳輸多個請求和響應而不會互相阻塞。因此一個SSE流和其他幾十個API請求可以共享同一個連接從根本上避免了連接數(shù)限制的問題。如果你的前端和后端都部署在支持HTTP/2的服務器/CDN上并且使用HTTPS那么這個問題幾乎不會出現(xiàn)。3.2 解決方案一為SSE使用獨立的域名或子域名這是最經(jīng)典、最有效的解決方案。既然限制是針對“同一域名”的那我們就把SSE服務放到另一個域名下。主應用域名www.your-app.com(或app.your-app.com)SSE專用域名sse.your-app.com或stream.your-app.com這樣瀏覽器對www.your-app.com有最多6個連接限制對sse.your-app.com也有另外6個連接限制。SSE長連接只會占用它自己域名的連接池不會影響主應用的資源加載和API調用。實施步驟在DNS服務商處為你的服務器IP添加一個A記錄或CNAME記錄指向sse.your-app.com。在后端服務器配置中確保你的SSE端點可以通過這個新域名訪問。這通常意味著在Web服務器如Nginx中配置一個新的server塊或者在你的應用框架中配置路由。前端代碼中將EventSource的連接地址改為新的域名。// 之前 // const eventSource new EventSource(/api/stream); // 之后 const eventSource new EventSource(https://sse.your-app.com/api/stream);處理跨域問題 因為域名不同會觸發(fā)CORS。你需要在SSE服務的響應頭中添加正確的CORS頭。Access-Control-Allow-Origin: https://www.your-app.com Access-Control-Allow-Credentials: true # 如果需要攜帶Cookie注意 對于EventSource如果設置了withCredentials服務器端的Access-Control-Allow-Origin不能是通配符*必須是具體的域名。3.3 解決方案二升級到HTTP/2如果條件允許將你的整個網(wǎng)站升級到HTTP/2或HTTP/3。這不僅是解決SSE連接限制的終極方案也能極大提升網(wǎng)站整體性能。前提 HTTP/2通常要求使用HTTPS。你需要為你的域名配置SSL/TLS證書現(xiàn)在有很多免費證書如Let‘s Encrypt。服務端支持 確保你的Web服務器Nginx 1.9.5, Apache 2.4.17或后端運行時Node.js的spdy/http2模塊啟用了HTTP/2支持。驗證 在瀏覽器開發(fā)者工具的“網(wǎng)絡”標簽中查看請求的“協(xié)議”列如果顯示h2就說明正在使用HTTP/2。一旦啟用HTTP/2所有請求都在一個連接上多路復用SSE連接將不再占用額外的連接“名額”問題迎刃而解。3.4 解決方案三優(yōu)化頁面資源加載策略如果暫時無法使用新域名或HTTP/2可以通過優(yōu)化來緩解問題減少初始并發(fā)請求 合并CSS/JS文件使用雪碧圖減少圖片請求懶加載非首屏資源。域名分片 這是一個HTTP/1.1時代的經(jīng)典優(yōu)化技巧。將靜態(tài)資源圖片、字體、樣式放在另一個或多個子域名下如static1.your-app.com,static2.your-app.com以利用瀏覽器對每個域名的連接限制。但這會增加DNS查詢和TCP連接建立的成本在HTTP/2環(huán)境下反而是反模式。延遲建立SSE連接 不要在頁面加載伊始就建立SSE連接?？梢缘却撁嬷饕Y源加載完畢監(jiān)聽DOMContentLoaded事件或用戶執(zhí)行某個操作如點擊標簽頁后再建立連接。3.5 診斷與驗證如何確認是連接限制問題當SSE不工作時按以下步驟排查打開瀏覽器開發(fā)者工具 - 網(wǎng)絡(Network)標簽。清空記錄刷新頁面。觀察/stream或其他SSE請求的狀態(tài)。如果它一直處于“待處理”(Pending)狀態(tài)且同一時間有很多其他對同一域名的請求也處于Pending狀態(tài)接近6個那么基本可以斷定是連接數(shù)限制。嘗試在瀏覽器地址欄打開一個新的隱私窗口無痕模式測試。因為隱私窗口的會話是隔離的可能不受其他標簽頁連接的影響。嘗試使用不同的瀏覽器Firefox, Safari進行測試對比結果。4. 進階實踐與常見陷阱解決了連接限制SSE的征途才走完一半。在實際生產(chǎn)環(huán)境中還有更多細節(jié)需要打磨。4.1 身份驗證與自定義頭部如前所述原生EventSource不支持設置請求頭。對于需要Token驗證的場景有幾種變通方案方案AURL查詢參數(shù)將認證Token作為URL的查詢參數(shù)傳遞。這是最簡單的方法但Token會暴露在瀏覽器歷史記錄、服務器日志和Referer頭中安全性較低僅適用于低敏感場景。const token getAuthToken(); const eventSource new EventSource(/api/stream?token${encodeURIComponent(token)});方案B使用Cookie如果SSE服務與主站同域或設置了正確的CORS和Cookie域可以將認證信息放在Cookie中。瀏覽器會自動攜帶Cookie。這種方式更安全但需要處理CSRF等安全問題。方案C使用fetch API模擬EventSource這是功能最強大的方案。你可以用fetch發(fā)起請求然后手動讀取流、解析事件、實現(xiàn)重連邏輯。雖然復雜但可以完全控制請求頭。async function createCustomEventSource(url, options {}) { const { headers {}, onMessage, onError, onOpen } options; async function connect() { try { const response await fetch(url, { method: GET, headers: { Accept: text/event-stream, ...headers // 可以在這里傳入 Authorization 等自定義頭 }, credentials: include // 如果需要Cookie }); if (!response.ok || !response.body) { throw new Error(SSE連接失敗: ${response.status}); } onOpen?.(); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 最后一行可能是不完整的放回緩沖區(qū) let event { id: null, event: message, data: }; for (const line of lines) { if (line.startsWith(id:)) event.id line.substring(3).trim(); else if (line.startsWith(event:)) event.event line.substring(6).trim(); else if (line.startsWith(data:)) event.data line.substring(5).trim() \n; else if (line ) { // 空行表示一個消息結束 if (event.data) { event.data event.data.trimEnd(); onMessage?.(event); } event { id: null, event: message, data: }; } } } } catch (err) { onError?.(err); // 實現(xiàn)重連邏輯 setTimeout(() connect(), 3000); } } connect(); // 返回一個關閉函數(shù) return () { /* 關閉邏輯 */ }; }4.2 連接穩(wěn)定性與生產(chǎn)環(huán)境考量心跳機制 為了防止代理或防火墻因長時間無數(shù)據(jù)而斷開空閑連接服務器應定期發(fā)送“心跳”消息。這可以是一個只包含冒號的注釋行:keepalive\n\n或者一個不包含實際數(shù)據(jù)的普通消息。錯誤處理與重連 雖然EventSource有自動重連但生產(chǎn)環(huán)境需要更精細的控制。例如在onerror事件中根據(jù)eventSource.readyState判斷錯誤類型實現(xiàn)指數(shù)退避重連策略避免網(wǎng)絡抖動時頻繁重連沖擊服務器。服務端連接管理 當有成千上萬個客戶端保持長連接時服務端資源管理至關重要。你需要一個機制來存儲和管理所有活躍的連接對象如放在Map中并在客戶端斷開時監(jiān)聽req.on(close)或res.on(close)及時清理防止內存泄漏。負載均衡與粘性會話 如果你的服務端是多實例部署SSE連接必須通過負載均衡器。由于SSE是長連接負載均衡器必須支持“粘性會話”Session Affinity確保來自同一客戶端的后續(xù)請求包括重連能被路由到之前那個持有連接的后端實例。否則重連后會找不到之前的連接上下文。4.3 與WebSocket的選型對比最后我們再來明確一下SSE和WebSocket的選型邊界這能幫你避免用錯技術。特性Server-Sent Events (SSE)WebSocket通信方向單向(服務器 - 客戶端)雙向(全雙工)協(xié)議普通 HTTP/HTTPS獨立的ws://或wss://協(xié)議數(shù)據(jù)格式文本 (UTF-8)格式固定(data:,id:,event:)文本或二進制格式完全自定義瀏覽器APIEventSource(簡單功能有限)WebSocket(功能強大)自動重連內置支持(帶Last-Event-ID)需手動實現(xiàn)自定義請求頭不支持(原生API)支持適用場景實時通知、新聞推送、監(jiān)控數(shù)據(jù)流、日志流、AI流式輸出在線聊天、協(xié)同編輯、實時游戲、股票交易終端簡單決策樹如果你的場景主要是服務器向客戶端推送數(shù)據(jù)且客戶端不需要頻繁地向服務器發(fā)送消息或者可以通過普通的HTTP API發(fā)送那么SSE是更簡單、更輕量的選擇。AI對話的流式輸出就是典型場景。如果你需要真正的雙向、低延遲、高頻次通信比如構建一個聊天室或在線游戲那么WebSocket是唯一的選擇。我個人在構建后臺數(shù)據(jù)監(jiān)控大屏和AI功能的前端流式輸出時首選SSE。它的實現(xiàn)成本低基于HTTP的特性使其更容易集成到現(xiàn)有架構中并且自動重連等特性非常省心。而遇到連接限制問題時使用獨立子域名是最快最穩(wěn)的解決方案。