mcp通讯协议

• stdio
• sse
• streamable http

JSON_RPC

MCP 的传输层负责将 MCP 协议消息转换为 JSON-RPC 格式进行传输，并将接收到的 JSON-RPC 消息转换回 MCP 协议消息

• 请求

{  jsonrpc: "2.0",  id: number | string,  method: string,  params?: object}

• 响应

{  jsonrpc: "2.0",  id: number | string,  result?: object,  error?: {    code: number,    message: string,    data?: unknown  }}

一 stdio

本地化部署mcp server后，本机上的gpt工具集成了mcp client skd，然后通过本地进程与mcp server进行通讯

二 sse

MCP 早期采用 HTTP+SSE（Server-Sent Events）实现客户端与服务器的通信，但存在以下问题：

1. 不支持断线恢复：SSE 连接中断后会话状态丢失，需重新开始。
2. 服务器资源压力大：需为每个客户端维护长连接，高并发时资源消耗显著。
3. 单向通信限制：服务器只能通过 SSE 端点单向推送消息，无法灵活处理双向交互。
4. 基础设施兼容性差：CDN、防火墙等可能中断长连接，导致服务不可靠。

客户端和服务端通讯原理

1. 客户端向服务服务/sse节点发起get请求，它是一个长连接，connection keep-alive,accept text/event-stream
2. 服务端返回endpoint节点，并带上sessionId标识，之后服务端向客户端推送的数据，也是从这个/sse节点完成
3. 客户端向endpoint节点发起post请求，将问题以请求体的形式发给mcp server
4. mcp server获取当前endpoint+sessionId，对请求体处理，并通过/sse接口推送到客户端

sdk处理流程

实际工作过程总结

连接建立    客户端请求 /sse；    服务端初始化 SseEmitter 和 McpServerSession，返回可用的消息接口地址。会话初始化    客户端通过 /message 发送 InitializeRequest，告知能力与标识；    服务端处理后通过 SSE 返回 InitializeResponse。资源管理    客户端发起如 tools/list 请求；    服务端从会话中查找状态，调用工具处理器并通过 SSE 返回结果。调用工具    客户端拼接 prompt 后发起 tools/call；    服务端查找处理器执行逻辑，并通过 SSE 返回执行结果。连接维持    客户端周期性发送 ping；    服务端返回 pong，用于保持连接活跃。连接关闭    客户端主动断开；    服务端清理对应的连接与会话状态。

java-webflux正确引用

使用快照版1.0.0-SNAPSHO，引用包spring-ai-starter-mcp-server-webflux

 <dependencies>        <dependency>            <groupId>org.springframework.ai</groupId>            <artifactId>spring-ai-starter-mcp-server-webflux</artifactId>        </dependency> </dependencies>    <dependencyManagement>        <dependencies>            <dependency>                <groupId>org.springframework.ai</groupId>                <artifactId>spring-ai-bom</artifactId>                <version>1.0.0-SNAPSHOT</version>                <type>pom</type>                <scope>import</scope>            </dependency>        </dependencies>    </dependencyManagement>

使用标准版1.0.0-M6，引用包spring-ai-mcp-server-webflux-spring-boot-starter会出现无sessionId参数的问题

三 streamable http

Streamable HTTP 通过以下设计解决了SSE的问题：

1. 统一端点
   移除专用的 /sse 端点，所有通信通过单一端点（如 /mcp）完成，支持 POST 和 GET 请求。

2. 按需流式传输
   服务器可灵活选择响应方式：

   • 普通 HTTP 响应：适用于简单请求（如计算任务）。
   • 升级为 SSE 流：用于需持续推送的场景（如进度反馈）。
   • 维持长连接：支持双向流式交互（如多轮对话）。

3. 会话标识与状态管理
   引入会话 ID 机制（通过 Mcp-Session-Id 头部传递），支持断线重连和状态恢复。服务器可选择无状态（Stateless）或有状态（Stateful）模式运行。

4. 灵活初始化与恢复

   • 客户端可通过空 GET 请求主动初始化 SSE 流。
   • 断线后，客户端可通过会话 ID 重新连接并恢复上下文。

Streamable HTTP 的优势

1. 兼容性与扩展性

• 纯 HTTP 实现，兼容 CDN、API 网关等现有基础设施。
• 支持无状态服务器，适合 Serverless 架构（如 AWS Lambda）。

2. 性能优化

• 复用 TCP 连接，减少高并发下的连接数（测试显示，1000 并发用户时连接数仅为 HTTP+SSE 的 1/10）。
• 平均响应时间更短（Streamable HTTP 为 0.0075s，HTTP+SSE 为 1.5112s）。

3. 客户端简化

• 相比 HTTP+SSE 需维护双通道，Streamable HTTP 客户端代码量减少 40% 以上，仅需处理统一端点。

4. 灵活部署

• 支持无状态模式，避免强制粘性会话（Sticky Session），便于水平扩展。
• 适用于云原生架构，如 Kubernetes 动态扩缩容。

典型应用场景

• 无状态服务（如数学计算工具）

客户端直接发送 POST 请求，服务器返回即时 HTTP 响应，无需维护会话。

• 流式进度反馈（如大文件处理）

服务器通过 SSE 流分阶段推送进度（如 10%、30%），完成后关闭连接。

• 多轮对话 AI（如上下文感知助手）

初始化会话后，通过会话 ID 维持上下文，支持多轮交互与断线恢复。

• 弱网络环境

网络中断后，客户端可携带会话 ID 重新连接，从断点继续任务。

开发语言的选择

mcp-java-sdk 暂未支持新版 Streamable HTTP 协议，(不过应该也快了，目前在分支PR上已经有了，)需要继续使用SSE实现，当然你也可以采用pyton-sdk，它是有支持的。