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）实现客户端与服务器的通信，但存在以下问题：

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

客户端和服务端通讯原理

客户端向服务服务/sse节点发起get请求，它是一个长连接，connection keep-alive,accept text/event-stream
服务端返回endpoint节点，并带上sessionId标识，之后服务端向客户端推送的数据，也是从这个/sse节点完成
客户端向endpoint节点发起post请求，将问题以请求体的形式发给mcp server
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的问题：

统一端点

移除专用的 /sse 端点，所有通信通过单一端点（如 /mcp）完成，支持 POST 和 GET 请求。
按需流式传输

服务器可灵活选择响应方式：
- 普通 HTTP 响应：适用于简单请求（如计算任务）。
- 升级为 SSE 流：用于需持续推送的场景（如进度反馈）。
- 维持长连接：支持双向流式交互（如多轮对话）。
会话标识与状态管理

引入会话 ID 机制（通过 Mcp-Session-Id 头部传递），支持断线重连和状态恢复。服务器可选择无状态（Stateless）或有状态（Stateful）模式运行。
灵活初始化与恢复
- 客户端可通过空 GET 请求主动初始化 SSE 流。
- 断线后，客户端可通过会话 ID 重新连接并恢复上下文。

Streamable HTTP 的优势

兼容性与扩展性

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

性能优化

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

客户端简化

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

灵活部署

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

典型应用场景

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

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

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

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

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

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

弱网络环境

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

开发语言的选择

mcp-java-sdk 暂未支持新版 Streamable HTTP 协议，需要继续使用SSE实现，当然你也可以采用pyton-sdk，它是有支持的。

mcp~客户端与服务端的通讯技术