MCP传输层机制：stdio与SSE - 流行MCP服务器-学习笔记-上海佼艾

一、传输层的作用

在MCP（Model Context Protocol）协议中，传输层（Transport Layer）负责客户端和服务器之间的消息传递，是整个MCP通信体系的基础。传输层屏蔽了底层通信细节，为上层提供一致的消息收发接口，使得上层应用无需关心数据是通过本地管道还是网络传输。

MCP协议栈自下而上分为三层：传输层（Transport Layer）、消息层（JSON-RPC 2.0）和应用层（MCP Primitives）。传输层位于最底层，定义了数据如何在客户端和服务器之间流动；消息层定义了请求、响应、通知的标准格式；应用层则定义了工具调用、资源访问、提示模板等高级功能。

MCP官方定义了两套标准传输方式：stdio传输和SSE传输。前者适用于本地进程间通信，后者适用于远程网络通信。两者虽然底层机制完全不同，但在消息层面上统一使用JSON-RPC 2.0协议，因此上层应用可以相对透明地在两种传输方式之间切换。

核心概念：传输层只负责"怎么把消息发过去"，不关心"消息里有什么"。消息内容（JSON-RPC载荷）由上层协议解析。这种分层设计使得MCP可以灵活适配各种通信场景。

二、stdio传输详解

stdio（Standard Input/Output）传输是MCP中最基础也是最常用的传输方式。在这种模式下，MCP服务器作为客户端进程的子进程运行，双方通过标准输入输出流进行通信。

2.1 工作原理

当客户端（如Claude Code、VS Code的MCP插件等）启动时，它会为每一个配置的MCP服务器创建一个子进程。客户端通过子进程的标准输入（stdin）发送JSON-RPC请求，子进程通过标准输出（stdout）返回JSON-RPC响应。标准错误（stderr）则独立用于服务器自身的日志输出或调试信息，不会干扰正常的数据通信流。

这种通信模式的生命周期与客户端进程紧密绑定：客户端启动时拉起子进程，客户端退出时杀死子进程。这意味着每启动一个客户端会话，都会重新创建完整的MCP服务器进程。

2.2 配置方式

在Claude Code中，通过修改claude.json配置文件来声明stdio类型的MCP服务器。每个服务器条目包含type: "stdio"以及相应的启动命令和参数：

{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@anthropic-ai/mcp-filesystem",
        "/path/to/allowed/dir"
      ]
    },
    "github": {
      "type": "stdio",
      "command": "node",
      "args": [
        "path/to/github-mcp-server/index.js"
      ],
      "env": {
        "GITHUB_TOKEN": "<your_token>"
      }
    }
  }
}

关键配置字段说明：command指定可执行文件的路径或命令名（如npx、node、python等）；args是传递给该命令的参数数组；env（可选）用于设置子进程的环境变量，适合传入API密钥等敏感信息。

2.3 优势与局限

优势：安全性高（所有通信限制在本地进程内，不暴露网络端口）；性能优异（进程间管道通信延迟极低，通常在微秒级）；配置简单（只需指定启动命令和参数）；无需处理网络连接的复杂性（TCP握手、TLS、认证等）。

局限：服务器只能与启动它的客户端通信（一对一的进程关系）；无法支持远程访问（服务器必须和客户端在同一台机器上）；每次启动客户端都需要重新初始化服务器（有状态的服务器会丢失之前的上下文）；不适合长时间运行的后台服务。

三、SSE传输详解

SSE（Server-Sent Events）传输是MCP针对远程通信场景设计的传输方式。在这种模式下，MCP服务器作为一个独立的HTTP服务运行，客户端通过HTTP协议与服务器建立连接并进行通信。

3.1 工作原理

SSE传输采用双向但不对称的通信模式。客户端通过标准的HTTP POST请求向服务器发送JSON-RPC消息，而服务器则通过SSE连接（Server-Sent Events，一种HTTP服务器推送技术）向客户端推送事件和响应。SSE是一种轻量级的服务器推送技术，基于HTTP长连接实现，比WebSocket更简单，天然支持断线重连。

具体而言，客户端首先向服务器的SSE端点（通常是/sse或/events）发起一个HTTP GET请求，建立长连接。服务器通过这个连接持续推送事件，包括endpoint事件（告知客户端消息端点的URL）、message事件（包含JSON-RPC响应内容）。客户端则向服务器指定的消息端点发送HTTP POST请求来提交JSON-RPC请求。

3.2 配置方式

在Claude Code中，SSE类型的MCP服务器配置如下：

{
  "mcpServers": {
    "remote-server": {
      "type": "sse",
      "url": "https://example.com/mcp/sse"
    }
  }
}

SSE配置比stdio简洁得多：只需指定type: "sse"和服务器SSE端点的url。客户端会负责处理SSE连接的建立、消息的收发以及断线重连等底层细节。

3.3 优势与局限

优势：支持远程访问（服务器可部署在云端，多个客户端共享）；服务器可以独立运行和管理，不受客户端生命周期限制；天然支持水平扩展（通过负载均衡分发请求）；适合构建MCP网关和服务市场；单个服务器可同时服务多个客户端连接。

局限：需要处理网络安全问题（TLS、认证鉴权、CORS等）；延迟相对较高（网络延迟通常在毫秒到百毫秒级）；部署和维护复杂度更高（需要管理HTTP服务器、负载均衡、监控等）；需要处理连接断开和重连逻辑；可能面临跨域访问限制。

3.4 SSE与WebSocket的对比

MCP选择SSE而非WebSocket作为远程传输的默认方案，有其技术考量。SSE是单向推送协议（服务器→客户端），客户端→服务器的通信通过独立的HTTP POST完成；WebSocket是全双工协议。SSE基于标准HTTP，不需要额外的协议升级握手，在存在代理和防火墙的环境中兼容性更好。SSE内置了断线重连机制（EventSource API），而WebSocket需要手动实现。对于MCP的使用场景（客户端发请求，服务器回响应），SSE配合HTTP POST已经足够，不需要全双工能力。

四、stdio vs SSE对比

下表从多个维度对比两种传输方式的核心差异，帮助开发者根据实际需求做出合适的选择：

对比维度	stdio传输	SSE传输
通信模式	本地进程间管道通信	HTTP网络通信
部署位置	本地（与客户端同一台机器）	本地或远程（服务器可独立部署）
安全模型	依赖本地文件系统权限，不暴露网络	需要TLS加密、认证鉴权、CORS等
延迟	极低（微秒级，进程内管道通信）	较低（毫秒级，受网络延迟影响）
生命周期	与客户端进程绑定，随客户端启停	独立运行，可作为常驻服务
部署复杂度	低（仅需安装运行环境）	中到高（需要管理HTTP服务基础设施）
适用场景	本地开发者工具、文件系统操作、本地数据库查询	云端API服务、多租户平台、MCP服务市场
可靠性	依赖子进程稳定性，子进程崩溃即中断	支持断线重连，可搭配负载均衡实现高可用
多客户端支持	一对一（一个服务器实例服务一个客户端）	一对多（一个服务器可服务多个客户端）
资源消耗	每个客户端启动独立进程，内存开销大	共享服务器进程，资源利用率高
消息格式	JSON-RPC 2.0 over stdin/stdout	JSON-RPC 2.0 over HTTP/SSE

选择策略：开发个人工具或本地使用的MCP服务器，优先选择stdio，部署简单且安全。构建生产环境的云服务或多租户平台，选择SSE以支持远程访问和水平扩展。也可以同时提供两种传输方式的支持，让用户根据场景灵活切换。

五、MCP的JSON-RPC消息格式

无论使用哪种传输层，MCP的消息格式统一采用JSON-RPC 2.0协议。JSON-RPC是一种轻量级的远程过程调用协议，使用JSON作为数据格式，定义了三种基础消息类型：请求、响应和通知。

5.1 基础消息格式

请求（Request）：包含jsonrpc: "2.0"、唯一的id、方法名method和参数params。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "北京"
    }
  }
}

响应（Response）：包含jsonrpc、对应的id、结果result（或错误error）。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "北京当前气温22°C，晴"
      }
    ]
  }
}

通知（Notification）：没有id的请求，不需要响应。常用于日志、进度更新等单向消息。

{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": {
    "progressToken": "abc123",
    "progress": 50,
    "total": 100
  }
}

5.2 初始化握手过程

当传输层连接建立后，客户端和服务器之间首先进行初始化握手，这是MCP会话建立的必经步骤。整个过程分为两步：

第一步：客户端发送initialize请求，包含客户端支持的协议版本和能力信息。

// 客户端 → 服务器（通过stdio/stdout或HTTP POST）
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {}
    },
    "clientInfo": {
      "name": "claude-code",
      "version": "1.0.0"
    }
  }
}

第二步：服务器返回初始化响应，包含服务器支持的协议版本和能力信息。

// 服务器 → 客户端（通过stdio/stdout或SSE事件）
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-03-26",
    "capabilities": {
      "tools": {},
      "resources": {},
      "prompts": {}
    },
    "serverInfo": {
      "name": "my-mcp-server",
      "version": "0.1.0"
    }
  }
}

第三步：客户端发送initialized通知，确认初始化完成。此后双方可以开始正常的MCP会话通信。

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

5.3 关闭流程

当客户端需要关闭会话时，会发送shutdown请求，服务器收到后完成清理工作并返回响应。对于stdio传输，关闭请求发出后客户端通常还会终止子进程；对于SSE传输，关闭后SSE连接也会随之断开。

// 客户端请求关闭
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "shutdown"
}

// 服务器确认关闭
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": null
}

注意：关闭完成后，客户端应发送exit通知，服务器收到后主动退出进程。这是MCP协议中的优雅关闭流程，确保双方都能完整释放资源。

六、自定义传输实现

除了stdio和SSE这两种标准传输方式外，MCP协议在设计上保留了传输层的扩展性，允许开发者根据特定场景实现自定义传输。

MCP的传输抽象层定义了一组核心接口：连接建立、消息发送、消息接收、连接关闭和错误处理。只要实现了这些接口，任何通信机制都可以作为MCP的传输层。以下是一些可能的自定义传输场景：

6.1 浏览器扩展中的MessageChannel传输

在浏览器扩展（如Chrome Extension）中，由于扩展运行在沙箱环境中，既不能启动子进程（stdio不可用），也不能直接建立HTTP服务器（SSE不可用）。此时可以利用浏览器的MessageChannel或runtime.connect API实现自定义传输。例如，扩展的Service Worker作为MCP客户端，通过MessageChannel与Content Script通信，再由Content Script转发到后端服务。这种传输方式利用了浏览器原生的消息传递机制，完全符合MCP的传输层抽象。

6.2 WebSocket传输

虽然MCP默认选择SSE作为远程传输方式，但在某些需要全双工通信或更复杂消息模式的场景下，可以基于WebSocket实现自定义传输。WebSocket传输在全双工、低延迟方面有优势，但需要额外的协议握手，且在存在代理和防火墙的环境中兼容性不如SSE。

6.3 Unix Domain Socket传输

在Unix/Linux系统中，Unix Domain Socket（UDS）提供了一种比TCP回环地址（localhost）更高效、更安全的进程间通信方式。UDS传输兼具stdio的低延迟优势和SSE的多客户端支持能力，但限于同一台机器且仅适用于Unix类系统。适合需要单机多进程共享MCP服务器的高性能场景。

6.4 消息队列传输

在微服务架构中，可以通过消息队列（如RabbitMQ、Kafka）实现MCP传输。客户端将JSON-RPC消息发布到请求队列，服务器从队列消费并发布响应到响应队列。这种传输方式天然支持异步处理、消息持久化和消费者组负载均衡，适用于高吞吐量和需要消息可靠投递的企业级场景。

MCP协议的设计哲学是"传输无关"。无论采用何种传输方式，上层的JSON-RPC消息格式和MCP Primitives（工具、资源、提示模板）都保持一致。这种分层抽象使得MCP可以适应从本地CLI工具到分布式云服务的各种部署形态。