協議各給多少保證

SSE（Server-Sent Events）把重連寫進協議本身。WHATWG 的規範定義：連線斷掉時 user agent 自動重連、重連時把最後收到的 event id 放進 Last-Event-ID header 送回 server、server 據此可從斷點往後補送（見 11.C55）。所以 SSE 對消費者的承諾是「自動重連加一個補送的協商鉤子」。要注意這個承諾的邊界：spec 只保證瀏覽器會送 Last-Event-ID、實際補不補送由 server 有沒有實作 replay 決定；而且 SSE 是單向的、client 要傳資料回 server 得另開通道。

WebSocket 走相反的路：給雙向管線、不給保證。RFC 6455 只定義 handshake 與 framing、對投遞保證、ack（收到確認）、重連、斷點續傳全部沉默（見 11.C56）。這個沉默是設計、不是遺漏 —— 可靠性語意留給應用層。這代表每個用 WebSocket 的服務都要自己蓋一套：Slack 的 Socket Mode 在 WebSocket 上加了 envelope ack（每則事件回一個確認）、未 ack 就 retry、多連線熱備、斷線前預警（見 11.C57）—— 這套是 Slack 自己補的、不是 WebSocket 標準行為、換一個 vendor 補的方式又不一樣。

long-polling 是把普通 HTTP 請求 hold 住到有事件才回。RFC 6202 講清楚它的機制代價：每則訊息一次完整 request/response、帶完整 HTTP headers（payload 小時 header 佔比高）、最大延遲跨三段網路傳輸、每個 client 佔一條連線（見 11.C58）。這些重量是機制決定的、不是實作品質問題。它的價值在相容性下限：WebSocket 連線不保證每個環境都建得起來（少數受限網路 —— 舊企業 proxy、深度封包檢查 —— 仍可能擋）、所以 Socket.IO 預設先用 long-polling 建連、再嘗試 upgrade 到 WebSocket（見 11.C59；這是 Socket.IO 的策略、有些 vendor 反向、先試 WebSocket 再退回）。

本文聚焦這三個已成熟的主流。WebTransport（HTTP/3 之上的新興雙向 transport）正在補 WebSocket 的多 stream 與 datagram 缺口、但瀏覽器與生態支援仍在成熟；HTTP/2 Server Push 已被主流棄用退場。兩者都不進本文的選型、但值得知道它們落在光譜的哪一端。

承諾差異並排

把三者的承諾攤成一張表。下表依各機制的一手定義（RFC 6455、RFC 6202、WHATWG SSE spec）整理、不是單一 vendor 的對照宣傳。

表只是索引、每一格的成立條件要回到情境判讀。以「重連」欄為例：SSE 的「協議內建」對消費者是零成本的自動重連、但補送的完整性要 server 端配合；WebSocket 的「應用層自建」意思是這件事跑不掉、Slack Socket Mode 那套 ack 加 retry 是最低成本、不是可選；long-polling 沒有「重連」這個概念、因為每則訊息本來就是一次新請求、斷線在下一次請求自然癒合、代價是延遲與 header 開銷。

選型：對到消費者形狀

三條承諾線對到三種消費者形狀。消費者只需要 server 單向推、又想要開箱即用的重連（儀表板、通知流、log tail）—— SSE 的承諾剛好、不必自己蓋重連。消費者需要雙向、低延遲、高頻互動（協作編輯、遊戲、互動終端）—— WebSocket 給你管線、但要接受「可靠性得自己蓋」這筆帳、參考 Slack 那套 ack 加 retry 的形狀。消費者在不可控的網路環境、WebSocket 不保證連得上 —— 要一條相容性 fallback、long-polling 是那個下限、常搭配 transport negotiation（能 upgrade 就 upgrade、方向因 library 而異）。

這三格對應 11.2 消費者形狀軸 的推送情境。共同的判讀是：這三種都不自帶「訊息一定不漏」的保證 —— SSE 的補送、WebSocket 的 ack、都要 server 或應用層主動實作。真的要「事件一定送達、可重放」的語意、那是佇列的責任、路由到 03 訊息佇列、不是在推送機制上硬蓋。

下一步路由

• server 對 server 的事件推送：webhook 對外承諾
• 消費者形狀選型軸：11.2 風格選型總覽
• 要可靠送達與重放的事件語意：03 訊息佇列
• 案例原文：模組十一案例庫

投遞保證不是預設

webhook 不一定會重試 —— 這是採用前最該先確認的承諾。GitHub 明文（文件裡重述兩次）不自動重投失敗的 webhook、失敗條件是 server down 或回應超過 10 秒、補救要你手動重送或自寫排程查 API 補投（見 11.C61）。對照 Stripe：live mode 對失敗投遞重試最多三天、指數退避（見 11.C60）。同樣叫 webhook、一個試三天、一個一次都不重試。

重試的「形狀」本身就是一條要讀清楚的承諾。四個 vendor 四種形狀：Stripe 的長視窗指數退避、Slack 的固定三次（幾乎立即、1 分鐘後、5 分鐘後、見 11.C62）、GitHub 的完全不重試、Shopify 連投遞本身都不保證（見 11.C63）。假設「webhook 會自動重試到成功」、會讓你漏事件卻不自知。payload 格式層有 CloudEvents 這類標準化嘗試、但它標準化的是事件信封的欄位、不是投遞語意 —— 重試、ack、去重這些承諾仍逐 vendor 各異、還是得逐家讀。

consumer 要扛的五件事

webhook 把可靠性的一部分交給 consumer 自己扛、有五件事跑不掉。

去重（冪等）是第一件。at-least-once 的投遞會重複、vendor 明文要你用某個 header 當冪等 key 去重 —— Stripe 用 event ID、Shopify 指定 X-Shopify-Webhook-Id、GitHub 給 X-GitHub-Delivery GUID。就算 GitHub 不自動重試、手動重投也會重複、去重照樣跑不掉。這條對到 11.8 API 層冪等設計 的 consumer 側。

不依賴順序是第二件。ordering 不保證是通則、Stripe 與 Shopify 都明文（Shopify 建議用 updated_at 自己排）—— 事件處理邏輯不能假設收到的順序等於發生的順序。

快速 ack（回覆確認收到）是第三件：慢等於失敗。Slack 寫死 3 秒、GitHub 10 秒、超過就算投遞失敗。這逼出「先回 2xx、再背景處理」的拆分、複雜邏輯不能擋在 ack 前面、否則一個慢查詢就讓整批事件被判失敗。

簽章驗證是第四件。webhook 是打到你公開 URL 的請求、要驗它真的來自該 vendor。每個 vendor 一套 HMAC（雜湊訊息鑑別碼）方案（Stripe-Signature、GitHub 的 X-Hub-Signature-256、Shopify 的 X-Shopify-Hmac-Sha256）—— header 名不同、驗法類似：用雙方共享的 secret 對 body 算一段雜湊、比對請求帶的簽章、對不上就丟。簽章之外還有一格常被略過：驗簽章通過只證明內容沒被改、不證明這是新的請求，要擋 重放 得另外檢查 vendor 附的 timestamp 是否在容忍窗口內。窗口要開多寬有上下界可以換算、比對簽章那一行要用什麼函式、以及對方的文件與實際送出的內容不一致時怎麼辦，見 7.35 簽章對接的驗證收斂。

對帳兜底是第五件。Shopify 文件最直接：投遞不保證、app 可能漏事件、要另備 reconciliation（對帳）或 polling 補漏。webhook 是盡力而為的推送、要做到不漏、consumer 得在 webhook 之外自備對帳。

採用前要讀完的四個承諾

採一個 vendor 的 webhook 前、把承諾讀成四題：重試是什麼形狀（三天、三次、還是不重試）、ack timeout 幾秒、用哪個 header 去重、投遞保不保證。這四題的答案決定 consumer 端要蓋多少機制 —— 不讀清楚就上、會在漏事件或重複處理時、才發現承諾跟假設的不一樣。本文引的具體數字（三天、3 秒、10 秒、固定三次）是各 vendor 當前的承諾、採用前以官方 docs 現值為準。

反過來當 producer、要決定對外推事件用不用 webhook：適不適合不取決於事件關不關鍵、而取決於 consumer 端能不能補齊冪等與對帳 —— Stripe 用 webhook 推付款這種最關鍵的事件、靠的正是 consumer 側的去重與對帳補到接近可靠。真正把 webhook 排除掉的、是「需要 producer 端就保證有序、durable、可重放」的場景：那種可靠語意 webhook 這種盡力而為的形狀補不出來、該換有 durable 保證的佇列 —— 見 03 訊息佇列。

下一步路由

• 簽章原語的選型（這個機制擋得住誰、金鑰放哪一格）：7.28 密碼學原語選型
• 持久連線的推送機制：持久連線推送
• 錯誤與投遞承諾的雙向框架：11.11 Status 與錯誤的雙向契約
• consumer 側的冪等設計：11.8 API 層冪等設計
• 要可靠送達與重放的事件語意：03 訊息佇列
• 各家去重 header 名稱不同只是命名之爭，重送回什麼才是語意之爭：Idempotency key 標準化之爭
• 案例原文：模組十一案例庫