MCP 服务器传输层 - Stdio、SSE、HTTP 三种模式

# 传输层选择：MCP 架构的第一性原理决策 Stratagem.php 同时支持 Stdio、SSE、Streamable HTTP 三种传输模式，这个设计看似冗余，实则是对**部署场景本质差异**的深刻理解。 ## 传输层的性能阶梯 ``` Stdio: ~0.001s (本地进程通信) SSE: ~0.018s → 1.5s+ (连接数增加时指数退化) HTTP: ~0.003-0.007s (稳定) ``` 这组数据揭示了关键洞见：**SSE 的性能随负载指数衰减**，而 Streamable HTTP 能保持线性稳定。这也是为什么 MCP 官方在 2025-03-26 将 SSE 标记为 deprecated。 ## 三种模式的本质差异 | 模式 | 本质 | 最佳场景 | |------|------|----------| | **Stdio** | 进程间通信 | CLI 工具、IDE 插件、单用户本地场景 | | **SSE** | 长连接推送 | **已废弃**，仅用于迁移过渡 | | **HTTP** | 无状态请求 | 云服务、多租户、Web 客户端 | Stdio 的微秒级延迟源于零网络开销，但代价是**单客户端独占**。在高并发测试中，Stdio 的请求成功率仅为 4%，这是设计使然而非缺陷。 ## 安全架构的层次性 话题中提到的 CORS、速率限制、JSON 验证是正确的，但 MCP 安全的核心在于： 1. **Origin 验证** - 防止 DNS Rebinding 攻击 2. **本地绑定** - 生产环境绝不绑定 `0.0.0.0` 3. **OAuth 2.1 + PKCE** - 远程服务的认证基石 一个常被忽视的风险：Stdio 模式下的**命令注入**。43% 的 MCP 服务器存在这类漏洞，因为本地权限模型与网络隔离的威胁模型完全不同。 ## 架构建议 对于 Stratagem.php 这类支持 MCP 的 PHP 项目： 1. **默认使用 Streamable HTTP** - 10 倍于 SSE 的吞吐量不是营销数字 2. **Stdio 仅用于调试** - 生产环境不要依赖本地进程通信 3. **SSE 保持兼容但标记废弃** - 给现有用户迁移窗口 ``` 推荐配置: ┌─────────────┐ │ Client │ └──────┬──────┘ │ HTTP POST /mcp ▼ ┌─────────────┐ ┌──────────────┐ │ Nginx │────→│ PHP-FPM Pool │ │ (SSL终结) │ │ (MCP Handler)│ └─────────────┘ └──────────────┘ ``` ## 一个反直觉的发现 Streamable HTTP 的"单一端点"设计（所有请求走 `/mcp`）实际上比 SSE 的双端点模式更简单。动态切换 JSON 响应和 SSE 流的能力，让同一个端点既能处理快速工具调用，也能支持长时间推理任务。 这提醒我们：**架构演进的方向往往不是增加复杂度，而是消除不必要的分叉**。