# HTTP 明明是客戶端找伺服器，伺服器怎麼反過來推送？答案是兩條 SSE 連接 這是 Anthropic Academy《Model Context P… · @swordBluesy · TwKit

@swordBluesy

# HTTP 明明是客戶端找伺服器，伺服器怎麼反過來推送？答案是兩條 SSE 連接 這是 Anthropic Academy《Model Context Protocol: Advanced Topics》第 12 課的實作教學，標題直譯是《StreamableHTTP in depth（深入 StreamableHTTP）》。先把結論放在前面，因為它反常識： **StreamableHTTP 用 Server-Sent Events 繞過了 HTTP 的單向限制——初始化之後，客戶端發一個 GET 請求建立 SSE 連接，形成一條伺服器可以隨時推送消息的長連接，伺服器發起的請求就從這條通道走。** 先說清詞。**Server-Sent Events（SSE，伺服器推送事件）**，是一種伺服器通過一條長連接持續向客戶端推送消息的 HTTP 機制。**mcp-session-id（會話編號）**，是伺服器在初始化結果裡給的特殊標頭，唯一標識一個客戶端，之後所有請求都要帶。**主 SSE 連接（main SSE connection）**，是初始化後建立的、一直開著的那條連接，專門走伺服器發起的請求。**工具專屬 SSE 連接（tool-specific SSE connection）**，是每個工具調用另外建立的連接，工具結果一發就自動關閉。 一個真實例子：客戶端發 Initialize Request，伺服器回 Initialize Result，裡面含特殊的 mcp-session-id 標頭；客戶端再發帶 session ID 的 Initialized Notification，初始化完成。之後客戶端發 GET 請求建立 SSE 連接，伺服器從此可以通過這條持久通道發請求、通知等消息；工具調用時另建一條工具專屬連接，結果一發就關。 他們還點名了一種「眼熟的舊路線」：以為 HTTP 上伺服器發起消息是靠什麼魔法，或者以為一條連接就能包辦一切。官方的拆台很直接：**繞法就是雙連接模型**，主連接一直開著走伺服器發起的請求，工具連接用完就關，兩條各有分工。 先把話說全：不是所有消息都走同一條連接。分流規則是這樣的： - 進度通知走主 SSE 連接； - 日誌消息與工具結果走工具專屬 SSE 連接； - 兩條連接的請求都要帶 session ID，少了就對不上號。 ## 一、雙連接模型沒分清的三種翻車方式 - **進度通知找不到路**：以為進度走工具連接，工具結果一發連接就關了，進度跟著斷。 - **session ID 沒帶上**：初始化之後的請求忘了帶 mcp-session-id，伺服器認不出是哪個客戶端。 - **限制性配置破壞繞法**：stateless_http、json_response 設為 True，直接破壞 SSE 繞法機制，伺服器發起的功能全滅。 ## 二、替代方案：初始化、建連接、分流，三步走通 初始化三步：客戶端發 Initialize Request → 伺服器回 Initialize Result，含 mcp-session-id 標頭 → 客戶端發帶 session ID 的 Initialized Notification。建連接一步：初始化後客戶端發 GET 請求建立 SSE 連接，形成伺服器可隨時推送的長連接。分流一步：主 SSE 連接走伺服器發起的請求、一直開著；每個工具調用另建工具專屬連接，結果一發就關；進度通知走主連接，日誌與工具結果走工具連接。三步做的是同一件事：**先認人，再開通道，最後按消息種類分流**。 ## 三、目標形態：系統自動管理多條連接 理想狀態是開發者不用手工管連接：初始化後所有請求都帶 session ID，系統自動管理多條 SSE 連接，消息按種類自動分流。但「自動」的前提是理解模型——不知道雙連接模型，調試時看到兩條連接會以為是 bug，優化時也不知道該動哪一條。 ## 四、遷移三步走：從單連接理解改成雙連接理解 ### 第一步：先把初始化三步走對 session ID 拿到手，之後所有請求都要帶，這是雙連接模型的根。 ### 第二步：把消息分流規則寫進調試清單 進度通知查主連接，日誌與結果查工具連接，查錯先問消息走哪條，別兩條一起猜。 ### 第三步：限制性配置開之前先算代價 某些場景可能想開 stateless_http 或 json_response，但它們會破壞 SSE 繞法、限制全部依賴伺服器向客戶端通信的功能，開之前先列出代價。 ## 五、團隊怎麼共建同一套連接理解 雙連接模型最大的坑不是技術，是調試時各查各的：進度丟了查工具連接，日誌丟了查主連接。團隊要先約好三條：消息分流規則寫進調試手冊，不要憑感覺查；session ID 的傳遞寫成共用程式碼，不要每個請求各帶各的；限制性配置的取值要評審，改了就要重新驗伺服器發起的功能。 ## 六、官方工具包之外還要記得的事 這課沒有給出完整工具箱，但它把邊界講得很清楚：StreamableHTTP 比其他傳輸複雜，正因為要繞 HTTP 限制；理解雙連接模型對調試與優化很關鍵；建應用時記住初始化後所有請求都要 session ID，系統會自動管理多條 SSE 連接。 ## 結尾：原則比架構重要 繞法不是魔法，是模型。**原則比架構重要——先理解雙連接模型，再談調試與優化，模型沒分清，查錯永遠查錯連接。** 可重複的動作規則是：下次調試 StreamableHTTP，先問三句——session ID 帶了嗎、消息走哪條連接、限制性配置開了嗎——三句答得上，問題就定位了一半。 原文連結：https://anthropic.skilljar.com/model-context-protocol-advanced-topics 原文：Anthropic Academy（由 S1哥 編譯） ## S1哥觀點 這課最狠的地方，是它把一堆人的「一條連接包辦一切」幻想一刀砍掉：過去大家以為 HTTP 上就一條道，現在官方說，是兩條，各有分工。真正貴的從來不是多建一條連接的成本，是你按單連接理解調了一整天，進度丟了查工具連接、日誌丟了查主連接，全查錯地方。 我站這一邊：模型要先分清。一個不知道雙連接模型、調試全靠猜的開發者，比一句「我不知道」更危險——前者讓你帶著「已經定位」的錯覺改程式碼，後者至少讓你停下來。 所以問一句：你現在的 StreamableHTTP 調試裡，有幾次是查錯了連接的？評論區報個數，敢不敢說實話。

曝光 302 · 评论 2 · 点赞 2 · 书签 0