MCP 协议重大升级,Spring AI Alibaba 联合 Higress 发布业界首个 Stramable HTTP 实现方案
· 12 min read
文章摘要
MCP 官方引入了全新的 Streamable HTTP 传输层,对原有 HTTP+SSE 传输机制有重大改进。
本文将:
- 详细解析这个协议的设计思想、技术细节以及实际应用。
- 详解 Spring AI Alibaba 开源框架提供的 Stramable HTTP Java 实现 ,文后包含 Spring AI Alibaba + Higress 的 Streamable HTTP 示例讲解。
相关项目链接如下:
- 完整可运行示例: https://github.com/springaialibaba/spring-ai-alibaba-examples
- Spring AI Alibaba 官网博客文章:https://java2ai.com/
- Spring AI Alibaba 开源项目地址:https://github.com/alibaba/spring-ai-alibaba
- Higress 官网地址:https://higress.ai/
HTTP+SSE 原理及缺陷

在原有的 MCP 实现中,客户端和服务器通过两个主要通道通信:
- HTTP 请求/响应:客户端通过标准 HTTP 请求发送消息到服务器
- 服务器发送事件(SSE):服务器通过专门的**/sse**端点向客户 端推送消息
主要问题
这种设计虽然简单直观,但存在几个关键问题:
不支持断线重连/恢复
当 SSE 连接断开时,所有会话状态丢失,客户端必须重新建立连接并初始化整个会话。例如,正在执行的大型文档分析任务会因 WiFi 不稳定而完全中断,迫使用户重新开始整个过程。
服务器需维护长连接
服务器必须为每个客户端维护一个长时间的 SSE 连接,大量并发用户会导致资源消耗剧增。当服务器需要重启或扩容时,所有连接都会中断,影响用户体验和系统可靠性。
服务器消息只能通过 SSE 传递
即使是简单的请求-响应交互,服务器也必须通过 SSE 通道返回信息,造成不必要的复杂性和开销。对于某些环境(如云函数)不适合长时间保持 SSE 连接。
基础设施兼容性限制
许多现有的 Web 基础设施如 CDN、负载均衡器、API 网关等可能不能正确处理长时间的 SSE 连接,企业防火墙可能会强制关闭超时连接,导致服务不可靠。
Streamable HTTP 原理与改进
Streamable 关键改进
相比原有 HTTP+SSE 机制,Streamable HTTP 引入了几项关键改进:
- 统一 Endpoint:移除专门的 /sse 端点,所有通信通过单一端点(当前官方 sdk 实现为 /mcp)进行
- 按需流式传输:服务器可灵活选择是返回普通 HTTP 响应还是升级为 SSE 流
- 会话标识:引入会话 ID 机制,支持状态管理和恢复
- 灵活初始化:客户端可通过空 GET 请求主动初始化 SSE 流
**Streamable **工作原理
Streamable HTTP 的工作流程如下:
- 会话初始化(非强制,适用于有状态实现场景):
- 客户端发送初始化请求到 /mcp 端点
- 服务器可选择生成会话 ID 返回给客户端
- 会话 ID 用于后续请求中标识会话
- 客户端向服务器通信:
- 所有消息通过 HTTP POST 请求发送到 /mcp 端点
- 如果有会话 ID,则包含在请求中
- 服务器响应方式:
- 普通响应:直接返回 HTTP 响应,适合简单交互
- 流式响应:升级连接为 SSE,发送一系列事件后关闭
- 长连接:维持 SSE 连接持续发送事件
- 主动建立 SSE 流:
- 客户端可发送 GET 请求到 /mcp 端点主动建立 SSE 流
- 服务器可通过该流推送通知或请求
- 连接恢复:
- 连接中断时,客户端可使用之前的会话 ID 重新连接
- 服务器可恢复会话状态继续之前的交互
Streamable 请求示例
无状态服务器模式
场景:简单工具 API 服务,如数学计算、文本处理等。
实现:
客户端 服务器
| |
|-- POST /message (计算请求) -------->|
| |-- 执行计算
|<------- HTTP 200 (计算结果) -------|
| |
优势:极简部署,无需状态管理,适合无服务器架构和微服务。
