什么是 REST API？
HTTP+SSE的傳輸過程實現中，客戶端和服務器通過兩個主要渠道進行通信：（1）HTTP 請求/響應：客戶端通過標準的 HTTP 請求向服務器發送消息。 （2）服務器發送事件（SSE）：服務器通過專門的 /sse 端點向客戶端推送消息，這就導致存在下面三個問題：
Streamable HTTP 是 MCP 協議的一次重要升級，通過下面的改進解決了原有 HTTP + SSE 傳輸方式的多個關鍵問題：
Streamable HTTP 移除了專門建立連接的 /sse 端點，將所有通信整合到統一的端點。這一設計帶來的好處包括：
服務器可以根據請求類型和內容靈活選擇返回標準 HTTP 響應或通過 SSE 流式返回：
引入了完善的session機制以支持狀態管理和恢復：
下面通過實際應用場景中穩定性，性能和客戶端復雜度三個角度對比說明 Streamable HTTP 相比 HTTP + SSE的優勢，AI 網關 Higress 目前已經支持了 Streamable HTTP 協議，通過 MCP 官方 Python SDK 的樣例 Server 部署了一個 HTTP + SSE 協議的 MCP Server，通過 Higress 部署了一個 Streamable HTTP 協議的MCP Server。
利用Python程序模擬1000個用戶同時并發訪問遠程的MCP Server并調用獲取工具列表，圖中可以看出 SSE Server的 SSE 連接無法復用且需要長期維護，高并發的需求也會帶來 TCP 連接數的突增，而 Streamable HTTP 協議則可以直接返回響應，多個請求可以復用同一個 TCP 連接，TCP連接數最高只到幾十條，并且整體執行時間也只有SSE Server 的四分之一。
在1000個并發用戶的測試場景下，Higress 部署的 Streamable HTTP 方案的 TCP 連接數明顯低于 HTTP + SSE 方案：
實際應用場景中進程級別通常會限制最大連接數，linux默認通常是1024。利用Python程序模擬不同數量的用戶訪問遠程的MCP Server并調用獲取工具列表，SSE Server在并發請求數到達最大連接數限制后，成功率會極速下降，大量的并發請求無法建立新的 SSE 連接而訪問失敗。
在不同并發用戶數下的請求成功率測試中，Higress 部署的 Streamable HTTP 的成功率顯著高于 HTTP + SSE 方案：
這里對比的是社區 Python 版本的 GitHUB MCP Server 和 Higress MCP 市場的 GitHUB MCP Server。
利用 Python 程序模擬不同數量的用戶同時并發訪問遠程的 MCP Server 并調用獲取工具列表，并統計調用返回響應的時間，圖中給出的響應時間對比為對數刻度，SSE Server 在并發用戶數量較多時平均響應時間會從0.0018s顯著增加到1.5112s，而 Higress 部署的 Streamable HTTP Server 則依然維持在0.0075s的響應時間，也得益于 Higress 生產級的性能相比于 Python Starlette框架。
性能測試結果顯示，Higress 部署的Streamable HTTP 在響應時間方面具有明顯優勢：
Streamable HTTP 支持無狀態的服務和有狀態的服務，目前的大部分場景無狀態的 Streamable HTTP的可以解決，通過對比兩種傳輸方案的客戶端實現代碼，可以直觀地看到無狀態的 Streamable HTTP 的客戶端實現簡潔性。
HTTP + SSE 客戶端樣例代碼
classSSEClient:
def __init__(self, url: str, headers: dict = None):
self.url = url
self.headers = headers or {}
self.event_source = None
self.endpoint = None
async def connect(self):
# 1. 建立 SSE 連接
async with aiohttp.ClientSession(headers=self.headers) as session:
self.event_source = await session.get(self.url)
# 2. 處理連接事件
print('SSE connection established')
# 3. 處理消息事件
async for line in self.event_source.content:
if line:
message = json.loads(line)
await self.handle_message(message)
# 4. 處理錯誤和重連
if self.event_source.status != 200:
print(f'SSE error: {self.event_source.status}')
await self.reconnect()
async def send(self, message: dict):
# 需要額外的 POST 請求發送消息
async with aiohttp.ClientSession(headers=self.headers) as session:
async with session.post(self.endpoint, json=message) as response:
return await response.json()
async def handle_message(self, message: dict):
# 處理接收到的消息
print(f'Received message: {message}')
async def reconnect(self):
# 實現重連邏輯
print('Attempting to reconnect...')
await self.connect()Streamable HTTP 客戶端樣例代碼
classStreamableHTTPClient:
def __init__(self, url: str, headers: dict = None):
self.url = url
self.headers = headers or {}
async def send(self, message: dict):
# 1. 發送 POST 請求
async with aiohttp.ClientSession(headers=self.headers) as session:
async with session.post( self.url, json=message,
headers={'Content-Type': 'application/json'}
) as response:
# 2. 處理響應
if response.status == 200:
return await response.json()
else:
raise Exception(f'HTTP error: {response.status}')從代碼對比可以看出：
1. 復雜度：Streamable HTTP 無需處理連接維護、重連等復雜邏輯
2. 可維護性：Streamable HTTP 代碼結構更清晰，更易于維護和調試
3. 錯誤處理：Streamable HTTP 的錯誤處理更直接，無需考慮連接狀態
隨著MCP協議的不斷發展，Streamable HTTP傳輸機制的引入標志著協議向更高效、更穩定的方向邁進了一大步。通過統一端點設計、靈活的傳輸模式和強大的會話管理，Streamable HTTP解決了HTTP+SSE方案中的諸多痛點，為AI應用提供了更可靠的通信基礎。
對于希望快速部署高性能MCP服務的開發者和企業，mcp.higress.ai[2]提供了基于Higress開源AI網關構建的MCP server托管市場。這個市場的獨特優勢在于：
與其他MCP市場不同，mcp.higress.ai不是簡單收集開源社區中未經充分驗證的Python/TS項目，而是專注于將成熟的API轉化為高質量的MCP服務，為AI應用提供可靠的工具和資源支持。隨著MCP協議的普及和應用場景的拓展，基于Higress的MCP服務將為AI生態系統提供更加堅實的基礎設施支持。
參考鏈接：
[1]https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206
[2]https://mcp.higress.ai/
文章轉載自： MCP 協議：為什么 Streamable HTTP 是最佳選擇？
