核心要点

  • 能说清传输层职责：在 client 与 server 之间收发 JSON-RPC 2.0 消息，与上层协议语义解耦

  • 能列举三种传输：stdio（本地子进程、最简最快）、旧版 HTTP+SSE（双端点、已被取代）、Streamable HTTP（2025 新版、单 /mcp 端点）

  • 能讲 Streamable HTTP 的改进：单端点、可选 SSE 流式、支持断线重连（Last-Event-ID），更适合远程与 Serverless

  • 能给选型结论并带安全意识：本地用 stdio，远程/横向扩展用 Streamable HTTP；远程务必做鉴权与 Origin 校验

标准回答

传输层在 MCP 里的位置

MCP（Model Context Protocol）把「协议语义」和「消息怎么传」分开。无论哪种传输，承载的都是 JSON-RPC 2.0 消息（请求、响应、通知）。传输层只负责把这些消息在 client 和 server 之间可靠地搬运，因此选型本质是选「连接方式」，不影响工具调用、资源、提示等上层能力。

stdio：本地子进程

client 把 server 作为子进程拉起，通过标准输入写请求、标准输出读响应（stderr 留给日志）。没有网络栈、没有握手开销，延迟最低、实现最简单，是本地工具（读写本地文件、调本地 CLI、连本机数据库）的首选。缺点是天然单机单客户端，无法被远程或多个客户端共享。

旧版 HTTP+SSE：双端点方案

早期远程方案：客户端用一个 POST 端点发消息，再单独开一条 SSE（Server-Sent Events）长连接接收服务端推送。两个端点、状态耦合，断线后难以恢复，对 Serverless/无状态部署不友好。它已被新版取代，新项目不建议再用，只在对接老 server 时需要兼容。

Streamable HTTP：2025 新版远程标准

收敛成单个 /mcp 端点：客户端 POST 发请求，服务端可以直接返回一个 JSON 响应，也可以「升级」成 SSE 流逐步推送（适合长任务、流式输出、服务端主动通知）。配合 Mcp-Session-Id 维持会话、用 Last-Event-ID 实现断线重连续传。单端点、可无状态化，天然契合远程服务、网关和 Serverless，也更容易横向扩展。

选型结论

本地集成、单客户端、追求最低延迟 → stdio；需要远程访问、多客户端共享、跑在 Serverless 或要横向扩展 → Streamable HTTP；遇到 HTTP+SSE 只做兼容、不做新选型。

常见误区

⚠️ 常见踩坑

远程 MCP server 千万别裸跑：要做鉴权（OAuth 2.1 等）、严格校验 Origin 头防 DNS rebinding，并尽量绑定到 127.0.0.1 而非 0.0.0.0；误以为「换成 HTTP 就只是改个地址」会留下严重安全漏洞。

追问

追问 1：Streamable HTTP 相比旧版 HTTP+SSE 到底改进了什么？

三点：一是从「POST + 独立 SSE」两个端点收敛为单个 /mcp 端点，降低耦合；二是响应可选择普通 JSON 或升级为 SSE 流，无需为每个会话长期占用连接，更适合 Serverless；三是引入会话 ID 与 Last-Event-ID 续传，断线后能从断点恢复，提升了远程可靠性。

追问 2：同一个 server 想同时支持本地和远程客户端怎么办？

通常做成两套传输入口共用同一份业务逻辑：本地场景暴露 stdio 入口，远程场景暴露 Streamable HTTP 入口，工具/资源实现层保持一致。多数 MCP SDK 已把传输抽象成可插拔层，切换传输不必改业务代码。

追问 3：远程 MCP 的鉴权一般怎么做？

主流是把 MCP server 当作 OAuth 2.1 受保护资源：客户端携带 Bearer Token，server 校验 token 的签发方、受众与作用域后再放行工具调用。再叠加 Origin 校验、HTTPS、最小权限的工具暴露和速率限制，形成纵深防御。

🔗 相似问题

同一考点的不同问法，面试官可能换着问，一起刷更稳

没找到想看的面试题？把你想看的告诉我们 →

延伸学习

按主题分类的相关资源，便于系统复习

核心术语

查看更多 →