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

mcp通讯协议

• stdio
  
• sse
  
• streamable http
  

JSON_RPC

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

• 请求
  

1. {
2.   jsonrpc: "2.0",
3.   id: number | string,
4.   method: string,
5.   params?: object
6. }

复制代码

• 响应
  

1. {
2.   jsonrpc: "2.0",
3.   id: number | string,
4.   result?: object,
5.   error?: {
6.     code: number,
7.     message: string,
8.     data?: unknown
9.   }
10. }

复制代码

一 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处理流程

实际工作过程总结

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

复制代码

java-webflux正确引用

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

1. <dependencies>
2.         <dependency>
3.             <groupId>org.springframework.ai</groupId>
4.             spring-ai-starter-mcp-server-webflux</artifactId>
5.         </dependency>
6. </dependencies>
7.     <dependencyManagement>
8.         <dependencies>
9.             <dependency>
10.                 <groupId>org.springframework.ai</groupId>
11.                 spring-ai-bom</artifactId>
12.                 <version>1.0.0-SNAPSHOT</version>
13.                 <type>pom</type>
14.                 <scope>import</scope>
15.             </dependency>
16.         </dependencies>
17.     </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 协议，(不过应该也快了，目前在分支PR上已经有了，https://github.com/modelcontextprotocol/java-sdk/commit/fdc11db29e23be3e8df38c812ea250a1b4fd3f1b#diff-31e16deaf3da3266ef0811b072b367a44c30e9c03c9e1fc738de6dc07d22d63d)需要继续使用SSE实现，当然你也可以采用pyton-sdk，它是有支持的。

• https://github.com/modelcontextprotocol/java-sdk
  
• https://github.com/modelcontextprotocol/python-sdk
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！