MCP传输机制深度解析：stdio、HTTP+SSE与Streamable HTTP完全指南

本文对比了MCP协议的三种传输机制：stdio、HTTP+SSE和Streamable HTTP。重点分析了Streamable HTTP相较于HTTP+SSE的改进：统一端点设计降低复杂度，按需流式传输提高灵活性，强大的会话管理增强稳定性。测试数据显示Streamable HTTP在连接数、请求成功率和响应时间等指标上均显著优于HTTP+SSE，为AI应用提供了更高效的通信方案。

编程小饴

642人浏览 · 2025-09-20 19:15:00

编程小饴 · 2025-09-20 19:15:00 发布

本文详细介绍了MCP协议的三种传输机制：stdio、HTTP+SSE和Streamable HTTP。重点对比了HTTP+SSE与Streamable HTTP的区别，指出Streamable HTTP通过统一端点设计、灵活传输模式和强大会话管理，解决了HTTP+SSE的连接维护成本高、资源消耗大和兼容性差等问题。Streamable HTTP在稳定性、性能和实现复杂度方面均优于HTTP+SSE，为AI应用提供了更可靠的通信基础。

有读者留言问，”是否可以单独部署 mcp 服务器？”（[FastMCP，构建 MCP 的 python 框架，比官方 SDK 更好用！。这个问题，与服务器采用哪种传输机制（transport）是相关的。MCP 的传输机制（Transport）指的是客户端与服务端之间的通信机制。

官方文档介绍，MCP 的客户端与服务端之间的通信，需遵循以下原则：

消息格式：所有 MCP 消息都必须是 JSON-RPC 格式；所有 JSON-RPC 消息必须使用 UTF-8 编码。
两种标准化的传输方式：stdio (标准输入/输出)、Streamable HTTP 。在可能的情况下，客户端应当支持标准输入输出 (stdio)。
客户端和服务器可以通过模块化的方式实现自定义的传输机制。

在 MCP 协议 2025-03-26 版本，Streamable HTTP 替代了之前版本（2024-11-05 版）的传输方式：HTTP+SSE 。下面分别详细介绍三种传输机制：stdio、HTTP+SSE、Streamable HTTP。

stdio（标准输入/输出）

适用场景：适合本地运行的 MCP 服务器（如桌面应用 Claude Desktop）；适合 MCP 服务器的开发调试。

关键特性：

客户端直接启动并管理服务器进程。
默认环境隔离（不继承 shell 环境变量），需显式传递敏感数据（如 API Key）。
支持会话持久化。

通信工作流程

客户端将 MCP 服务器作为子进程启动。
服务器从其标准输入 (stdin) 读取 JSON-RPC 消息，并将其消息发送到其标准输出 (stdout)。
消息是单独的 JSON-RPC 请求、通知或响应。
消息通过换行符 (\n) 分隔，且消息内容中禁止包含内嵌的换行符。
服务器可将其标准错误 (stderr) 用于输出 UTF-8 编码的字符串，以达到日志记录目的。客户端可捕获、转发或忽略此日志记录。
服务器不得向其 stdout 写入任何非有效的 MCP 消息的内容。
客户端不得向服务器的 stdin 写入任何非有效的 MCP 消息的内容。

从 HTTP+SSE 到 Streamable HTTP

在 MCP 协议 2025-03-26 版本，Streamable HTTP 替代了之前版本（2024-11-05 版）的传输方式：HTTP+SSE transport（https://modelcontextprotocol.io/specification/2024-11-05/basic/transports）

为什么要从 HTTP+SSE 转到 Streamable HTTP 呢？

HTTP+SSE：客户端通过 HTTP POST 发送请求，服务器通过一个单独的 SSE (Server-Sent Events) 端点推送响应，需要维护两个独立的连接。
Streamable HTTP：它使用单一的 HTTP 端点统一处理请求和响应，允许服务器根据需要选择返回标准 HTTP 响应或启用 SSE 流。

HTTP+SSE

HTTP+SSE 的工作流程：

客户端连接到服务器上的一个 “http://example.com/sse” 端点
服务器响应一个 “endpoint event”，告知客户端使用哪个 URI（例如 http://example.com/messages）来发送消息
客户端使用此 URI 与服务器通信
服务器通过 SSE 协议与客户端通信。

SSE（Server-Sent Events）是一种用于实现服务器主动向客户端推送数据的技术，也被称为“事件流”（Event Stream）。它基于 HTTP 协议，利用了其长连接特性，在客户端与服务器之间建立一条持久化连接，并通过这条连接实现服务器向客户端的实时数据推送。

HTTP+SSE 的存在的问题：

连接的维护成本高：需要维护两个独立的连接/端点（endpoint）。
资源消耗高：必须保持长连接，在高并发情况下可能导致显著的资源消耗。长连接也使得无状态实现变得困难。
基础设施兼容性差：许多现有网络基础设施可能无法正确处理长期的 SSE 连接。企业防火墙可能会强制终止超时的连接，使得服务变得不可靠。
连接的可恢复性差：在网络问题的情况下缺乏连接的可恢复性。这给需要通过互联网访问、可能面临连接中断的远程 MCP 服务器带来了挑战。

HTTP+SSE 需要维护两个独立的连接：

Streamable HTTP

Streamable HTTP 是 MCP 协议定义的一种特定的、基于 HTTP 的传输机制或模式。Streamable HTTP 描述了如何利用 HTTP（特别是 POST 和 GET 方法）和可选的 SSE 技术，在 MCP 客户端和服务器之间实现双向的、可具备流式交互能力的消息交换。

Streamable HTTP 的工作流程：

客户端向服务端发送请求。
服务端自己决定是以标准的 HTTP 响应（HTTP Response）还是流式响应（SSE Response）的形式返回。

服务端自己决定响应的形式（HTTP Response 或 SSE Response）：

Streamable HTTP 与 HTTP+SSE 的区别？

在之前的 HTTP+SSE 传输中：

客户端会连接到一个专用的 /sse 端点，该端点专门用于接收服务器消息。
服务器会立即发回一个“端点事件 (endpoint event)”，其中包含一个供客户端发送消息的 URL。
需要维护两个独立的连接：一个用于客户端→服务器 (HTTP POST)，另一个用于服务器→客户端 (SSE)。

在新的 Streamable HTTP 传输中：

只有一个端点（通常是 /message）。
任何客户端请求都可以用标准的 HTTP 响应或升级的 SSE 流来响应。
这种升级是动态发生的，基于服务器对该特定交互的需求。
客户端通过一个标准的 HTTP 请求发起连接，由服务器决定是否对其进行“流式响应”。

Streamable HTTP 的优势：

1、🌐统一的端点设计

Streamable HTTP 移除了用于建立连接的专用 /sse 端点，将所有通信集成到一个单一端点中。这种设计的好处包括：

简化的架构：减少了客户端和服务器之间的连接数量，降低了系统复杂性。
更低的资源消耗：单一连接管理更高效，减少了服务器资源使用。
改进的兼容性：更好地适应现有的网络基础设施，减少了与防火墙和代理服务器的兼容性问题。

2、🔄灵活的传输模式

服务器可以根据请求的类型和内容，灵活地选择返回标准的 HTTP 响应或通过 SSE 流式传输：

按需流式传输：对于简单的请求，可以返回直接的 HTTP 响应，无需建立长连接。
智能降级：在网络条件不佳时，可以自动降级到标准的 HTTP 模式。
资源优化：根据请求的复杂性动态分配服务器资源，以提高整体效率。

3、🤖强大的会话管理

引入了全面的会话机制，以支持状态管理和恢复：

会话一致性：通过 Mcp-Session-Id 头确保跨请求的状态一致性。
断线重连：支持 Last-Event-ID 机制，确保断线后未收到的消息可以被恢复。
状态恢复：允许客户端在重新连接时恢复之前的会话状态，提升用户体验。

Streamable HTTP 只需维护一个独立连接，降低了复杂度：

HTTP + SSE VS Streamable HTTP

1、⚖️稳定性

TCP连接次数比较

SSE Server 的 SSE 连接无法复用且需要长期维护。高并发需求也将导致 TCP 连接数量急剧增加，而 Streamable HTTP 协议可以直接返回响应，并复用同一个 TCP 连接处理多个请求。其 TCP 连接数最多仅达到几十个，且整体执行时间仅为 SSE Server 的四分之一。

HTTP + SSE：需要维护大量长连接，TCP 连接数随时间推移持续增长。
Streamable HTTP：按需建立连接，保持低水平的 TCP 连接数。

请求成功率比较

HTTP + SSE：随着并发用户数的增加，成功率显著下降。
Streamable HTTP：即使在高并发条件下也能保持相对较高的成功率。

2、🚀性能

响应时间比较：

Streamable HTTP 的平均响应时间更短，响应时间波动较小，且随并发用户数增加，响应时间增长更为平稳。
HTTP + SSE 的平均响应时间更长，在高并发场景下响应时间波动显著

3、🧩复杂度

Streamable HTTP 同时支持无状态和有状态服务。当前大多数场景可以通过无状态的 Streamable HTTP 解决。通过对比两种传输解决方案的客户端实现代码，可以清晰地看出无状态 Streamable HTTP 客户端实现的简洁性。

HTTP + SSE 客户端示例代码：

classSSEClient:
def__init__(self, url: str, headers: dict = None):
        self.url = url
        self.headers = headers or {}
        self.event_source = None
        self.endpoint = None

asyncdefconnect(self):
# 1. Establish SSE connection
asyncwith aiohttp.ClientSession(headers=self.headers) as session:
            self.event_source = await session.get(self.url)

# 2. Handle connection events
            print('SSE connection established')

# 3. Handle message events
asyncfor line in self.event_source.content:
if line:
                    message = json.loads(line)
await self.handle_message(message)

# 4. Handle errors and reconnect
if self.event_source.status != 200:
                        print(f'SSE error: {self.event_source.status}')
await self.reconnect()

asyncdefsend(self, message: dict):
# Need an additional POST request to send the message
asyncwith aiohttp.ClientSession(headers=self.headers) as session:
asyncwith session.post(self.endpoint, json=message) as response:
returnawait response.json()

asyncdefhandle_message(self, message: dict):
# Handle the received message
        print(f'Received message: {message}')

asyncdefreconnect(self):
# Implement reconnection logic
        print('Attempting to reconnect...')
await self.connect()

Streamable HTTP 客户端示例代码：

classStreamableHTTPClient:
def__init__(self, url: str, headers: dict = None):
        self.url = url
        self.headers = headers or {}

asyncdefsend(self, message: dict):
# 1. Send a POST request
asyncwith aiohttp.ClientSession(headers=self.headers) as session:
asyncwith session.post(self.url, json=message,
                                    headers={'Content-Type': 'application/json'}
                                   ) as response:
# 2. Handle the response
if response.status == 200:
returnawait response.json()
else:
raise Exception(f'HTTP error: {response.status}')

以上是 MCP 传输机制的相关介绍。随着 MCP 协议的持续发展，Streamable HTTP 传输机制的引入标志着协议向更高效、更稳定方向迈出了重要一步。通过统一的端点设计、灵活的传输模式和强大的会话管理，Streamable HTTP 解决了 HTTP+SSE 方案的诸多痛点，为 AI 应用提供了更可靠的通信基础。

读者福利大放送：如果你对大模型感兴趣，想更加深入的学习大模型**，那么这份精心整理的大模型学习资料，绝对能帮你少走弯路、快速入门**

如果你是零基础小白，别担心——大模型入门真的没那么难，你完全可以学得会！

👉 不用你懂任何算法和数学知识，公式推导、复杂原理这些都不用操心；
👉 也不挑电脑配置，普通家用电脑完全能 hold 住，不用额外花钱升级设备；
👉 更不用你提前学 Python 之类的编程语言，零基础照样能上手。

你要做的特别简单：跟着我的讲解走，照着教程里的步骤一步步操作就行。

包括：大模型学习线路汇总、学习阶段，大模型实战案例，大模型学习视频，人工智能、机器学习、大模型书籍PDF。带你从零基础系统性的学好大模型！

现在这份资料免费分享给大家，有需要的小伙伴，直接VX扫描下方二维码就能领取啦😝↓↓↓
在这里插入图片描述

为什么要学习大模型？

数据显示，2023 年我国大模型相关人才缺口已突破百万，这一数字直接暴露了人才培养体系的严重滞后与供给不足。而随着人工智能技术的飞速迭代，产业对专业人才的需求将呈爆发式增长，据预测，到 2025 年这一缺口将急剧扩大至 400 万！!
在这里插入图片描述

大模型学习路线汇总

整体的学习路线分成L1到L4四个阶段，一步步带你从入门到进阶，从理论到实战，跟着学习路线一步步打卡，小白也能轻松学会！
在这里插入图片描述

大模型实战项目&配套源码

光学理论可不够，这套学习资料还包含了丰富的实战案例，让你在实战中检验成果巩固所学知识
在这里插入图片描述

大模型学习必看书籍PDF

我精选了一系列大模型技术的书籍和学习文档(电子版)，它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
在这里插入图片描述

大模型超全面试题汇总

在面试过程中可能遇到的问题，我都给大家汇总好了，能让你们在面试中游刃有余
在这里插入图片描述

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
在这里插入图片描述
👉获取方式：

😝有需要的小伙伴，可以保存图片到VX扫描下方二维码免费领取【保证100%免费】
在这里插入图片描述
相信我，这套大模型系统教程将会是全网最齐全最适合零基础的！！

北京朝阳AI社区

更多推荐

AI觉醒：小白的大模型冒险记第8章：解码器王宫的秘密 - Decoder与生成艺术

北京朝阳AI社区

扣子Coze实战：零基础搭建数据分析智能体，1分钟完成复盘，流量翻10倍

以上就是本期分享的视频数据复盘智能体的详细介绍。通过这个智能体，你可以轻松实现视频数据的科学分析，快速找到内容优化的方向。AI时代，我们每个人都可以成为数据分析专家。希望这个智能体能帮助你在短视频创作的道路上走得更轻松。

北京朝阳AI社区

langgraph开发Deep Research智能体-项目搭建

大家都说2025年是AI Agent元年，自然agent智能体开发也非常热门。很多公司的所谓的智能体其实是通过扣子、dify这种平台配出来的。就像是通过低代码平台配置出来的web页面一样，虽然能用，但是如果你的需求很复杂，往往平台就无法满足你的需求。作为程序员所以我们还是得需要自己动手来实现智能体，这篇文章我们来讲讲如何使用langgraph搭建一个node.js项目来实现一个Deep Resea