MCP模型上下文协议的通信机制从早期的 HTTPSSE 演进到了 Streamable HTTP。简单来说Streamable HTTP 并非彻底推翻重来而是一次重大的架构优化旨在解决旧模式在连接管理、资源消耗和灵活性上的痛点。两者的核心区别如下· 核心架构旧版 HTTPSSE 采用“双连接”模式一个SSE长连接收消息 一个HTTP短连接发请求新版 Streamable HTTP 则精简为“单连接”模式所有通信通过统一的 POST /message 端点完成。· 通信方向旧版 SSE 本质是单向的服务端→客户端客户端请求需另起HTTP连接新版是双向的同一连接内支持请求与响应。· 连接管理旧版需要服务器维护高可用长连接资源消耗大且连接中断后无法恢复新版支持无状态无需维持长连接服务器可按需选择是否升级为SSE流。· 端点设计旧版需维护 /sse 和 /message 两个端点新版仅需一个统一端点如 /mcp开发更简单。· 性能表现旧版每次调用需建连延迟高约120-150ms新版连接复用延迟可降至30ms以内高并发下TCP连接数和失败率都远低于旧版。· 基础设施旧版 SSE 长连接可能被防火墙或代理中断新版基于标准HTTP与CDN、负载均衡等现有设施兼容性更好。· 官方地位旧版SSE Transport已被官方弃用 (Deprecated)新版 Streamable HTTP 是官方推荐的当前标准。 总结Streamable HTTP 通过简化连接模型、支持无状态、提升性能和基础设施兼容性解决了旧版 HTTPSSE 的诸多痛点是目前构建 MCP 服务的首选方案。好的这是两个协议的文本流程图对比核心差异在于连接模型和交互时序宏观架构对比双连接 vs 单连接【旧版 MCP (HTTPSSE)】 【新版 MCP (Streamable HTTP)】 客户端 客户端 │ │ │ (1) GET /sse (建立长连接) │ (1) POST /mcp (唯一入口) ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ SSE通道 │ │HTTP通道 │ │统一端点 │ │(只收不送)│ │(只送不收)│ │(收发一体)│ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ ▼ ▼ ▼ 服务器 (需维护双连接状态) 服务器 (可按需无状态) 【端点/sse /message】 【端点仅 /mcp】交互时序对比被动推送 vs 按需响应【旧版流程强制长连接 分离式请求】 客户端 服务器 │ │ ├──── GET /sse ──────────│ (第一步建立SSE长连接) │──── 200 OK (保持) ─────┤ │ (通道常开) │ │ │ ├──── POST /message ─────│ (第二步另起连接发指令) │ (请求数据) │ │ │ (处理任务...) │──── SSE事件流推送 ─────┤ (第三步通过之前的长连接回传) │ (响应结果) │ └───────── 循环 ──────────┘ 【新版流程灵活单次连接支持无状态与按需流】 场景A (简单请求-响应无状态) 客户端 服务器 │ │ ├──── POST /mcp ─────────│ (唯一一次建连) │ (请求数据) │ │ │ (快速处理) │──── HTTP JSON响应 ─────┤ (直接返回连接关闭) └───────── 结束 ──────────┘ 场景B (长任务/流式按需升级) 客户端 服务器 │ │ ├──── POST /mcp ─────────│ (初始请求携带流式头) │ │ │──── 升级为 SSE流 ──────┤ (同一连接内升级非强制保持) │ (分块推送结果) │ └───────── 结束 ──────────┘核心差异速览图旧版 (SSE) 新版 (Streamable HTTP) ┌─────────────────────┐ ┌─────────────────────────┐ │ 2个端点 (SSEMSG) │ │ 1个端点 (统一 /mcp) │ │ 必须维持长连接 │ │ 可按需选择是否流式 │ │ 有状态 (Session ID) │ │ 支持完全无状态交互 │ │ 防火墙不友好 │ │ 完美适配CDN/代理 │ │ 官方已弃用 │ │ 官方推荐当前标准 │ └─────────────────────┘ └─────────────────────────┘新版 Streamable HTTP 的实现核心在于将传统的“双连接”模式革新为基于单一端点的“智能按需”模式。它充分利用了标准HTTP协议的灵活性。️ 核心架构一切从“单端点”开始· 统一入口服务器只需提供一个统一的HTTP端点如 /mcp。客户端所有请求无论是否需要流式都发往此端点。· 双方法支持该端点必须同时支持 POST 和 GET 方法。· POST发送JSON-RPC消息请求、响应、通知。· GET客户端主动建立SSE流用于接收服务端推送。 工作流程按需的三种响应模式普通响应模式 (Request-Response)适合无状态简单交互。客户端 POST 请求服务器处理完成后直接返回标准 application/json 响应并关闭连接。流式响应模式 (Streaming Response)适合长任务。客户端 POST 请求服务器在响应头设置 Content-Type: text/event-stream 将连接升级为SSE流。数据分块推送推送完毕后关闭连接。长连接模式 (Long-lived Stream)适合需要持续推送的场景。客户端通过 GET 请求主动建立SSE流服务器维持长连接用于推送通知或请求。 关键机制会话、标准化与安全· 会话管理 (MCP-Session-Id)服务器可在初始化时生成ID。客户端后续请求携带此ID实现状态恢复无状态服务也可忽略此ID。· HTTP头标准化 (SEP-2243)将 method 等关键路由信息镜像到 Mcp-Method、Mcp-Name 等标准HTTP头中。这让负载均衡器等中间设备无需解析JSON体即可智能路由。· 安全措施服务器必须验证 Origin 头以防DNS Rebinding攻击本地运行时应仅绑定到 localhost。总的来说Streamable HTTP 的实现是通过架构简化单端点、协议灵活运用按需升级SSE和标准化增强头部镜像的组合打造出一个既简单又强大的传输协议。
