logo
MCP 协议

MCP 协议

MCP 新传输层：Streamable HTTP 协议

MCMCP 协议

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 应用中的广泛应用。