logo

MCP 新传输层:Streamable HTTP 协议

Model Context Protocol (MCP) 是一个用于 AI 模型和工具间通信的标准协议。随着 AI 应用的日益复杂和广泛部署,原有的通信机制面临着一系列挑战。GitHub 上的 PR #206 引入了全新的 Streamable HTTP 传输层,这是对原有 HTTP+SSE 传输机制的重大改进。本文将详细解析这个协议的设计思想、技术细节以及实际应用。

原有 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 引入了几项关键改进:

  1. 统一端点:移除专门的 /sse 端点,所有通信通过单一端点(如 /message)进行
  2. 按需流式传输:服务器可灵活选择是返回普通 HTTP 响应还是升级为 SSE 流
  3. 会话标识:引入会话 ID 机制,支持状态管理和恢复
  4. 灵活初始化:客户端可通过空 GET 请求主动初始化 SSE 流

技术细节

Streamable HTTP 的工作流程如下:

  1. 会话初始化

    • 客户端发送初始化请求到 /message 端点
    • 服务器可选择生成会话 ID 返回给客户端
    • 会话 ID 用于后续请求中标识会话
  2. 客户端向服务器通信

    • 所有消息通过 HTTP POST 请求发送到 /message 端点
    • 如果有会话 ID,则包含在请求中
  3. 服务器响应方式

    • 普通响应:直接返回 HTTP 响应,适合简单交互
    • 流式响应:升级连接为 SSE,发送一系列事件后关闭
    • 长连接:维持 SSE 连接持续发送事件
  4. 主动建立 SSE 流

    • 客户端可发送 GET 请求到 /message 端点主动建立 SSE 流
    • 服务器可通过该流推送通知或请求
  5. 连接恢复

    • 连接中断时,客户端可使用之前的会话 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 应用中的广泛应用。