MCP 的新傳輸層 - Streamable HTTP 協定詳解

Model Context Protocol (MCP) 是一個用於 AI 模型和工具間通訊的標準協定。隨著 AI 應用的日益複雜和廣泛部署，原有的通訊機制面臨著一系列挑戰。GitHub 上的 PR #206 引入了全新的 Streamable HTTP 傳輸層，這是對原有 HTTP+SSE 傳輸機制的重大改進。本文將詳細解析這個協定的設計思想、技術細節以及實際應用。

原有 HTTP+SSE 傳輸機制及其局限

在原有的 MCP 實現中，客戶端和伺服器通過兩個主要通道通訊：

HTTP 請求/回應 ：客戶端通過標準 HTTP 請求發送訊息到伺服器 伺服器發送事件(SSE) ：伺服器通過專門的 /sse 端點向客戶端推送訊息 主要問題 這種設計雖然簡單直觀，但存在幾個關鍵問題：

不支援斷線重連/恢復

當 SSE 連接斷開時，所有會話狀態丟失，客戶端必須重新建立連接並初始化整個會話。例如，正在執行的大型文件分析任務會因 WiFi 不穩定而完全中斷，迫使用戶重新開始整個過程。

伺服器需維護長連接

伺服器必須為每個客戶端維護一個長時間的 SSE 連接，大量並發用戶會導致資源消耗劇增。當伺服器需要重啟或擴容時，所有連接都會中斷，影響用戶體驗和系統可靠性。

伺服器訊息只能通過 SSE 傳遞

即使是簡單的請求-回應互動，伺服器也必須通過 SSE 通道返回資訊，造成不必要的複雜性和開銷。對於某些環境（如雲函數）不適合長時間保持 SSE 連接。

基礎設施相容性限制

許多現有的 Web 基礎設施如 CDN、負載均衡器、API 閘道等可能不能正確處理長時間的 SSE 連接，企業防火牆可能會強制關閉超時連接，導致服務不可靠。

Streamable HTTP：設計與原理 Streamable HTTP 的設計基於以下幾個核心理念：

最大化相容性 ：與現有 HTTP 生態系統無縫整合 靈活性 ：同時支援無狀態和有狀態模式 資源效率 ：按需分配資源，避免不必要的長連接 可靠性 ：支援斷線重連和會話恢復 關鍵改進 相比原有機制，Streamable HTTP 引入了幾項關鍵改進：

統一端點 ：移除專門的 /sse 端點，所有通訊通過單一端點（如 /message ）進行 按需流式傳輸 ：伺服器可靈活選擇是返回普通 HTTP 回應還是升級為 SSE 流 會話標識 ：引入會話 ID 機制，支援狀態管理和恢復 靈活初始化 ：客戶端可通過空 GET 請求主動初始化 SSE 流 技術細節 Streamable HTTP 的工作流程如下：

會話初始化 ：

客戶端發送初始化請求到 /message 端點 伺服器可選擇生成會話 ID 返回給客戶端 會話 ID 用於後續請求中標識會話 客戶端向伺服器通訊 ：

所有訊息通過 HTTP POST 請求發送到 /message 端點 如果有會話 ID，則包含在請求中 伺服器回應方式 ：

普通回應 ：直接返回 HTTP 回應，適合簡單互動 流式回應 ：升級連接為 SSE，發送一系列事件後關閉 長連接 ：維持 SSE 連接持續發送事件 主動建立 SSE 流 ：

客戶端可發送 GET 請求到 /message 端點主動建立 SSE 流 伺服器可通過該流推送通知或請求 連接恢復 ：

連接中斷時，客戶端可使用之前的會話 ID 重新連接 伺服器可恢復會話狀態繼續之前的互動 實際應用場景 無狀態伺服器模式 場景 ：簡單工具 API 服務，如數學計算、文字處理等。

實現 ：

流式進度回饋模式 場景 ：長時間運行的任務，如大文件處理、複雜 AI 生成等。

實現 ：

複雜 AI 會話模式 場景 ：多輪對話 AI 助手，需要維護上下文。

實現 ：

斷線恢復模式 場景 ：不穩定網路環境下的 AI 應用使用。

實現 ：

Streamable HTTP 的主要優勢 技術優勢 簡化實現 ：可以在普通 HTTP 伺服器上實現，無需特殊支援 資源效率 ：按需分配資源，不需要為每個客戶端維護長連接 基礎設施相容性 ：與現有 Web 基礎設施（CDN、負載均衡器、API 閘道）良好配合 水平擴展 ：支援通過訊息總線路由請求到不同伺服器節點 漸進式採用 ：服務提供者可根據需求選擇實現複雜度 斷線重連 ：支援會話恢復，提高可靠性 業務優勢 降低運維成本 ：減少伺服器資源消耗，簡化部署架構 提升用戶體驗 ：通過即時回饋和可靠連接改善體驗 廣泛適用性 ：從簡單工具到複雜 AI 互動，都有合適的實現方式 擴展能力 ：支援更多樣化的 AI 應用場景 開發友好 ：降低實現 MCP 的技術門檻 實現參考 伺服器端實現要點 端點設計 ：

實現單一的 /message 端點處理所有請求 支援 POST 和 GET 兩種 HTTP 方法 狀態管理 ：

設計會話 ID 生成和驗證機制 實現會話狀態存儲（記憶體、Redis 等） 請求處理 ：

解析請求中的會話 ID 確定回應類型（普通 HTTP 或 SSE） 處理流式回應的內容類型和格式 連接管理 ：

實現 SSE 流初始化和維護 處理連接斷開和重連邏輯 客戶端實現要點 請求構造 ：

構建符合協定的訊息格式 正確包含會話 ID（如有） 回應處理 ：

檢測回應是普通 HTTP 還是 SSE 解析和處理 SSE 事件 會話管理 ：

存儲和管理會話 ID 實現斷線重連邏輯 錯誤處理 ：

處理網路錯誤和超時 實現指數退避重試策略 結論 Streamable HTTP 傳輸層代表了 MCP 協定的重要進化，它通過結合 HTTP 和 SSE 的優點，同時克服二者的局限，為 AI 應用的通訊提供了更靈活、更可靠的解決方案。它不僅解決了原有傳輸機制的問題，還為未來更複雜的 AI 互動模式奠定了基礎。

這個協定的設計充分體現了實用性原則，既滿足了技術先進性要求，又保持了與現有 Web 基礎設施的相容性。它的靈活性使得開發者可以根據自身需求選擇最合適的實現方式，從簡單的無狀態 API 到複雜的互動式 AI 應用，都能找到合適的解決方案。

隨著這個 PR 的合併，MCP 社區的技術生態將更加豐富多樣，也為更多開發者採用 MCP 提供了便利。相信在不久的將來，我們將看到基於 Streamable HTTP 的 MCP 實現在各種 AI 應用中的廣泛應用。

MCP 的新傳輸層 - Streamable HTTP 協定詳解

相關文章

10 個值得關注嘅 MCP Server

什麼是 MCP？

LangChain 的 MCP 適配器