考察点
这道题出自小米大模型岗三面，已经不考「MCP 是什么」，直接钻传输层。面试官想确认你读过协议规范或真部署过远程 MCP server：三种传输方式的差异、JSON-RPC 消息格式、为什么协议组选了 HTTP 系而不是 WebSocket、新旧 HTTP 方案对 Serverless 的兼容性。答得出 trade-off 才算过，背名词不够。追问常往鉴权、断线恢复、stdio 安全走。
参考答案
三种传输方式与消息格式
MCP 的消息层统一是 JSON-RPC 2.0：请求带 jsonrpc、method、params、id，通知（notifications）没有 id，连接建立时走 initialize 握手协商协议版本和双方 capabilities。消息格式不变，变的是底下的传输层，目前三种：
- stdio：客户端把 server 作为子进程拉起，stdin 发请求、stdout 收响应。零网络配置，Claude Desktop、Cursor 这类桌面 Agent 的主流方式。局限是只能本机，server 进程生命周期和客户端绑定，做不了团队级共享服务。
- 旧 HTTP+SSE：两个端点，客户端 POST 发请求，另外挂一条
/sse长连接收服务端推送。问题出在架构上：请求和响应走两条通道，部署时要保证同一个客户端的两条通道路由到同一实例；SSE 是长连接，对 Serverless（函数有执行时长上限）、对需要滚动重启的服务都不友好。 - Streamable HTTP（2025 年规范引入，替代旧方案）：单一端点，客户端 POST 后，服务端可以按场景选择——简单请求直接返回普通 JSON 响应；需要流式或多条消息时，把这次响应升级成 SSE 流。它同时支持完全无状态模式（每次请求独立，天然适配 Serverless 和水平扩展）和有状态模式（带 session id），断线时可以用 Last-Event-ID 机制恢复事件流。
为什么不用 WebSocket
这是最容易被追问的点，我的理解是四层原因：
第一，通信模式不匹配。MCP 的核心交互是请求-响应（调工具、读资源）加少量服务端通知，这是 HTTP 的主场；WebSocket 的全双工优势在双方高频互推的场景，MCP 用不上。
第二，生态红利。选 HTTP 就白拿了整个 HTTP 基础设施：网关、负载均衡、CDN、标准鉴权头、TLS、企业的 API 管理工具。选 WebSocket 这些大半要重做。
第三，穿透性。企业网络里的代理、防火墙对普通 HTTPS 请求放行，对 WebSocket 的 Upgrade 握手经常有额外限制，跨组织部署远程 server 时这是真实的落地障碍。
第四，与无状态目标冲突。MCP 的远程化方向要求 server 能水平扩展、能跑在 Serverless 上，WebSocket 长连接天然绑定实例，和这个目标对着干。Streamable HTTP 的无状态模式正是为此设计的。
公平地说，如果哪天出现需要毫秒级双向实时推送的 Agent 场景，WebSocket 或 WebTransport 会回归视野，但那不是 MCP 当前要解决的问题。
部署上的实践经验
本地开发用 stdio 最省事；团队共享的远程 server 直接上 Streamable HTTP，跳过旧 HTTP+SSE（已被规范标记为 legacy）。有状态模式下要处理 session 亲和，无状态模式注意每次请求都得自包含鉴权信息。鉴权方面，远程 server 按规范走 OAuth 2.1，别自己发明 token 方案。
可能的追问
- stdio 模式有什么安全风险？ 答：server 是本地子进程，权限和宿主一样大，恶意 server 配置等于在你机器上执行任意命令；对策是只装可信来源的 server、配置变更要用户确认、敏感环境用容器隔离。
- 断线恢复具体怎么做的？ 答：SSE 流里每个事件带 id，客户端断开后用 Last-Event-ID 重新发起，服务端重放缺失事件；前提是服务端愿意缓存事件窗口，无状态模式下这个能力受限。
- 远程 MCP 的鉴权方案？ 答：规范采用 OAuth 2.1，client 走标准授权码流程拿 token，server 校验；企业内网可以简化成网关统一鉴权，但协议字段保持标准。