SSE——被低估的單向串流，AI 時代的主角
嗨，我是凱文大叔。
上期講完輪詢家族：「你去問」的模式適合低頻鬆即時的場景，但頻率一高就是災難。這期進入「它來說」的世界，先從最容易被跳過、卻在 AI 時代意外翻紅的主角開始：SSE（Server-Sent Events）。
你每天都在用 SSE，只是不知道。ChatGPT、Claude、Gemini 的回答逐字浮現的「打字機效果」——那不是前端動畫，是伺服器真的一小段一小段把文字推過來，而承載這件事的協定，絕大多數就是 SSE。
SSE 是什麼：一條「不掛斷的 HTTP」
SSE 的原理簡單到令人懷疑：瀏覽器發一個普通的 HTTP GET，伺服器回應 Content-Type: text/event-stream，然後不關閉連線，有資料就往裡面寫一段：
data: 第一則訊息
data: 第二則訊息
就這樣。沒有新協定、沒有握手升級，就是一條不掛斷的 HTTP 回應。這帶來三個很實際的好處：
- 防火牆、代理、企業網路一路綠燈——它就是 HTTP，不會像 WebSocket 偶爾被中間設備擋掉
- 瀏覽器原生支援，前端三行就能動：
const es = new EventSource('/api/stream');
es.onmessage = (e) => render(e.data);
es.onerror = () => console.log('瀏覽器會自動重連，通常不用你管');
- 自動重連是規格內建的——斷線後瀏覽器自己重連，還會帶上
Last-Event-ID標頭告訴伺服器「我收到哪了」，讓伺服器能補發漏掉的事件。WebSocket 的重連要自己寫，SSE 送你。
當然，它有兩個明確的限制：單向（只能伺服器→瀏覽器；瀏覽器要說話請另外發 HTTP 請求）、純文字（UTF-8；二進位資料不行）。
什麼場景該選 SSE
共同特徵：資料主要往一個方向流。
- AI 串流回覆：LLM 逐 token 輸出，天生單向、天生文字——SSE 跟這個場景貼合到像是為它發明的
- 通知、動態牆：新留言、新訂單、系統廣播
- 進度回報：長任務的百分比、部署日誌的逐行輸出
- 看板數據：股價、監控指標、比分
反過來說，聊天室、協作編輯這種雙向高頻的場景，SSE 就不是主角了——那是下期 WebSocket 的地盤。
|
工商時間 |