传输层在 MCP 架构中的定位
MCP 架构的一大精妙之处在于“传输层与应用层协议解耦”。JSON-RPC 报文不关心自己是通过管道（pipe）、HTTP 长连接还是网络套接字传递。
1. 三大传输模式横向对比矩阵
| 维度 | stdio (子进程标准输入输出) | SSE (HTTP + Server-Sent Events) | WebSockets (双向持久套接字) |
|---|---|---|---|
| 网络边界 | 仅限本地宿主机内部 | 支持跨互联网与 VPC 内网 | 支持跨互联网与 VPC 内网 |
| 连接机制 | OS 匿名管道 (IPC) | 单向 HTTP 响应流 + POST 报文 | 全双工单个 TCP/TLS 连接 |
| 延迟损耗 | < 1ms（无网络栈开销） | 受网络 RTT 与 TLS 影响 (10~50ms) | 低于 SSE，约一个网络 RTT |
| 反向代理支持 | 不适用 | Nginx / Cloudflare 原生良好支持 | 需要额外的代理升级协议支持 |
| 权限与安全 | 继承当前用户本地权限 | 需独立设计 OAuth/Token 鉴权 | 需独立设计握手鉴权 |
2. 企业级混合拓扑推荐
- 本地开发态：首选
stdio，配置简单，无端口冲突，无后台僵尸进程滞留风险。 - 企业服务态：对外统一暴露基于 SSE/HTTPS 的网关，前端结合 WAF 与 RBAC 统一鉴权，后端再将请求分发至内网微服务工具集群。