> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# MCP流式HTTP协议深入研究
- URL: https://www.hubwiz.com/blog/a-deep-dive-into-mcp-streamable-http-protocol/
- Published: 2025-04-10T14:20:18.000Z
- Updated: 2025-04-10T14:20:29.000Z
- Description: MCP引入了一个全新的流式HTTP传输层，相比原来的HTTP+SSE传输机制有了显著改进。本文将详细分析该协议的设计理念、技术细节及其实际应用场景。
- Author: admin
- Tags: APPLICATION, MCP, #Import 2026-10-14 14:41

[模型上下文协议（MCP）](https://www.claudemcp.com/?ref=hubwiz.com) 是一种用于AI模型与工具之间通信的标准协议。随着AI应用变得越来越复杂并广泛部署，原有的通信机制面临一系列挑战。GitHub上的[PR #206](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206?ref=hubwiz.com)引入了一个全新的`流式HTTP`传输层，相比原来的HTTP+SSE传输机制有了显著改进。本文将详细分析该协议的设计理念、技术细节及其实际应用场景。

## 1、原始HTTP+SSE传输机制及其局限性

![](https://www.hubwiz.com/blog/content/images/2025/04/image-150.png)

在原始的MCP实现中，客户端和服务端通过两个主要通道进行通信：

- **HTTP请求/响应**：客户端通过标准HTTP请求向服务器发送消息。
- **服务器发送事件（SSE）**：服务器通过专用的`/sse`端点向客户端推送消息。

尽管这种设计简单直观，但它存在几个关键问题：

- **不支持重新连接/恢复**

当SSE连接断开时，所有会话状态都会丢失，迫使客户端重新建立连接并重新初始化整个会话。例如，在一个正在进行的大文件分析任务中，由于不稳定的WiFi，整个过程可能会完全中断，用户需要重新启动整个流程。

- **服务器必须维持长连接**

服务器必须为每个客户端维持长期的SSE连接，导致高并发情况下资源消耗巨大。当服务器需要重启或扩展时，所有连接都会中断，影响用户体验和系统可靠性。

- **服务器只能通过SSE发送消息**

即使对于简单的请求-响应交互，服务器也必须通过SSE通道返回信息，这造成了不必要的复杂性和开销。某些环境（如云函数）不适合维护长期的SSE连接。

- **基础设施兼容性限制**

许多现有的Web基础设施——如CDN、负载均衡器和API网关——可能无法正确处理长期的SSE连接。企业防火墙可能会强制终止超时的连接，导致服务不可靠。

## 2、流式HTTP：设计与原则

流式HTTP基于以下核心原则构建：

- **最大化兼容性**：无缝集成到现有的HTTP生态系统中。
- **灵活性**：支持无状态和有状态模式。
- **资源效率**：按需分配资源，避免不必要的长期连接。
- **可靠性**：支持重新连接和会话恢复。

### 2.1 主要改进

与原始机制相比，流式HTTP引入了几个关键增强功能：

1. **统一端点**：移除专用的`/sse`端点，通过单一端点（如`/message`）完成所有通信。
2. **按需流式传输**：服务器可以选择返回标准HTTP响应或升级为SSE流。
3. **会话识别**：引入会话ID机制以支持状态管理和恢复。
4. **灵活初始化**：客户端可以通过空GET请求主动初始化SSE流。

### 2.2 技术细节

流式HTTP的工作流程如下：

**会话初始化**：

- 客户端向`/message`端点发送初始化请求。
- 服务器可能会生成并返回会话ID给客户端。
- 会话ID用于后续请求中标识会话。

**客户端到服务器通信**：

- 所有消息都通过HTTP POST请求发送到`/message`端点。
- 如果存在会话ID，则将其包含在请求中。

**服务器响应方式**：

- **标准响应**：返回直接的HTTP响应，适用于简单的交互。
- **流式响应**：升级连接为SSE，发送一系列事件后关闭。
- **长期连接**：保持SSE连接以持续传递事件。

**主动SSE流建立**：

- 客户端可以通过向`/message`端点发送GET请求来主动建立SSE流。
- 服务器可以通过此流推送通知或请求。

**连接恢复**：

- 如果连接断开，客户端可以使用之前的会话ID重新连接。
- 服务器可以恢复会话状态并继续之前的操作。

## 3、实际应用场景

### 3.1 无状态服务器模式

**场景**：简单的工具API服务，如数学计算或文本处理。

**实现**：

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

```

**优势**：最小化部署，无需状态管理，适合无服务器架构和微服务。

### 3.2 流式进度反馈模式

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

**实现**：

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

```

**优势**：提供实时反馈，而无需永久连接状态。

### 3.3 复杂AI会话模式

**场景**：需要上下文维护的多轮AI助手。

**实现**：

```
客户端                                  服务器
   |                                    |
   |-- POST /message (初始化) ----------->|
   |<-- HTTP 200 (会话ID: abc123) ------|
   |                                    |
   |-- GET /message (会话ID: abc123) ---->|
   |<------- SSE流已建立 ---------------|
   |                                    |
   |-- POST /message (Q1, abc123) ------->|
   |<------- SSE: 思考中... -------------|
   |<------- SSE: 回答1 -----------------|
   |                                    |
   |-- POST /message (Q2, abc123) ------->|
   |<------- SSE: 思考中... -------------|
   |<------- SSE: 回答2 -----------------|

```

**优势**：维护会话上下文，支持复杂交互，并能实现水平扩展。

### 3.4 断连恢复模式

**场景**：在不稳定网络环境中的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: 完成 -----------------|

```

**优势**：在弱网络条件下提高可靠性，提升用户体验。

## 4、流式HTTP的主要优势

### 4.1 技术优势

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

### 4.2 商业优势

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

## 5、实现参考

### 5.1 服务器端实现亮点

**端点设计**：

- 实现单一`/message`端点用于所有请求。
- 支持POST和GET HTTP方法。

**状态管理**：

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

**请求处理**：

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

**连接管理**：

- 实现SSE流的初始化和维护。
- 处理断开和重新连接逻辑。

### 5.2 客户端实现亮点

**请求构造**：

- 构符合协议的消息
- 正确包含会话ID（如适用）

**响应处理**：

- 检测响应是标准HTTP还是SSE
- 解析和处理SSE事件

**会话管理**：

- 存储和管理会话ID
- 实现重新连接逻辑

**错误处理**：

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

## 6、结束语

可流式传输的HTTP传输层代表了MCP协议的重大演进。通过结合HTTP和SSE的优点并克服其局限性，它为AI应用程序提供了一个更灵活可靠的通信解决方案。它不仅解决了原始传输机制的问题，还为未来更复杂的AI交互模式奠定了基础。

该协议的设计体现了实用性，平衡了技术复杂性和与现有Web基础设施的兼容性。其灵活性允许开发人员根据需要选择最合适的实现方式，从简单的无状态API到复杂的交互式AI应用程序。

随着此PR的合并，MCP社区的技术生态系统将变得更加丰富，降低更多开发人员采用的门槛。在不久的将来，我们预计基于可流式传输HTTP的MCP实现将在各种AI应用程序中得到广泛应用。

---

原文链接：[MCP's New Transport Layer - A Deep Dive into the Streamable HTTP Protocol](https://www.claudemcp.com/blog/mcp-streamable-http?ref=hubwiz.com#google%5Fvignette)

汇智网翻译整理，转载请标明出处