第一章：HTTP vs WebSocket 的差異：為什麼聊天軟體都需要即時雙向連線？

在開發傳統的網頁應用程式時，我們幾乎都是在使用 HTTP 協定。但在開發「即時互動（Real-time）」應用（像是 Line 聊天室、股票看盤軟體、或是像 ChatGPT 那樣會一個字一個字蹦出來的 AI）時，傳統的 HTTP 就會顯得非常吃力。

本章將帶你從底層網路協定的邏輯開始了解，為什麼要開發高階商業專案，你必須跨越 HTTP 的舒適圈，去擁抱 WebSocket 與 Streaming (SSE 串流) 技術。這也是你從「初階網頁設計師」晉升為「全端架構師」的必經之路。

🛑 傳統 HTTP 的限制：單向且短暫

HTTP (HyperText Transfer Protocol) 的核心模型叫做 「Request-Response (請求與回應)」 模型。你可以把它想像成你去手搖飲店買飲料：

Request (發起請求)：你（網頁前端）走到櫃檯跟店員說：「我要一杯珍珠奶茶。」
Processing (處理中)：店員轉身去泡茶（後端伺服器正在運算或查詢資料庫）。
Response (回應)：店員把珍珠奶茶遞給你。

一旦交易結束，你跟店員之間的「連結」就徹底斷了。這被稱為 「Stateless (無狀態)」。如果你想知道「現在有沒有草莓新口味？」，你不能站在原地等店員告訴你，你必須「再次走到櫃檯開口問一次」。

致命的效能殺手：Polling (輪詢)

如果我們硬要用傳統 HTTP 來寫一個多人聊天室，會發生什麼事？因為伺服器「無法主動」聯絡你的網頁，所以你的網頁只能寫一個定時器，每隔一秒鐘去問一次伺服器：

```javascript // 俗稱的 Short Polling (輪詢) - 新手最常犯的效能災難 setInterval(async () => { const response = await fetch('/api/get-new-messages?lastMsgId=999') const newMessages = await response.json()

if (newMessages.length > 0) { renderMessages(newMessages) } }, 1000) // 每秒鐘無腦敲一次伺服器 ```

這會帶來什麼毀滅性的後果？

無效請求太多：如果這 10 分鐘內根本沒有人講話，你的網頁還是會發出 600 次的 `fetch` 請求。
伺服器瞬間崩潰：當你有 10,000 個線上使用者時，你的伺服器「每秒鐘」都要處理 10,000 個「有新訊息嗎？」的垃圾請求。伺服器的 CPU 和資料庫連線池會瞬間耗盡，直接當機（而且你還會收到天價的 AWS 或 Vercel 雲端帳單）。

⚡ WebSocket 的誕生：一條專屬的雙向熱線電話

為了解決輪詢帶來的效能災難，HTML5 時代誕生了 WebSocket 協定。

WebSocket 就像是你跟伺服器之間牽了一條「專屬的熱線電話」，而且雙方都不掛斷。它打破了 HTTP 「只能由客戶端發起請求」的鐵律！

WebSocket 運作三部曲：

Handshake (握手階段)：網頁先發一個 HTTP 請求給伺服器，裡面帶有一個特殊的標籤 `Upgrade: websocket`，問伺服器：「我們改用 WebSocket 講電話好嗎？」
Bi-directional (雙向暢通)：伺服器答應後，連線建立。現在，不僅網頁可以隨時傳訊息給伺服器，伺服器也可以隨時主動推播訊息 (Push) 給網頁！
極低延遲：不需要像 HTTP 那樣每次都在封包裡塞滿厚重的 Header (如 Cookie, User-Agent)，WebSocket 的資料框架 (Data Frame) 極度輕量，訊息傳遞如閃電般迅速。

聊天室情境的魔法

在聊天軟體的場景中，當使用者 A 傳了一句「你好」給伺服器，伺服器不需要等使用者 B 來問，可以直接透過已經接通的 WebSocket 電話線，把「你好」廣播（Broadcast）到 B 的螢幕上。這就是為什麼你用 Line 的時候，對方一按下送出，你的手機會「瞬間」跳出通知，毫無延遲。

🌊 現代 AI 的基礎：Server-Sent Events (SSE) 與 Streaming

除了 WebSocket，在 AI (特別是 LLM 大語言模型) 浪潮爆發後，還有一個技術變得極度熱門，那就是 Streaming (串流) 與 SSE (Server-Sent Events)。

當你在使用 ChatGPT 時，你會發現它的回答是「一個字、一個字」慢慢印出來的，這就是著名的打字機特效。為什麼 AI 不能像傳統 HTTP 一樣，等整篇文章寫完再「一口氣」回傳呢？

AI 運算的物理極限

因為大語言模型 (LLM) 的運算速度有限。對於 GPT-4 這種巨型模型來說，生成一篇 1000 字的文章可能需要 15 秒到 30 秒。如果使用傳統 HTTP，使用者發出請求後，會看到一個轉圈圈的 Loading 圖案，然後對著白紙發呆 15 秒。在現代網頁的使用者體驗 (UX) 中，超過 3 秒沒有畫面更新，使用者就會認為「你的網站壞了」並關閉網頁。

所以，AI 業界全面採用了 Streaming 技術。伺服器算好第一個字，就立刻把這個字「塞」進一條未關閉的連線中傳給前端。算好第二個字，再塞第二個字。前端收到一個字，就立刻畫在螢幕上，讓使用者有一種「AI 正在瘋狂打字」的極速錯覺。

SSE (Server-Sent Events) 的底層原理

SSE 和 WebSocket 有點像，但它使用的是傳統的 HTTP 協定，並且是 「單向」 的長連線。

網頁對伺服器發起一個 HTTP GET/POST 請求。
伺服器回傳 Header `Content-Type: text/event-stream`，這等於告訴瀏覽器：「我這包資料還沒送完，這個連線不要關閉，我會一直丟新的片段 (Chunk) 給你。」
然後伺服器就可以不斷地把新的文字推送到這個連線上。

這種技術完美契合了 AI 對話的場景。因為使用者發問後，只需要「被動接收」 AI 源源不絕的回覆即可，不需要像 WebSocket 那樣建立雙向通道，這大幅減輕了伺服器維持連線的負擔。

🛠️ 現代即時應用的技術選擇 (我們這堂課的藍圖)

總結來說，在 2024 年開發商業級 SaaS，你必須根據不同的情境選擇不同的即時通訊技術：

Supabase Realtime (底層為 WebSocket)：
- 情境：用來監聽資料庫的變化。例如「聊天室的多人即時留言」、「共同編輯文件」、「即時股票看盤」。
- 優勢：雙向溝通，延遲極低。
AI Streaming API (SSE 的現代變形)：
- 情境：用來串接 OpenAI / Anthropic 伺服器，接收 AI 生成的文章。
- 優勢：輕量、原生支援 HTTP、完美支援 Vercel AI SDK 的打字機特效。

準備好了嗎？理論課到此結束。下一章，我們將直接切入實戰，從 Supabase Realtime 開始，親眼見證「不寫任何 polling 程式碼，資料庫一變動，前端畫面自動推播」的超級魔法！