MCP 协议更新详解：从 HTTP+SSE 到 Streamable HTTP

学习网络编程，理解HTTP协议和TCP/IP。 #生活技巧# #学习技巧# #编程学习指南#

该文章已被 Model Context Protocol(MCP) 中文教程讲解 收录，欢迎 star 收藏。

前言

2025 年 3 月 26 日，模型上下文协议（Model Context Protocol，简称 MCP）引入了一项关键更新：用 Streamable HTTP 替代原先的 HTTP + SSE 作为默认传输方式。

这一变更在解决原有方案中连接不可恢复、服务端长连接压力大等问题的同时，依然保留了 SSE 带来的流式响应优势。

本文将深入解析这次更新背后的动因、技术细节以及实际应用场景。

准备好了吗？准备一杯你最喜欢的咖啡或茶，随着本文一探究竟吧。

HTTP + SSE 的缺陷

远程 MCP 通过 HTTP + SSE 的传输方式工作，存在以下问题，这也是它所被替换的根本原因：

不支持恢复连接 要求服务器保持高可用的长连接 服务器只能通过 SSE 发送消息

不支持恢复连接

如果客户端和服务器之间的 SSE 连接中断了，就无法 “从端点继续”，只能重新开始新的连接，之前的上下文可能会丢失。

要求服务器保持高可用的长连接

服务器必须一直保持一个稳定、不中断的 SSE 长连接，否则通信就中断。

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

服务器无法在已有的请求之外，主动地发送消息给客户端，除了通过专门的 /sse 通道。换句话说，它是“单向被动响应”，而不是“任意时机推送”。

Streamable HTTP

Streamable HTTP 并不是传统意义上的 流式 HTTP（Streaming HTTP），它指的是一种 兼具以下特性的传输机制：

以普通 HTTP 请求为基础，客户端用 POST/GET 发请求；

服务器可选地将响应升级为 SSE 流，实现 流式传输 的能力（当需要时）；

去中心化、无强制要求持续连接，支持 stateless 模式；

客户端和服务端之间的消息传输更加灵活，比如同一个 /message 端点可用于发起请求和接收 SSE 流；

不再需要单独的 /sse 端点，一切通过统一的 /message 协议层处理。

Streamable HTTP 的优势

支持无状态服务器：无需维持高可用的长连接

纯 HTTP 实现：MCP 可在纯 HTTP 服务中实现，无需 SSE 支持

兼容基础设施：因为 “只是 HTTP”，可以与中间件和现有基础设施良好集成

向后兼容：是当前 HTTP+SSE 传输方式的渐进式改进

灵活的传输方式：服务器可选择是否使用 SSE 进行流式响应

从 HTTP+SSE 到 Streamable HTTP 的变化

移除了 /sse 端点

所有客户端 → 服务端的消息都通过 /message（或类似端点）发送

所有客户端 → 服务端的请求都可以被服务器升级为 SSE，以发送通知或请求

服务器可以选择建立会话 ID 以维护状态

客户端可以通过对 /message 发送一个空的 GET 请求启动 SSE 流

该方法兼容旧版本的实现，并允许服务器保持无状态（如果有需要）

为什么不用 WebSocket？

官方团队曾认真探讨过是否应该将 WebSocket 作为远程通信的主要方式，并尝试在其基础上实现断线重连等功能。但最终决定暂时不采用 WebSocket，主要原因如下：

想要以 RPC 风格使用 MCP（例如构建一个无状态、只暴露基础工具的服务）时，如果每次调用都依赖 WebSocket，将引入不必要的维护和网络开销。

在浏览器环境中，WebSocket 连接无法像普通 HTTP 请求那样附加请求头（比如 Authorization），而且不同于 SSE，WebSocket 在浏览器中也无法由第三方库完全“模拟”实现。

只有 GET 请求可以自动升级为 WebSocket，而 POST 等其他 HTTP 方法并不支持直接升级。这就意味着如果要让 POST 请求使用 WebSocket，需要一个额外的 两步升级 过程，增加了实现的复杂度和延迟。

也避免在 MCP 规范中增加 WebSocket 的可选支持，以减少客户端与服务器间可能的兼容性组合问题（但不阻止社区自己扩展非官方的 WebSocket 实现）

官方也有意避免在 MCP 协议中引入 WebSocket 作为官方选项，以避免客户端和服务器之间因传输方式组合过多而导致的兼容性问题（当然，这并不妨碍用户基于 WebSocket 自行实现非官方版本）。

当然，如果将来实践中发现 SSE 并不理想，官方仍会考虑重新评估 WebSocket 的可能性。

MCP Server 示例

无状态服务器（Stateless Server）

Streamable HTTP 支持构建完全无状态、无需保持长连接的服务器架构。

以一个仅提供大语言模型（LLM）工具的服务为例，不依赖其他高级功能，可以按以下方式实现：

始终响应初始化请求，但无需持久化任何状态； 对所有传入的 ToolListRequest，直接返回一个标准的 JSON-RPC 响应； 对 CallToolRequest，执行对应工具，等待其完成后，将结果通过 HTTP 响应体以 CallToolResponse 的形式返回。

支持流式输出的无状态服务器（Stateless Server with Streaming）

即使服务器完全无状态、且不支持长连接，也仍然可以利用此设计进行流式响应。

以工具调用时的进度反馈为例：

当收到 POST 的 CallToolRequest 时，服务器通过响应头声明该响应将以 SSE（Server-Sent Events）格式返回； 启动工具执行逻辑； 在执行过程中，服务器可以通过 SSE 向客户端持续发送多个 ProgressNotification（进度通知）； 执行完成后，服务器通过 SSE 发送最终的 CallToolResponse； 最后，服务器关闭 SSE 流，整个交互完成。

有状态服务器（Stateful Server）

对于需要维护客户端会话的服务器，整体架构可以保持与 http+SSE 的实现类似。

主要区别在于：服务器需要为客户端生成唯一的会话 ID，并要求客户端在后续所有请求中携带该 ID。

服务器可以利用会话 ID 实现 粘性路由 或消息总线中的会话定位。例如，在水平扩展的部署中（部署多台相同的 mcp server），某个 POST 请求可能被路由到任意一个节点，此时可以通过 Redis 等中间件将请求路由到关联的会话上下文，确保状态一致性。

小结

Streamable HTTP 是对 MCP 协议传输层的一次重要优化。它在保留原有 HTTP + SSE 模式优势的基础上，解决了连接不可恢复、长连接负担重、传输不灵活等问题，带来了更高的可用性与灵活性。

参考资料

[RFC] Replace HTTP+SSE with new "Streamable HTTP" transport

你好，我是陈明勇，一名热爱技术、乐于分享的开发者，同时也是开源爱好者。

我专注于分享 Go 语言相关的技术知识，同时也会深入探讨 AI 领域的前沿技术。

成功的路上并不拥挤，有没有兴趣结个伴？

网址：MCP 协议更新详解：从 HTTP+SSE 到 Streamable HTTP https://c.klqsh.com/news/view/313445

相关内容

解决Tomcat启动成功但无法访问http://localhost:8080/的问题
轻松上传：C#中HTTP POST multipart/form
四川大学研究生管理系统：http://my.scu.edu.cn
PubMed: http://www.pubmed.org
浅谈流媒体协议以及视频编解码
周星驰经典喜剧：揭秘http背后的电影魅力
国家普通话水平测试在线报名系统( http://bm.cltt.org )
南京智慧教育云平台登录入口：http://www.jsnje.cn
扣子空间
山东省普通高中综合素质评价系统登录：http://www.sdei.edu.cn/uc/wcms/zpLogin.htm

随便看看