核心内容点:

• Streamable HTTP 解决了原有 HTTP+SSE 传输机制的断线重连、服务器资源消耗和基础设施兼容性等问题。
• Streamable HTTP 通过统一端点、按需流式传输、会话标识和灵活初始化等关键改进，实现了更高的灵活性和资源效率。
• Streamable HTTP 支持多种应用场景，包括无状态服务器模式、流式进度反馈模式、复杂 AI 会话模式和断线恢复模式。

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

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

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 服务，如数学计算、文本处理等。

实现：

1
2
3
4
5
6

客户端                                 服务器
   |                                    |
   |-- POST /message (计算请求) -------->|
   |                                    |-- 执行计算
   |<------- HTTP 200 (计算结果) -------|
   |                                    |

优势：极简部署，无需状态管理，适合无服务器架构和微服务。

流式进度反馈模式

场景：长时间运行的任务，如大文件处理、复杂 AI 生成等。

实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

客户端                                 服务器
   |                                    |
   |-- POST /message (处理请求) -------->|
   |                                    |-- 启动处理任务
   |<------- HTTP 200 (SSE开始) --------|
   |                                    |
   |<------- SSE: 进度10% ---------------|
   |<------- SSE: 进度30% ---------------|
   |<------- SSE: 进度70% ---------------|
   |<------- SSE: 完成 + 结果 ------------|
   |                                    |

优势：提供实时反馈，但不需要永久保持连接状态。

复杂 AI 会话模式

场景：多轮对话 AI 助手，需要维护上下文。

实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

客户端                                 服务器
   |                                    |
   |-- 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 应用使用。

实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

客户端                                 服务器
   |                                    |
   |-- 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 的主要优势

技术优势

1. 简化实现：可以在普通 HTTP 服务器上实现，无需特殊支持
2. 资源效率：按需分配资源，不需要为每个客户端维护长连接
3. 基础设施兼容性：与现有 Web 基础设施（CDN、负载均衡器、API 网关）良好配合
4. 水平扩展：支持通过消息总线路由请求到不同服务器节点
5. 渐进式采用：服务提供者可根据需求选择实现复杂度
6. 断线重连：支持会话恢复，提高可靠性

业务优势

1. 降低运维成本：减少服务器资源消耗，简化部署架构
2. 提升用户体验：通过实时反馈和可靠连接改善体验
3. 广泛适用性：从简单工具到复杂 AI 交互，都有合适的实现方式
4. 扩展能力：支持更多样化的 AI 应用场景
5. 开发友好：降低实现 MCP 的技术门槛

实现参考

服务器端实现要点

1. 端点设计：

   • 实现单一的 /message 端点处理所有请求
   • 支持 POST 和 GET 两种 HTTP 方法

2. 状态管理：

   • 设计会话 ID 生成和验证机制
   • 实现会话状态存储（内存、Redis 等）

3. 请求处理：

   • 解析请求中的会话 ID
   • 确定响应类型（普通 HTTP 或 SSE）
   • 处理流式响应的内容类型和格式

4. 连接管理：

   • 实现 SSE 流初始化和维护
   • 处理连接断开和重连逻辑

客户端实现要点

1. 请求构造：

   • 构建符合协议的消息格式
   • 正确包含会话 ID（如有）

2. 响应处理：

   • 检测响应是普通 HTTP 还是 SSE
   • 解析和处理 SSE 事件

3. 会话管理：

   • 存储和管理会话 ID
   • 实现断线重连逻辑

4. 错误处理：

   • 处理网络错误和超时
   • 实现指数退避重试策略

结论

Streamable HTTP 传输层代表了 MCP 协议的重要进化，它通过结合 HTTP 和 SSE 的优点，同时克服二者的局限，为 AI 应用的通信提供了更灵活、更可靠的解决方案。它不仅解决了原有传输机制的问题，还为未来更复杂的 AI 交互模式奠定了基础。

这个协议的设计充分体现了实用性原则，既满足了技术先进性要求，又保持了与现有 Web 基础设施的兼容性。它的灵活性使得开发者可以根据自身需求选择最合适的实现方式，从简单的无状态 API 到复杂的交互式 AI 应用，都能找到合适的解决方案。

随着这个 PR 的合并，MCP 社区的技术生态将更加丰富多样，也为更多开发者采用 MCP 提供了便利。相信在不久的将来，我们将看到基于 Streamable HTTP 的 MCP 实现在各种 AI 应用中的广泛应用。