MCP 协议采用 stdio 和 Streamable HTTP 两种通信方式。stdio 适用于本地场景通过标准输入输出直接通信延迟低且无需网络Streamable HTTP 是推荐的远程传输方式支持多 Client 共享 Server架构更简洁。两种方式底层消息格式统一为 JSON-RPC 2.0体现了传输方式和消息格式的解耦设计。面试官MCP 协议通常采用什么通信方式♂️我MCP 应该是用 WebSocket 吧因为需要双向通信Client 发请求、Server 推结果WebSocket 全双工正好合适。面试官MCP 并没有用 WebSocket。你想想MCP 有本地工具和远程工具两种场景本地场景需要走网络吗♂️我本地的话……应该也是走 HTTP 吧在本机起个服务Client 通过 localhost 访问面试官想复杂了。本地场景用的是 stdio直接通过进程的标准输入输出通信根本不需要网络。远程场景才用 HTTP而且不是 WebSocket是 SSE。另外不管哪种传输方式底层消息格式统一用 JSON-RPC 2.0这一点你也没提到。传输方式和消息格式是解耦的这个设计是 MCP 灵活性的关键。看来通信方式这块确实有不少容易搞混的地方下面我把 MCP 的消息格式和两种传输方式都讲清楚。 简要回答MCP 支持两种主要的传输方式分别适用于不同场景。本地场景用 stdioClient 把 Server 作为子进程启动通过标准输入输出通信延迟极低不用开端口也没有网络安全问题我用 Claude Desktop 接本地工具走的就是这种方式。远程场景现在推荐用 Streamable HTTPServer 作为独立的 HTTP 服务部署多个 Client 可以共享同一个 Server适合团队统一管理工具服务。MCP 早期版本2024-11-05 规范的远程传输是「HTTP SSE」双端点方案2025 年 3 月的规范更新里被标记为 deprecated保留向后兼容但不推荐新项目使用Streamable HTTP 成为了推荐的远程传输方式。不管哪种传输方式底层消息格式都统一用 JSON-RPC 2.0传输方式只影响「怎么传」消息协议本身不变。 详细解析MCP 的消息格式JSON-RPC 2.0在说传输方式之前先说消息格式因为不管用哪种传输方式消息格式都是同一套。那为什么 MCP 选了 JSON-RPC 2.0 呢其实原因很朴素MCP 需要一种「Client 调用 Server 的方法Server 返回结果」的通信模式这本质上就是远程过程调用RPC。而 JSON-RPC 2.0 是现成的、足够轻量的 RPC 规范用 JSON 格式易读易调试任何编程语言都能实现不管 Server 是 Python 写的还是 TypeScript 写的消息格式都一样不需要额外的序列化工具。每条消息就是一个 JSON 对象格式固定// 请求消息Client - Server { jsonrpc: 2.0, id: 1, // 请求 ID用于匹配响应 method: tools/call, // 调用的方法名 params: { name: take_screenshot, // 工具名 arguments: {url: https://example.com} } } // 响应消息Server - Client { jsonrpc: 2.0, id: 1, // 对应请求的 ID result: { content: [{type: image, data: ...base64...}] } }JSON-RPC 本身只定义消息格式不关心底层怎么传输MCP 在此基础上定义了两种传输层实现。传输方式一stdio标准输入输出stdio 是 MCP 最常用的传输方式适合本地工具的场景。工作原理MCP Client比如 Claude Desktop在启动时把 MCP Server 当作一个子进程启动然后通过进程的标准输入stdin发送请求、从标准输出stdout读取响应。两个进程在同一台机器上运行通过操作系统的管道通信。这里的「管道」到底是什么你可以把它理解成操作系统在内存里给这两个进程分配的一段先进先出的小缓冲区Client 往里塞一行 JSONServer 从缓冲区的另一头读出来处理Server 处理完再往另一条管道里塞一行 JSONClient 从那头读。整个过程不经过网卡、不经过 TCP/IP 协议栈数据在 RAM 里走了一趟就到了所以延迟天然比网络请求低得多也不需要序列化成网络可传输的字节流。stdio 方式有几个很明显的优点。首先延迟极低进程间通信比走网络快得多数据直接在操作系统管道里流转几乎没有开销。其次不需要开端口也就没有网络安全问题不用担心外部访问。另外 Server 的生命周期是自动管理的随 Client 启动而启动、随 Client 关闭而关闭不需要你手动去管进程。在实际使用中你只需要在配置文件里告诉 Client「用什么命令启动 Server」就行了比如在 Claude Desktop 的claude_desktop_config.json里这样配置{ mcpServers: { filesystem: { command: npx, // 启动命令 args: [-y, modelcontextprotocol/server-filesystem, /tmp], env: {} // 环境变量可选 } } }传输方式二Streamable HTTP当前标准的远程传输远程场景下Server 作为独立的 HTTP 服务运行Client 通过网络连接访问。MCP 当前推荐的远程传输方式是 Streamable HTTP。Streamable HTTP 的核心设计是用单个 HTTP 端点通常是/mcp同时处理请求和响应。Client 通过 POST 请求发送 JSON-RPC 消息Server 可以选择两种方式返回如果是简单的同步操作直接返回一个普通的 JSON 响应就行如果是需要流式输出的操作Server 返回一个 SSE 流持续推送数据。这种「按需选择」的设计非常灵活不需要强制建立长连接。Streamable HTTP 的优点很明确。Server 可以部署在云端多个 Client 共享同一个 Server这对团队来说特别实用比如团队共用一个部署在服务器上的数据库 MCP Server所有人连同一个服务就行不需要各自在本地跑一份。而且支持跨机器访问不局限于本地环境适合需要统一管理工具服务的团队或平台。当然相比 stdio 多了网络开销延迟会略高一些而且你还需要处理认证、网络中断重连等在本地场景下完全不用操心的问题。为什么 SSE 被弃用了你可能看到一些早期的 MCP 教程还在讲 SSEServer-Sent Events传输方式这里要说明一下HTTP SSE 双端点方案是 MCP 早期版本2024-11-05 规范采用的远程传输方案在 2025 年 3 月的规范更新里被标记为 deprecated仍然保留向后兼容但新项目应该直接用 Streamable HTTP。为什么要替换原因是架构上有一个小尴尬Client 向 Server 发请求要走 POST 端点Server 向 Client 推数据要走另一条 SSE 长连接端点同一个对话被拆成了两条通道。这带来的具体问题是状态管理复杂比如 Client POST 了一条消息之后网络突然断了那条消息到底被处理了没、SSE 流会不会推回结果Client 没有一个简单的办法判断出问题时排查链路很长。Streamable HTTP 的做法是把这两条通道合并成一个端点Client 照样 POST 发请求Server 根据情况决定返回「一个普通 JSON」还是「一条 SSE 流」不需要 Client 提前开另一条连接。注意这里的关键Streamable HTTP 并没有抛弃 SSE流式推送的部分底层还是 SSEContent-Type: text/event-stream只是把端点从两个合成一个。架构更简洁、对负载均衡和 serverless 环境都更友好。目前主流的 MCP 客户端和 SDK 都已经迁移到了 Streamable HTTP。 面试总结回到开头踩的雷最常见的误区就是想当然地以为 MCP 用 WebSocket 或者 HTTP REST 接口。面试回答这道题首先要说清楚 MCP 支持两种传输方式本地场景用 stdio标准输入输出Server 作为子进程运行通过管道通信远程场景用 Streamable HTTPServer 作为 HTTP 服务部署单个端点同时处理请求和响应。stdio 不走网络、延迟极低、生命周期自动管理Streamable HTTP 支持多 Client 共享一个 Server适合团队统一部署。第二个要点是消息格式和传输方式的解耦。不管用 stdio 还是 Streamable HTTP底层消息格式都统一用 JSON-RPC 2.0切换传输方式不影响上层调用逻辑。这个解耦设计是面试官比较看重的点说明你理解了 MCP 的分层架构而不是把「消息格式」和「传输方式」混为一谈。最后可以加分提一句传输方案的演进历史MCP 早期2024-11-05 规范的远程传输是「HTTP SSE」双端点方案因为两条通道状态管理复杂2025 年 3 月的规范更新里被 Streamable HTTP 取代单端点内部流式仍然走 SSE。能把 SSE 和 Streamable HTTP 的区别说清楚是这题的关键历史背景是加分项。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取
MCP 协议通信方式深度解析：从 WebSocket 到 Streamable HTTP，小白程序员必备收藏指南！
MCP 协议采用 stdio 和 Streamable HTTP 两种通信方式。stdio 适用于本地场景通过标准输入输出直接通信延迟低且无需网络Streamable HTTP 是推荐的远程传输方式支持多 Client 共享 Server架构更简洁。两种方式底层消息格式统一为 JSON-RPC 2.0体现了传输方式和消息格式的解耦设计。面试官MCP 协议通常采用什么通信方式♂️我MCP 应该是用 WebSocket 吧因为需要双向通信Client 发请求、Server 推结果WebSocket 全双工正好合适。面试官MCP 并没有用 WebSocket。你想想MCP 有本地工具和远程工具两种场景本地场景需要走网络吗♂️我本地的话……应该也是走 HTTP 吧在本机起个服务Client 通过 localhost 访问面试官想复杂了。本地场景用的是 stdio直接通过进程的标准输入输出通信根本不需要网络。远程场景才用 HTTP而且不是 WebSocket是 SSE。另外不管哪种传输方式底层消息格式统一用 JSON-RPC 2.0这一点你也没提到。传输方式和消息格式是解耦的这个设计是 MCP 灵活性的关键。看来通信方式这块确实有不少容易搞混的地方下面我把 MCP 的消息格式和两种传输方式都讲清楚。 简要回答MCP 支持两种主要的传输方式分别适用于不同场景。本地场景用 stdioClient 把 Server 作为子进程启动通过标准输入输出通信延迟极低不用开端口也没有网络安全问题我用 Claude Desktop 接本地工具走的就是这种方式。远程场景现在推荐用 Streamable HTTPServer 作为独立的 HTTP 服务部署多个 Client 可以共享同一个 Server适合团队统一管理工具服务。MCP 早期版本2024-11-05 规范的远程传输是「HTTP SSE」双端点方案2025 年 3 月的规范更新里被标记为 deprecated保留向后兼容但不推荐新项目使用Streamable HTTP 成为了推荐的远程传输方式。不管哪种传输方式底层消息格式都统一用 JSON-RPC 2.0传输方式只影响「怎么传」消息协议本身不变。 详细解析MCP 的消息格式JSON-RPC 2.0在说传输方式之前先说消息格式因为不管用哪种传输方式消息格式都是同一套。那为什么 MCP 选了 JSON-RPC 2.0 呢其实原因很朴素MCP 需要一种「Client 调用 Server 的方法Server 返回结果」的通信模式这本质上就是远程过程调用RPC。而 JSON-RPC 2.0 是现成的、足够轻量的 RPC 规范用 JSON 格式易读易调试任何编程语言都能实现不管 Server 是 Python 写的还是 TypeScript 写的消息格式都一样不需要额外的序列化工具。每条消息就是一个 JSON 对象格式固定// 请求消息Client - Server { jsonrpc: 2.0, id: 1, // 请求 ID用于匹配响应 method: tools/call, // 调用的方法名 params: { name: take_screenshot, // 工具名 arguments: {url: https://example.com} } } // 响应消息Server - Client { jsonrpc: 2.0, id: 1, // 对应请求的 ID result: { content: [{type: image, data: ...base64...}] } }JSON-RPC 本身只定义消息格式不关心底层怎么传输MCP 在此基础上定义了两种传输层实现。传输方式一stdio标准输入输出stdio 是 MCP 最常用的传输方式适合本地工具的场景。工作原理MCP Client比如 Claude Desktop在启动时把 MCP Server 当作一个子进程启动然后通过进程的标准输入stdin发送请求、从标准输出stdout读取响应。两个进程在同一台机器上运行通过操作系统的管道通信。这里的「管道」到底是什么你可以把它理解成操作系统在内存里给这两个进程分配的一段先进先出的小缓冲区Client 往里塞一行 JSONServer 从缓冲区的另一头读出来处理Server 处理完再往另一条管道里塞一行 JSONClient 从那头读。整个过程不经过网卡、不经过 TCP/IP 协议栈数据在 RAM 里走了一趟就到了所以延迟天然比网络请求低得多也不需要序列化成网络可传输的字节流。stdio 方式有几个很明显的优点。首先延迟极低进程间通信比走网络快得多数据直接在操作系统管道里流转几乎没有开销。其次不需要开端口也就没有网络安全问题不用担心外部访问。另外 Server 的生命周期是自动管理的随 Client 启动而启动、随 Client 关闭而关闭不需要你手动去管进程。在实际使用中你只需要在配置文件里告诉 Client「用什么命令启动 Server」就行了比如在 Claude Desktop 的claude_desktop_config.json里这样配置{ mcpServers: { filesystem: { command: npx, // 启动命令 args: [-y, modelcontextprotocol/server-filesystem, /tmp], env: {} // 环境变量可选 } } }传输方式二Streamable HTTP当前标准的远程传输远程场景下Server 作为独立的 HTTP 服务运行Client 通过网络连接访问。MCP 当前推荐的远程传输方式是 Streamable HTTP。Streamable HTTP 的核心设计是用单个 HTTP 端点通常是/mcp同时处理请求和响应。Client 通过 POST 请求发送 JSON-RPC 消息Server 可以选择两种方式返回如果是简单的同步操作直接返回一个普通的 JSON 响应就行如果是需要流式输出的操作Server 返回一个 SSE 流持续推送数据。这种「按需选择」的设计非常灵活不需要强制建立长连接。Streamable HTTP 的优点很明确。Server 可以部署在云端多个 Client 共享同一个 Server这对团队来说特别实用比如团队共用一个部署在服务器上的数据库 MCP Server所有人连同一个服务就行不需要各自在本地跑一份。而且支持跨机器访问不局限于本地环境适合需要统一管理工具服务的团队或平台。当然相比 stdio 多了网络开销延迟会略高一些而且你还需要处理认证、网络中断重连等在本地场景下完全不用操心的问题。为什么 SSE 被弃用了你可能看到一些早期的 MCP 教程还在讲 SSEServer-Sent Events传输方式这里要说明一下HTTP SSE 双端点方案是 MCP 早期版本2024-11-05 规范采用的远程传输方案在 2025 年 3 月的规范更新里被标记为 deprecated仍然保留向后兼容但新项目应该直接用 Streamable HTTP。为什么要替换原因是架构上有一个小尴尬Client 向 Server 发请求要走 POST 端点Server 向 Client 推数据要走另一条 SSE 长连接端点同一个对话被拆成了两条通道。这带来的具体问题是状态管理复杂比如 Client POST 了一条消息之后网络突然断了那条消息到底被处理了没、SSE 流会不会推回结果Client 没有一个简单的办法判断出问题时排查链路很长。Streamable HTTP 的做法是把这两条通道合并成一个端点Client 照样 POST 发请求Server 根据情况决定返回「一个普通 JSON」还是「一条 SSE 流」不需要 Client 提前开另一条连接。注意这里的关键Streamable HTTP 并没有抛弃 SSE流式推送的部分底层还是 SSEContent-Type: text/event-stream只是把端点从两个合成一个。架构更简洁、对负载均衡和 serverless 环境都更友好。目前主流的 MCP 客户端和 SDK 都已经迁移到了 Streamable HTTP。 面试总结回到开头踩的雷最常见的误区就是想当然地以为 MCP 用 WebSocket 或者 HTTP REST 接口。面试回答这道题首先要说清楚 MCP 支持两种传输方式本地场景用 stdio标准输入输出Server 作为子进程运行通过管道通信远程场景用 Streamable HTTPServer 作为 HTTP 服务部署单个端点同时处理请求和响应。stdio 不走网络、延迟极低、生命周期自动管理Streamable HTTP 支持多 Client 共享一个 Server适合团队统一部署。第二个要点是消息格式和传输方式的解耦。不管用 stdio 还是 Streamable HTTP底层消息格式都统一用 JSON-RPC 2.0切换传输方式不影响上层调用逻辑。这个解耦设计是面试官比较看重的点说明你理解了 MCP 的分层架构而不是把「消息格式」和「传输方式」混为一谈。最后可以加分提一句传输方案的演进历史MCP 早期2024-11-05 规范的远程传输是「HTTP SSE」双端点方案因为两条通道状态管理复杂2025 年 3 月的规范更新里被 Streamable HTTP 取代单端点内部流式仍然走 SSE。能把 SSE 和 Streamable HTTP 的区别说清楚是这题的关键历史背景是加分项。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取
