聊聊MCP三种通信机制 —— 一场技术面试实录

本地场景→ 选stdio，零网络开销，调试方便远程场景→ 选Streamable HTTP，延迟低（~7.5ms），防火墙友好存量SSE系统→ 用mcp-remote适配器过渡，尽快迁移。

八月的冰可乐

134人浏览 · 2026-03-01 17:24:00

八月的冰可乐 · 2026-03-01 17:24:00 发布

聊聊MCP三种通信机制 —— 一场技术面试实录

1. 第一回合：MCP协议与通信机制概述

秋风：小哈，我看你简历上写了MCP Server开发经验，聊聊你对MCP的理解？

小哈：MCP就是一套给AI用的通信协议，主要解决以前AI想使用工具很困难的问题，之前AI想对接工具，不同的模型就得加不同的适配器，类似那个Function Calling，MCP出现后，就只需要按照MCP的方式将外部工具，数据源等封装好，各种大模型就能直接使用

秋风：那你说说MCP和大模型有哪几种通信协议？

小哈：（想了想）传输层目前有三种——stdio用于本地、HTTP+SSE用于远程、还有Streamable HTTP，不过SSE的方式已经要废弃了。

秋风：为什么要搞这么多种？

小哈：应用的场景不一样。比如你本地测试，在IDE插件跑在本地，用stdio最简单，部署更新都很方便；服务器或者云端部署就得走HTTP。这跟数据库连接似的，本地用socket、远程用TCP，原理差不多。

2. 第二回合：stdio机制深度剖析

秋风：那就从stdio开始，讲讲它的实现原理。

小哈：stdio本质上是进程间通信。Host把MCP Server当子进程启动，通过管道传数据。

秋风：数据流向呢？

小哈：Server从stdin读请求，往stdout写响应。请求路径大致这样的：Host → Server进程的 stdin → Server(读取并处理) 响应路径：Server → Server进程的 stdout → Host(读取并解析)

秋风：遇到过什么典型问题没有？

小哈：有，估计使用过的人都有过，我之前调试的时候往stdout打了个debug日志，结果整个Server直接崩了。调查后发现，所有日志必须走stderr，stdout只能有JSON消息，任何其它格式数据都不支持。

3. 第三回合：SSE废弃与Streamable HTTP革新

秋风：你之前说过三种方式，还提到了SSE被废弃了，那说说你对SSE被废弃的理解吧。

小哈：SSE长连接会中断，这是它的硬伤。我们知道SSE是三次握手连接的，也就是双通道架构的设计。为啥会中断呢？比如我们的客户端发送POST请求到/messages，服务器接收请求后，通过SSE长连接持续推结果。问题是，一但超时，例如请求设置的超时、公司防火墙超时等，动不动就断。其它问题还有资源效率低下、高并发情况内存占用过高

秋风：那换成Streamable HTTP的好处是什么？

小哈：Streamable HTTP，它对外宣传的核心思想：“一个连接，一个请求，按需流式”。

秋风：具体说说看

小哈：一个连接指的它废弃了双通道，每个MCP工具调用都使用一个独立的、短暂的TCP/HTTP连接 一个请求则是它能同时处理GET和POST，所有通信——无论是普通请求、流式响应还是服务器通知——都合并到单个端点（如 /mcp），简单来说，以前的“一发一收”是两个HTTP交互，现在同时处理后就变成了“一发一收”一个HTTP交互。 按需流式则是服务器返回时，会一次次的返回流式响应，数据会一块一块的按需发送过来。按需还有一层还是，就是智能决定返回内容，如果生成数据量小则一次发送，否则流式持续发送。

秋风：相较于SSE还有什么好处吗？

小哈：效率差距也很大。延迟和内存方面都有优势、还支持断线重连，是通过Last-Event-ID实现的。