传输层
MCP支持两种官方传输方式，同时允许自定义传输实现。3.1 stdio传输
原理: 通过标准输入(stdin)和标准输出(stdout)流通信。Host启动Server子进程，通过管道交换JSON-RPC消息。每条消息以换行符分隔。 适用场景: Server和Client在同一台机器上运行。 优势:- 零网络开销，延迟最低
- 无需配置端口、证书
- 安全（不暴露网络接口）
- 实现简单
- 只能本地使用
- 一个Server进程只服务一个Client
node /path/to/my-server/index.js 子进程，通过stdin/stdout通信。Server的stderr可以用于日志输出，不会干扰协议。
3.2 Streamable HTTP传输
状态: 当前推荐的远程传输方式（协议版本2025-11-25）。
原理: Client和Server通过单一HTTP端点通信。Client用POST发送JSON-RPC请求，Server可以用Server-Sent Events (SSE)实现流式响应和主动推送。
适用场景: Server部署在远程（云服务器、SaaS服务等）。
核心机制
单一MCP端点: Server暴露一个端点（如/mcp），处理两种HTTP方法：
- POST: Client发送JSON-RPC请求。Server可以返回单个JSON响应，或以SSE流返回多个消息。
- GET: Client建立SSE连接，用于接收Server的主动推送（通知、请求等）。
Mcp-Session-Id HTTP头管理有状态会话：
MCP-Protocol-Version 头：
Last-Event-ID 机制实现断线重连。Client在重连时发送上次收到的事件ID，Server从该点继续推送：
优势
- 支持远程访问
- 一个Server可服务多个Client（通过Session ID区分）
- 支持标准HTTP认证（OAuth 2.1、API Key等）
- 支持负载均衡和水平扩展
- 支持断线重连和消息恢复
劣势
- 有网络延迟
- 需要配置HTTPS、认证
配置示例
3.3 已弃用：HTTP+SSE传输
已弃用的HTTP+SSE与当前Streamable HTTP的区别：3.4 自定义传输
MCP允许实现自定义传输层，只要满足JSON-RPC 2.0消息交换的基本要求：双向消息传递、请求-响应匹配、通知推送。例如，可以基于WebSocket、gRPC或自定义TCP协议实现。3.5 选型指南
3.6 OAuth 2.1认证
远程MCP Server的认证基于 OAuth 2.1（draft-ietf-oauth-v2-1-13），这是MCP规范推荐的标准认证机制。详细内容见第7章：安全与认证。 认证流程概览：下一章: 构建MCP Server — TypeScript和Python的完整开发指南