企业官网建设流程全解析

MCP（模型上下文协议）的通信机制从早期的 HTTP+SSE 演进到了 Streamable HTTP。简单来说，Streamable HTTP 并非彻底推翻重来，而是一次重大的架构优化，旨在解决旧模式在连接管理、资源消耗和灵活性上的痛点。

两者的核心区别如下：

· 核心架构：旧版 HTTP+SSE 采用“双连接”模式（一个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 通过简化连接模型、支持无状态、提升性能和基础设施兼容性，解决了旧版 HTTP+SSE 的诸多痛点，是目前构建 MCP 服务的首选方案。

好的，这是两个协议的文本流程图对比，核心差异在于连接模型和交互时序：

1. 宏观架构对比（双连接 vs 单连接）

【旧版 MCP (HTTP+SSE)】 【新版 MCP (Streamable HTTP)】 客户端 客户端 │ │ │ (1) GET /sse (建立长连接) │ (1) POST /mcp (唯一入口) ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ SSE通道 │ │HTTP通道 │ │统一端点 │ │(只收不送)│ │(只送不收)│ │(收发一体)│ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ ▼ ▼ ▼ 服务器 (需维护双连接状态) 服务器 (可按需无状态) 【端点：/sse + /message】 【端点：仅 /mcp】

2. 交互时序对比（被动推送 vs 按需响应）

【旧版流程：强制长连接 + 分离式请求】 客户端 服务器 │ │ ├──── GET /sse ──────────>│ (第一步：建立SSE长连接) │<──── 200 OK (保持) ─────┤ │ (通道常开) │ │ │ ├──── POST /message ─────>│ (第二步：另起连接发指令) │ (请求数据) │ │ │ (处理任务...) │<──── SSE事件流推送 ─────┤ (第三步：通过之前的长连接回传) │ (响应结果) │ └───────── 循环 ──────────┘ 【新版流程：灵活单次连接（支持无状态与按需流）】 场景A (简单请求-响应，无状态)： 客户端 服务器 │ │ ├──── POST /mcp ─────────>│ (唯一一次建连) │ (请求数据) │ │ │ (快速处理) │<──── HTTP JSON响应 ─────┤ (直接返回，连接关闭) └───────── 结束 ──────────┘ 场景B (长任务/流式，按需升级)： 客户端 服务器 │ │ ├──── POST /mcp ─────────>│ (初始请求，携带流式头) │ │ │<──── 升级为 SSE流 ──────┤ (同一连接内升级，非强制保持) │ (分块推送结果) │ └───────── 结束 ──────────┘

3. 核心差异速览图

旧版 (SSE) 新版 (Streamable HTTP) ┌─────────────────────┐ ┌─────────────────────────┐ │ 2个端点 (SSE+MSG) │ │ 1个端点 (统一 /mcp) │ │ 必须维持长连接 │ │ 可按需选择是否流式 │ │ 有状态 (Session ID) │ │ 支持完全无状态交互 │ │ 防火墙不友好 │ │ 完美适配CDN/代理 │ │ 官方已弃用 │ │ 官方推荐当前标准 │ └─────────────────────┘ └─────────────────────────┘

新版 Streamable HTTP 的实现，核心在于将传统的“双连接”模式，革新为基于单一端点的“智能按需”模式。它充分利用了标准HTTP协议的灵活性。

🏗️ 核心架构：一切从“单端点”开始

· 统一入口：服务器只需提供一个统一的HTTP端点（如 /mcp）。客户端所有请求（无论是否需要流式）都发往此端点。
· 双方法支持：该端点必须同时支持 POST 和 GET 方法。
· POST：发送JSON-RPC消息（请求、响应、通知）。
· GET：客户端主动建立SSE流，用于接收服务端推送。

🔄 工作流程：按需的三种响应模式

1. 普通响应模式 (Request-Response)：适合无状态简单交互。客户端 POST 请求，服务器处理完成后直接返回标准 application/json 响应并关闭连接。
2. 流式响应模式 (Streaming Response)：适合长任务。客户端 POST 请求，服务器在响应头设置 Content-Type: text/event-stream 将连接升级为SSE流。数据分块推送，推送完毕后关闭连接。
3. 长连接模式 (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）和标准化增强（头部镜像）的组合，打造出一个既简单又强大的传输协议。