HTTP 篇與 QUIC 篇一路把「請求／回應」做到極致；本篇處理的是它從頭到尾沒有碰的那一類需求——伺服器想在沒有人問的時候開口。

QUIC 篇的最後一句是：把 transport 換掉，換到的仍然是同一種通訊模式的更好版本——客戶端問、伺服器答，只是問得更快、答得更不容易被卡住。而 HTTP 篇在談完 Server Push 的失敗史時，也留下了同一個缺口：push 推的仍然是「客戶端接下來會請求的東西」，不是「伺服器現在想說的話」。

推播、行情跳動、聊天訊息、協作游標——這四個場景有一個共同特徵：訊息的時機由伺服器決定，客戶端沒有辦法事先問。 你可以用輪詢去猜（每秒問一次「有沒有新的？」），可以讓伺服器把回應 hold 住直到有東西可說（Long Polling），但這些都是在用請求／回應的語法模仿一件它不擅長的事。WebSocket（RFC 6455） 的作法乾脆得多：借 HTTP 開一次門，然後把這條 TCP 連線整個換掉，換成一個雙向、對稱、以訊息為單位的協定。

把一條 WebSocket 連線的一生拆開，剛好就是本篇的章節地圖。值得先注意的是：右邊那一欄幾乎沒有一項是協定幫你做好的——WebSocket 給的是一條乾淨的雙向訊息管道，管道以外的事全部是你的責任。

這張表也是本篇與 MQTT 篇的分界線：MQTT 會把右欄的一半搬到協定裡（QoS、離線訊息、Last Will）。WebSocket 刻意不做，因為它想當的是通道而不是訊息系統。

同一件事在 HTTP/1.1、HTTP/2、HTTP/3 上有三種寫法——而第三種之外還有一個「乾脆不要隧道」的選項。

1 · HTTP/1.1：借 101 換掉這條連線

WebSocket 交握是一個貨真價實的 HTTP GET 請求——這一點在第 6 節談認證時會變成關鍵。它多帶了幾個標頭，告訴伺服器「我想把這條連線換成 WebSocket」：

GET /ws HTTP/1.1                              # 就是一個普通的 GET
Host: chat.example.com
Upgrade: websocket                            # 想換到哪個協定
Connection: Upgrade                           # hop-by-hop：路徑上每個 proxy 都要看得懂
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==   # 16 bytes 隨機值的 base64
Sec-WebSocket-Version: 13                     # RFC 6455 定案的版本號
Sec-WebSocket-Protocol: chat.v2               # 可選：應用層子協定協商
Origin: https://app.example.com               # 瀏覽器自動帶上，伺服器必須驗（見第 6 節）

HTTP/1.1 101 Switching Protocols              # 不是 200；之後這條連線不再說 HTTP
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=   # SHA-1(key + 固定 GUID) 的 base64
Sec-WebSocket-Protocol: chat.v2               # 必須是客戶端提議清單裡的其中一個

注意回應是 101 而不是 200。收到 101 的那一刻，兩端都把這條 TCP 連線的「解析器」從 HTTP 換成 WebSocket——已經讀進來但還沒處理的位元組要一併轉交，這是自己實作 WebSocket 伺服器時最常見的 bug。

因為 Connection: Upgrade 是逐跳（hop-by-hop）標頭（HTTP 篇談狀態碼與標頭時已列），路徑上每一個反向代理、負載均衡器都必須顯式支援才能把 Upgrade 轉發下去——這也是實務上「本機好好的、上了測試環境就 400／連上馬上斷」的頭號原因（Nginx 要設 proxy_set_header Upgrade 與 Connection，並把 proxy_read_timeout 拉長）。

2 · HTTP/2：Connection 系列標頭被禁掉之後怎麼辦——RFC 8441

HTTP 篇留了一個尾巴：HTTP/2 直接禁止整組 Connection 系列標頭，因為連線管理已經下沉到 frame 層，用 SETTINGS／GOAWAY 而不是用標頭表達。這代表上面那套交握在 HTTP/2 上一個字都不能用：沒有 Upgrade、沒有 Connection、也沒有 101（HTTP/2 的回應只有一組 :status，不走協定切換那條路）。

RFC 8441（Extended CONNECT） 給的答案是換一個思路：不要「把整條連線換掉」，而是把單一條 stream 變成隧道。

sequenceDiagram
    participant C as 客戶端
    participant S as 伺服器
    S->>C: SETTINGS 宣告能力
    Note over C: 沒收到就不准送
    C->>S: Extended CONNECT
    S-->>C: status 200
    Note over C,S: 這條 stream 之後承載 WebSocket frame

三個回合的順序是強制的：伺服器沒有在 SETTINGS 裡宣告，客戶端連送都不准送——這是與 HTTP/1.1 交握最大的差別（那邊是客戶端先開口，伺服器只能答應或拒絕）。而且成功不再是換掉整條連線的 101，只是這條 stream 上的一個 200。

# 1. 伺服器在 SETTINGS frame 裡宣告能力，缺這一行後面全部不成立
SETTINGS_ENABLE_CONNECT_PROTOCOL = 1

# 2. 客戶端送出的 Extended CONNECT：四個 pseudo-header 缺一不可
:method   = CONNECT
:protocol = websocket     # RFC 8441 新增，一般 CONNECT 沒有這一個
:scheme   = https         # 必須保留
:path     = /ws           # 必須保留——隧道另一端是「端點」不是「host:port」

# 3. 成功的回應
:status   = 200

與一般 CONNECT（給 HTTP proxy 建 TCP 隧道用）的差別在 :protocol 這個新的 pseudo-header，以及必須保留 :scheme 與 :path——因為隧道的另一端不是「某個主機的某個 port」，而是「這台伺服器上的某個 WebSocket 端點」。成功的回應是 200 而不是 101；之後這條 stream 的 DATA frame payload 就是 WebSocket frame。

這個設計有一個很好的副作用：WebSocket 從此共用同一條 HTTP/2 連線，不再各自佔一條 TCP。對瀏覽器來說，這解掉了 HTTP 篇提過的 per-origin 6 連線上限——在 HTTP/1.1 上開六條 WebSocket 就把整個網域的 HTTP 請求餓死了。

3 · HTTP/3：同一套機制換一個載體——RFC 9220

QUIC 篇已經點名這條線的終點。RFC 9220 做的事幾乎是把 8441 原封不動搬到 HTTP/3 上：一樣用 SETTINGS_ENABLE_CONNECT_PROTOCOL 宣告能力、一樣用帶 :protocol 的 Extended CONNECT、一樣拿一條 stream 當隧道。差別在腳下換成了 QUIC，於是這條 WebSocket 隧道順便繼承了 QUIC 的 stream 獨立性與 connection migration——同一條連線上的其他 stream 丟包不會卡住它，手機從 Wi-Fi 切到 4G 也不必重連。

最後一列才是選型重點：8441／9220 在協定上很漂亮，但只要路徑上任何一層（CDN、企業 proxy、舊版 LB）不支援，就會安靜地退回 HTTP/1.1 的老路。所以 2026 年絕大多數 production 的 WebSocket 仍然是「WSS over HTTP/1.1 Upgrade」。

4 · 或者根本不要隧道：WebTransport

把 WebSocket 塞進 HTTP/2 或 HTTP/3 的 stream 裡，解掉的是「連線數」問題，但沒有解掉 WebSocket 自己的一個結構性限制：一條 WebSocket 就是一條有序、可靠的訊息串流。你在上面同時傳一個 10 MB 的檔案和每秒 20 次的游標位置，兩者會互相排隊——這其實就是 HoL Blocking 在應用層又演一次。

WebTransport 的作法是直接把 QUIC 的能力暴露給應用：一個 WebTransport session（也是用 Extended CONNECT 建立，:protocol = webtransport）之下可以開多條雙向／單向 stream，彼此獨立不互相阻塞；此外還提供不可靠的資料報（Datagram）——送出去不保證到、不重傳、不排序，正好對應遊戲狀態與音視訊那種「舊資料寧可丟掉」的需求。這兩件事都是 WebSocket 在設計上給不了的。

TCP/UDP 篇定調過「TCP 不保證訊息邊界，framing 是應用的事」。WebSocket 就是那句話的一個具體交卷。

TCP/UDP 篇談可靠性機制時已經論證過：TCP 給的是位元組串流，兩次 send() 可能被合併成一次 recv()、一次 send() 也可能被拆成三次收到——「黏包」不是 bug，是抽象本身如此。所以任何跑在 TCP 上的協定都得自己劃邊界：長度前綴、分隔符，或固定長度。WebSocket 選的是長度前綴，而且把長度欄位設計成變長的：

最小的一個 frame 只有 2 bytes 標頭（伺服器→客戶端、payload ≤ 125 bytes）；客戶端送出時加上 4 bytes 的 masking key，最小 6 bytes。對照 HTTP 篇介紹過的 HTTP/2 固定 9-byte 標頭——兩者的設計目標不同：HTTP/2 的 frame 要攜帶 Stream ID 做多路復用，長度固定換解析簡單；WebSocket 沒有多路復用要做，於是把每個 byte 都省下來，因為它預期的負載是「每秒好幾十則的小訊息」。

三個值得自己推一次的地方：(1) 把批量倍數從 5 調到 6，payload 從 105 跨到 126 bytes，標頭立刻從 6 跳到 8——「最小 2 bytes」是下限不是常態。(2) 切到 CLOSE 再把批量倍數往上推，理由文字超過 123 bytes 就違規，因為 control frame 的 125 bytes 上限要先扣掉 2 bytes 狀態碼。(3) 打開分片：payload 沒變，標頭卻被乘上片數——分片是為了不佔死連線，不是為了省位元組。

1 · opcode：資料 frame 與 control frame

「control frame 可以插隊」這一列很容易被略過，但它是保活能成立的前提：正在傳一個 8 MB 的分片訊息時，Ping 仍然可以插進去、Pong 仍然可以回來，否則大訊息一送就會被誤判為連線已死。

2 · 為什麼客戶端必須 mask，伺服器卻不必

RFC 6455 規定：客戶端送往伺服器的每一個 frame 都必須 masked（帶 4 bytes 隨機 key，payload 逐位元組 XOR），伺服器送往客戶端的則一律不 mask。這個不對稱的規定常被誤讀成「加密」——它跟機密性一點關係都沒有，key 就明文躺在同一個 frame 的標頭裡，任何人都能還原。

3 · frame 之上：訊息，以及協定沒有給你的東西

應用看到的單位是訊息（message）而不是 frame：瀏覽器的 onmessage 只會在一則完整訊息（可能由多個分片組成）到齊後才觸發一次。這是 WebSocket 相對於裸 TCP 最大的便利——你不必自己算長度、不必處理黏包。

但也就到此為止了。有三件在 HTTP/2 上習以為常的事，WebSocket 完全不提供：

結論很一致：WebSocket 提供的是「有邊界的雙向位元組管道」，不是「訊息系統」。上面這三格外加投遞保證，正是 MQTT 選擇放進協定裡的東西（MQTT 篇會展開）。

長連線最大的敵人不是斷線，而是「它明明已經斷了，兩端卻都以為還活著」。

TCP/UDP 篇談 Socket API 的章節已經把前提立好：因為「外往內」預設不通，即時系統一律採用客戶端主動建立並長期維持一條連線的模型；而那裡的 NAT callout 也定調了為什麼這條連線不能安靜——心跳既是活性偵測，也是「餵養」NAT 映射的手段。NAT 表項與有狀態防火牆的連線紀錄都有 idle timeout，一條完全沒有流量的長連線會在你毫無察覺的情況下被中間設備拆掉。

1 · 三層心跳，各測不同的東西

典型分工：伺服器每 20–30 秒送 Ping（瀏覽器會自動回 Pong，不需要前端寫任何程式碼），用來清掉殭屍連線並餵 NAT；瀏覽器端則送應用層 heartbeat，因為它沒有別的選擇。兩個方向都要做——只有一方偵測，另一方的資源就會洩漏。

2 · half-open：最難查的那一種斷線

Half-open 指的是一端已經消失（行程被 kill、機器斷電、路徑被中間設備靜默拆掉），但另一端沒有收到任何 FIN 或 RST。此時它的 socket 仍是 ESTABLISHED、readyState 仍是 OPEN、事件迴圈一片安靜——沒有任何錯誤事件會被觸發。它會一直維持這個狀態，直到你嘗試寫入並等到 TCP 重傳耗盡（可能是好幾分鐘），或是永遠。

3 · 關閉交握與 close code 體系

乾淨的關閉是雙向的：一方送出 CLOSE frame（payload = 2 bytes 狀態碼 + UTF-8 理由，因為 control frame ≤125 bytes，理由最多 123 bytes），對方回一個 CLOSE，然後由伺服器先關閉底層 TCP。兩邊都收到 CLOSE 才算 clean close——瀏覽器的 CloseEvent.wasClean 就是在說這件事。

重連策略應該按 close code 分流，而不是「一律重連」。把 1000 也拿去重連，就會做出一個永遠關不掉的連線。

一種是連線還在但送不出去，一種是連線沒了。兩種都不能靠「等一下應該就好了」處理。

1 · Backpressure：WebSocket 只給你一個數字

TCP/UDP 篇談 Backpressure 的章節已經把因果鏈講完：接收端應用讀得慢 → 接收端核心 buffer 滿 → rwnd 縮到 0 → 發送端不能再送 → 發送端 send buffer 滿 → write() 回 EAGAIN。那裡也列了四種處理策略（暫停生產／丟棄與合併／有界佇列+斷線／降級取樣），並下了結論：把 backpressure 吃掉，等於把問題換成 OOM。這裡不重講機制，只補 WebSocket 這一層的三個特殊之處。

伺服器端情況好一些：多數 runtime 允許暫停讀取 socket，讓壓力真的反壓到 TCP rwnd。但要小心副作用——停止讀取會把整條連線上的所有訊息一起卡住，包含對方的 Ping，於是你可能被對端判定為 half-open 而斷線。

let ws, attempt = 0;
function connect() {
  ws = new WebSocket("wss://chat.example.com/ws?ticket=" + ticket, ["chat.v2"]);
  ws.onopen    = () => { attempt = 0; send({ type: "resume", lastSeq }); };
  ws.onclose   = (e) => {                    // 1000/1001 有交握；1006 = 沒收到 CLOSE frame
    if (e.code === 1000 || e.code === 4001) return;      // 正常關閉／憑證失效：不重連
    const delay = Math.min(30000, 500 * 2 ** attempt++) * (0.5 + Math.random() * 0.5);
    setTimeout(connect, delay);              // exponential backoff + full-ish jitter
  };
}
function send(msg) {                         // send() 不會回 EAGAIN，只會無聲堆記憶體
  if (ws.readyState !== WebSocket.OPEN) return queue(msg);
  if (ws.bufferedAmount > 1_000_000) return drop(msg);   // 有界：寧可丟也不要 OOM
  ws.send(JSON.stringify(msg));
}

十五行裡塞了本節的全部重點：按 close code 決定要不要重連、退避要帶 jitter、重連後第一件事是宣告 lastSeq、送出前檢查 bufferedAmount。至於 drop() 要丟最舊的、還是把同一支股票的報價合併成最新一筆，就是 TCP/UDP 篇那張策略表的選擇題。

2 · 重連：退避、抖動，以及為什麼一定要抖

偵測到斷線之後立刻重連，是每個人第一版都會寫的錯誤。正確的作法是指數退避（exponential backoff）——每次失敗把等待時間加倍，並設一個上限：

前半段（min(cap, base * 2 ^ attempt)）讓失敗成本隨次數遞減；真正關鍵的是後面那個乘上隨機數的 jitter（抖動）。理由是：造成大量客戶端同時斷線的事件，通常是同一個事件——一次伺服器重啟、一次 LB 切換、一次網路抖動。這些客戶端的計時器因此完全同相，沒有 jitter 的話它們會在同一毫秒一起回來，把剛起來的伺服器再打掛一次，然後同步得更整齊地再來一輪。把重連時刻隨機攤平，是唯一能打破這個相位鎖定的手段。（這個現象叫重連風暴（Reconnect Storm），它在單機視角只是一個係數，到了多節點叢集才會真正露出獠牙——連線擴充篇會完整處理。）

3 · 重連 ≠ 恢復：連線狀態要怎麼接回去

新的 TCP 連線建起來、onopen 觸發了，但這只代表管道通了。斷線那段時間伺服器推的訊息去哪了？客戶端的訂閱列表在伺服器那邊還在不在？這些都不是協定管的事。

共同前提：伺服器願意為斷線的客戶端保留多久的狀態，決定了你能給出多強的恢復保證。保留視窗一定有上限，所以每一種策略都要設計「太舊了，請走全量重載」這條退路。這也是為什麼 resume 訊息的回應必須明確告訴客戶端是補發還是請重來。

還有一件事在單機視角看不出殺傷力：slow consumer（TCP/UDP 篇已定義）。一個手機在地鐵裡的使用者，會讓 gateway 上屬於他的那條連線的發送佇列持續堆積；在 fan-out 場景下，每一則廣播訊息都要為他複製一份，於是一個慢客戶端的成本會隨廣播頻率放大。單機上的答案就是那張策略表裡的「有界佇列 + 斷線」——犧牲他一個，保全其他人。至於當這件事發生在幾十台 gateway 上、而訊息還要跨節點分發時會變成什麼樣子，留給連線擴充篇。

整條連線的一生裡，只有第一個封包是 HTTP。你所有的認證機會都擠在那一瞬間——而瀏覽器還綁住了你的手。

好消息：交握是一個真正的 HTTP 請求，所以 Cookie 會自動帶上，既有的 session 機制可以直接沿用。壞消息有兩個，而且都很尖銳。

1 · 瀏覽器不讓你設自訂標頭

第二個壞消息：瀏覽器的 WebSocket 建構子只有兩個參數——new WebSocket(url, protocols)。沒有地方放 Authorization: Bearer …。（伺服器端與行動端 SDK 沒有這個限制，可以自由設標頭；這純粹是瀏覽器 API 的約束。）於是實務上出現四條路：

選擇順序通常是：同站部署用 Cookie + Origin 驗證；跨站或行動端用 Ticket 模式。把長效 JWT 直接掛在 query string 上是最省事、也最容易在資安檢查時被抓出來的做法。

2 · 連線活了八小時，token 三十分鐘就過期了

請求／回應模型裡，權杖過期是自然的：下一個請求帶新的就好。長連線把這個假設打破了——交握時驗過一次，不等於接下來八小時都該被允許。使用者可能已經登出、被停權、權限被收回，而那條連線還在推訊息給他。三種常見處理：

共同原則：認證發生在交握，授權必須持續。把兩者混為一談，就會做出「踢不掉的已停權使用者」。

3 · 伺服器端的 connection state：本篇最後一個伏筆

每接受一條 WebSocket 連線，伺服器就得在記憶體裡掛一份狀態：

六項的來源各不相同——認證給的、應用給的、保活給的、緩衝給的——但存放位置只有一種：持有這條 socket 的那一個行程的記憶體。真正該盯著看的是最後一列的乘數：這整份清單要乘上連線數。

單機上這完全不是問題——十萬條連線各配幾 KB 也就是幾百 MB，TCP/UDP 篇的 epoll 早就解決了「同時等很多連線」。真正的問題是這份狀態只存在於那一台機器的記憶體裡：它不能被別台機器讀到，也不會在行程重啟後留下來。一旦你要放兩台機器在負載均衡器後面，「這則訊息該送給誰」就變成「持有那條連線的是哪一台」——這是本篇刻意不處理的問題。

把需求逐條換算成分數與帳單：同一組規則同時回答「該選誰」與「這個選擇每天要付多少位元組」。

前面六節談的都是「WebSocket 怎麼運作」。但在真實專案裡，你要先回答的是更前面那一題：這個需求到底該不該用 WebSocket。下面這台決策器把第 8 節的對照表拆成 12 條加權規則，逐條套在你描述的需求上，算出 WebSocket／SSE／長輪詢／HTTP/2 串流／WebTransport 五個候選的分數走勢；同一組輸入還會被拿去算四筆帳——每則訊息的框架開銷比、全體連線的每日流量、建議的 ping 間隔，以及重連風暴的峰值。其中「需要斷線續傳」那條規則為什麼給 SSE 加分，SSE 篇談 Last-Event-ID 自動續接的那一節已經解釋過：那是規範內建的行為，而 WebSocket 這一側要靠第 5 節整節手工重建。

三個值得自己動手翻面的地方：(1) 只把方向性切成「伺服器單向推送」，勝出者就從 WebSocket 翻成 SSE——這正是第 8 節那句「客戶端需不需要低延遲地說話」的量化版本。(2) 在單向狀態下再打開「需要二進位」，兩個候選會擠到 8 分以內、結論條改口說「兩者都可行」，因為 SSE 只送 UTF-8 文字，二進位得先 base64，膨脹幅度 demo 會直接算給你看。(3) 把訊息大小拉到 16 bytes：分數幾乎不動，但長輪詢的開銷比會衝到 97% 以上——選型的代價常常不在分數，在帳單。

最該記住的一句是：不是所有即時需求都需要 WebSocket，而且多數不需要。

1 · 四種「即時」的對照

第三列常被低估：SSE 的自動重連與 Last-Event-ID 是規範內建的——瀏覽器斷線後自己回來、並把「我上次收到哪一則」帶給伺服器。這正是本篇花了整整一節（第 5 節）在 WebSocket 上手工重建的東西。而第四列的 HTTP/1.1 六連線限制，在 HTTP/2 的多路復用之後就消失了，這是近年 SSE 明顯復活的主因。

2 · 選型表

共同結構：WebSocket 把「通道」做得很好，但把所有「訊息系統」的問題原封不動留給你——保活、退避、補發、限流，每一項都要自己決定犧牲什麼。

把本篇收攏成一句：WebSocket 用一次 HTTP Upgrade 買到了一條對稱的雙向訊息管道，而它把管道以外的一切都留給了你。framing 幫你補回 TCP 拿掉的訊息邊界，Ping/Pong 幫你戳一下對面還在不在，close code 幫你分辨「談完了」與「線斷了」——除此之外，保活週期、退避曲線、補發視窗、限流策略，全部是應用層的設計題。

這套設計在瀏覽器與伺服器之間非常合身。但把同一套東西搬到一顆靠電池活著的感測器上，帳單就翻過來了：WebSocket 預設你有完整的 TLS 與 HTTP 堆疊、一顆可以常時醒著跑心跳的 CPU，以及不計較每個位元組的頻寬。更關鍵的是，它從頭到尾只負責「把位元組送到對面」——訊息會不會重複、掉線那段時間的訊息去了哪裡、裝置突然斷電時誰替它說最後一句話，協定一概不管。當場景變成幾十萬顆在不穩定網路上時醒時睡的裝置，需要的是一個把投遞保證（QoS）與 pub/sub 語義直接做進協定裡的東西——下一篇進入 MQTT。

而即使場景就是瀏覽器與 WebSocket，本篇談的一切都建立在一個隱含前提上：連線的另一端只有一台伺服器。使用者是誰、訂了哪些 topic、最後收到第幾則——這些狀態全都活在那一台機器的記憶體裡（第 6 節的最後一小節）。一旦要放到多台機器後面，Sticky Session 要不要做、訊息怎麼跨節點 fan-out 到「持有那條連線的那一台」、發版時怎麼 Graceful Drain（優雅排空）而不引爆重連風暴，就是完全另一個層級的問題了——連線擴充篇會處理它。