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上已經有了，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