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 POST 请求发送到
-
服务器响应方式:
- 普通响应:直接返回 HTTP 响应,适合简单交互
- 流式响应:升级连接为 SSE,发送一系列事件后关闭
- 长连接:维持 SSE 连接持续发送事件
-
主动建立 SSE 流:
- 客户端可发送 GET 请求到
/message
端点主动建立 SSE 流 - 服务器可通过该流推送通知或请求
- 客户端可发送 GET 请求到
-
连接恢复:
- 连接中断时,客户端可使用之前的会话 ID 重新连接
- 服务器可恢复会话状态继续之前的交互
实际应用场景
无状态服务器模式
场景:简单工具 API 服务,如数学计算、文本处理等。
实现:
客户端 服务器
| |
|-- POST /message (计算请求) -------->|
| |-- 执行计算
|<------- HTTP 200 (计算结果) -------|
| |
优势:极简部署,无需状态管理,适合无服务器架构和微服务。
流式进度反馈模式
场景:长时间运行的任务,如大文件处理、复杂 AI 生成等。
实现:
客户端 服务器
| |
|-- POST /message (处理请求) -------->|
| |-- 启动处理任务
|<------- HTTP 200 (SSE开始) --------|
| |
|<------- SSE: 进度10% ---------------|
|<------- SSE: 进度30% ---------------|
|<------- SSE: 进度70% ---------------|
|<------- SSE: 完成 + 结果 ------------|
| |
优势:提供实时反馈,但不需要永久保持连接状态。
复杂 AI 会话模式
场景:多轮对话 AI 助手,需要维护上下文。
实现:
客户端 服务器
| |
|-- POST /message (初始化) ---------->|
|<-- HTTP 200 (会话ID: abc123) ------|
| |
|-- GET /message (会话ID: abc123) --->|
|<------- SSE流建立 -----------------|
| |
|-- POST /message (问题1, abc123) --->|
|<------- SSE: 思考中... -------------|
|<------- SSE: 回答1 ----------------|
| |
|-- POST /message (问题2, abc123) --->|
|<------- SSE: 思考中... -------------|
|<------- SSE: 回答2 ----------------|
优势:维护会话上下文,支持复杂交互,同时允许水平扩展。
断线恢复模式
场景:不稳定网络环境下的 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: 完成 ------------------|
优势:提高弱网环境下的可靠性,改善用户体验。
总结
Streamable HTTP 传输层代表了 MCP 协议的重要进化,它通过结合 HTTP 和 SSE 的优点,同时克服二者的局限,为 AI 应用的通信提供了更灵活、更可靠的解决方案。它不仅解决了原有传输机制的问题,还为未来更复杂的 AI 交互模式奠定了基础。
这个协议的设计充分体现了实用性原则,既满足了技术先进性要求,又保持了与现有 Web 基础设施的兼容性。它的灵活性使得开发者可以根据自身需求选择最合适的实现方式,从简单的无状态 API 到复杂的交互式 AI 应用,都能找到合适的解决方案。
随着这个 PR 的合并,MCP 社区的技术生态将更加丰富多样,也为更多开发者采用 MCP 提供了便利。相信在不久的将来,我们将看到基于 Streamable HTTP 的 MCP 实现在各种 AI 应用中的广泛应用。