MCP 流式 HTTP 協議深入研究

MCP 引入了一個全新的流式 HTTP 傳輸層，相比原來的 HTTP+SSE 傳輸機制有了顯著改進。本文將詳細分析該協議的設計理念、技術細節及其實際應用場景。

模型上下文協議（MCP） 是一種用於 AI 模型與工具之間通信的標準協議。隨着 AI 應用變得越來越複雜並廣泛部署，原有的通信機制面臨一系列挑戰。GitHub 上的 PR #206 引入了一個全新的流式HTTP傳輸層，相比原來的 HTTP+SSE 傳輸機制有了顯著改進。本文將詳細分析該協議的設計理念、技術細節及其實際應用場景。

1、原始 HTTP+SSE 傳輸機制及其侷限性

在原始的 MCP 實現中，客戶端和服務端通過兩個主要通道進行通信：

• HTTP 請求 / 響應：客戶端通過標準 HTTP 請求向服務器發送消息。

• 服務器發送事件（SSE）：服務器通過專用的/sse端點向客戶端推送消息。

儘管這種設計簡單直觀，但它存在幾個關鍵問題：

• 不支持重新連接 / 恢復

當 SSE 連接斷開時，所有會話狀態都會丟失，迫使客戶端重新建立連接並重新初始化整個會話。例如，在一個正在進行的大文件分析任務中，由於不穩定的 WiFi，整個過程可能會完全中斷，用戶需要重新啓動整個流程。

• 服務器必須維持長連接

服務器必須爲每個客戶端維持長期的 SSE 連接，導致高併發情況下資源消耗巨大。當服務器需要重啓或擴展時，所有連接都會中斷，影響用戶體驗和系統可靠性。

• 服務器只能通過 SSE 發送消息

即使對於簡單的請求 - 響應交互，服務器也必須通過 SSE 通道返回信息，這造成了不必要的複雜性和開銷。某些環境（如雲函數）不適合維護長期的 SSE 連接。

• 基礎設施兼容性限制

許多現有的 Web 基礎設施——如 CDN、負載均衡器和 API 網關——可能無法正確處理長期的 SSE 連接。企業防火牆可能會強制終止超時的連接，導致服務不可靠。

2、流式 HTTP：設計與原則

流式 HTTP 基於以下核心原則構建：

• 最大化兼容性：無縫集成到現有的 HTTP 生態系統中。

• 靈活性：支持無狀態和有狀態模式。

• 資源效率：按需分配資源，避免不必要的長期連接。

• 可靠性：支持重新連接和會話恢復。

2.1 主要改進

與原始機制相比，流式 HTTP 引入了幾個關鍵增強功能：

1. 統一端點：移除專用的/sse端點，通過單一端點（如/message）完成所有通信。

2. 按需流式傳輸：服務器可以選擇返回標準 HTTP 響應或升級爲 SSE 流。

3. 會話識別：引入會話 ID 機制以支持狀態管理和恢復。

4. 靈活初始化：客戶端可以通過空 GET 請求主動初始化 SSE 流。

2.2 技術細節

流式 HTTP 的工作流程如下：

會話初始化：

• 客戶端向/message端點發送初始化請求。

• 服務器可能會生成並返回會話 ID 給客戶端。

• 會話 ID 用於後續請求中標識會話。

客戶端到服務器通信：

• 所有消息都通過 HTTP POST 請求發送到/message端點。

• 如果存在會話 ID，則將其包含在請求中。

服務器響應方式：

• 標準響應：返回直接的 HTTP 響應，適用於簡單的交互。

• 流式響應：升級連接爲 SSE，發送一系列事件後關閉。

• 長期連接：保持 SSE 連接以持續傳遞事件。

主動 SSE 流建立：

• 客戶端可以通過向/message端點發送 GET 請求來主動建立 SSE 流。

• 服務器可以通過此流推送通知或請求。

連接恢復：

• 如果連接斷開，客戶端可以使用之前的會話 ID 重新連接。

• 服務器可以恢復會話狀態並繼續之前的操作。

3、實際應用場景

3.1 無狀態服務器模式

場景：簡單的工具 API 服務，如數學計算或文本處理。

實現：

客戶端                                  服務器
   |                                    |
   |-- POST /message (計算請求) -------->|
   |                                    |-- 執行計算
   |<------- HTTP 200 (結果) ------------|
   |                                    |

優勢：最小化部署，無需狀態管理，適合無服務器架構和微服務。

3.2 流式進度反饋模式

場景：長時間運行的任務，如大文件處理或複雜的 AI 生成。

實現：

客戶端                                  服務器
   |                                    |
   |-- POST /message (處理請求) --------->|
   |                                    |-- 開始處理任務
   |<------- HTTP 200 (SSE開始) ---------|
   |                                    |
   |<------- SSE: 10% 進度 --------------|
   |<------- SSE: 30% 進度 --------------|
   |<------- SSE: 70% 進度 --------------|
   |<------- SSE: 完成 + 結果 -----------|
   |                                    |

優勢：提供實時反饋，而無需永久連接狀態。

3.3 複雜 AI 會話模式

場景：需要上下文維護的多輪 AI 助手。

實現：

客戶端                                  服務器
   |                                    |
   |-- POST /message (初始化) ----------->|
   |<-- HTTP 200 (會話ID: abc123) ------|
   |                                    |
   |-- GET /message (會話ID: abc123) ---->|
   |<------- SSE流已建立 ---------------|
   |                                    |
   |-- POST /message (Q1, abc123) ------->|
   |<------- SSE: 思考中... -------------|
   |<------- SSE: 回答1 -----------------|
   |                                    |
   |-- POST /message (Q2, abc123) ------->|
   |<------- SSE: 思考中... -------------|
   |<------- SSE: 回答2 -----------------|

優勢：維護會話上下文，支持複雜交互，並能實現水平擴展。

3.4 斷連恢復模式

場景：在不穩定網絡環境中的 AI 應用。

實現：

客戶端                                  服務器
   |                                    |
   |-- POST /message (初始化) ----------->|
   |<-- HTTP 200 (會話ID: xyz789) -------|
   |                                    |
   |-- GET /message (會話ID: xyz789) ---->|
   |<------- SSE流已建立 ---------------|
   |                                    |
   |-- POST /message (長時間任務, xyz789)|
   |<------- SSE: 30% 進度 --------------|
   |                                    |
   |     [網絡中斷]                     |
   |                                    |
   |-- GET /message (會話ID: xyz789) ---->|
   |<------- SSE流重新建立 --------------|
   |<------- SSE: 60% 進度 --------------|
   |<------- SSE: 完成 -----------------|

優勢：在弱網絡條件下提高可靠性，提升用戶體驗。

4、流式 HTTP 的主要優勢

4.1 技術優勢

1. 簡化實現：可以在標準 HTTP 服務器上工作，無需特殊要求。

2. 資源高效：按需分配資源，避免爲每個客戶端維持長期連接。

3. 基礎設施兼容性：與現有 Web 基礎設施（CDN、負載均衡器、API 網關）配合良好。

4. 水平可擴展性：通過消息總線路由請求到不同的服務器節點。

5. 逐步採用：服務提供商可以根據需求選擇實現複雜度。

6. 重新連接支持：啓用會話恢復以提高可靠性。

4.2 商業優勢

1. 降低運營成本：減少服務器資源消耗，簡化部署架構。

2. 提升用戶體驗：通過實時反饋和可靠連接改善體驗。

3. 廣泛應用：適用於從簡單工具到複雜 AI 交互的各種場景。

4. 可擴展性：支持更多樣化的 AI 應用場景。

5. 開發者友好：降低實施 MCP 的技術門檻。

5、實現參考

5.1 服務器端實現亮點

端點設計：

• 實現單一/message端點用於所有請求。

• 支持 POST 和 GET HTTP 方法。

狀態管理：

• 設計會話 ID 生成和驗證機制。

• 實現會話狀態存儲（內存、Redis 等）。

請求處理：

• 解析請求中的會話 ID。

• 確定響應類型（標準 HTTP 或 SSE）。

• 處理流式響應的內容類型和格式。

連接管理：

• 實現 SSE 流的初始化和維護。

• 處理斷開和重新連接邏輯。

5.2 客戶端實現亮點

請求構造：

• 構符合協議的消息

• 正確包含會話 ID（如適用）

響應處理：

• 檢測響應是標準 HTTP 還是 SSE

• 解析和處理 SSE 事件

會話管理：

• 存儲和管理會話 ID

• 實現重新連接邏輯

錯誤處理：

• 處理網絡錯誤和超時

• 實施指數退避重試策略

6、結束語

可流式傳輸的 HTTP 傳輸層代表了 MCP 協議的重大演進。通過結合 HTTP 和 SSE 的優點並克服其侷限性，它爲 AI 應用程序提供了一個更靈活可靠的通信解決方案。它不僅解決了原始傳輸機制的問題，還爲未來更復雜的 AI 交互模式奠定了基礎。

該協議的設計體現了實用性，平衡了技術複雜性和與現有 Web 基礎設施的兼容性。其靈活性允許開發人員根據需要選擇最合適的實現方式，從簡單的無狀態 API 到複雜的交互式 AI 應用程序。

隨着此 PR 的合併，MCP 社區的技術生態系統將變得更加豐富，降低更多開發人員採用的門檻。在不久的將來，我們預計基於可流式傳輸 HTTP 的 MCP 實現將在各種 AI 應用程序中得到廣泛應用。

聯繫我

最後，推薦大家關注一下開源項目：LangChat，Java 生態下的 AIGC 大模型產品解決方案。

• LangChat 產品官網：https://langchat.cn/

• Github: https://github.com/TyCoding/langchat

• Gitee: https://gitee.com/langchat/langchat

• 微信：LangchainChat

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/uY0_tzroFxgv2T6yjzSpYA