一、前言
在MCP（Model Context Protocol）中，Streamable HTTP和SSE（Server-Sent Events）都是用于實現客戶端與服務器之間通信的傳輸機制。然而，它們在設計、功能以及性能表現上有著顯著的區別。
二、SSE在MCP中的表現
SSE是一種基于HTTP的協議，允許服務器向客戶端推送更新。它非常適合需要實時更新的應用場景，如股票價格更新或社交媒體的新消息通知。在MCP中，SSE通常被用來實現實時的通知或者狀態更新。
SSE的特點：
- 單向通信：SSE主要用于從服務器到客戶端的數據推送，對于客戶端到服務器的請求，則需通過其他方式（例如標準HTTP POST請求）來完成。
- 長連接：為了維持數據流，SSE需要保持一個持續打開的HTTP連接，這可能對服務器資源造成壓力，尤其是在高并發情況下。
- 事件驅動：每個推送的數據包都包含一個事件標識符和數據內容，使得客戶端能夠識別并處理不同的事件類型。
在MCP中使用SSE的一個典型流程是這樣的：
- 客戶端發送一個GET請求到/sse端點以建立連接。
- 服務器接收請求后開始維護這個長連接，并通過此連接向客戶端發送事件。
- 當有新的數據可用時，服務器會將這些數據作為事件推送給客戶端。
- 如果連接斷開，客戶端必須重新發起連接以繼續接收數據。
三、Streamable HTTP在MCP中的表現
Streamable HTTP是對傳統HTTP+SSE的一種改進，旨在解決SSE存在的問題，同時保留其優點。它是為了解決SSE不支持恢復連接、要求服務器保持高可用的長連接等問題而設計的。
Streamable HTTP的特點：
- 雙向通信：Streamable HTTP不僅支持服務器向客戶端推送數據，同時也支持客戶端向服務器發送請求，所有交互都可以通過統一的/message端點進行。
- 按需流式傳輸：服務器可以根據實際需求選擇是否使用SSE進行流式傳輸，而不是強制性的長連接。
- 無狀態服務：Streamable HTTP支持無狀態運行模式，這意味著服務器不需要為每個連接保持長期的狀態信息，從而減輕了服務器的壓力。
- 兼容性：由于基于標準HTTP協議，Streamable HTTP可以很好地與現有的網絡基礎設施集成，比如CDN、API網關等。
在MCP中使用Streamable HTTP的一個典型流程如下：
- 客戶端發送POST請求到/message端點以初始化通信。
- 服務器收到請求后返回響應，并根據情況決定是否升級為SSE流式傳輸。
- 如果需要，服務器可以通過SSE的方式向客戶端推送數據；否則，它將以常規HTTP響應的形式回復。
- 在任何時間點，如果連接中斷，客戶端可以攜帶必要的上下文信息（如Last-Event-ID）重新連接，服務器則可以根據這些信息恢復之前的狀態。
總結來說，Streamable HTTP提供了更加靈活且高效的通信機制，適用于更廣泛的場景，特別是在需要高效雙向通信和大規模部署的情況下。而SSE雖然也能滿足某些特定的需求，但在處理復雜性和擴展性方面不如Streamable HTTP。
因此，在最新的MCP版本中，官方推薦使用Streamable HTTP作為默認的傳輸機制。
四、SSE改造成StreamableHTTP
之前我們編寫了一個基于FastMCP框架的SSE模式的圖書館預定MCP-Server。現在我們給它升級成Streamable。
首先需要升級FastMCP框架版本，需要>=2.3.3
uv pip install fastmcp==2.3.3
然后引入依賴時，需要引入根依賴：
from fastmcp import FastMCP
SSE時是這樣引入的from mcp.server.fastmcp import FastMCP
中間代碼全部都不變，在最后指定通信方式是Streamable，如下：
if __name__ == "__main__":# mcp.run(transport="streamable-http", host="0.0.0.0", port=8000, path="/mcp")# mcp.run(transport="streamable-http")mcp.run(transport="streamable-http",host="0.0.0.0",port=8000,path="/mcp",# log_level="debug",)
