|
大家通过上面这张图简单了解一下什么是MCP MCP协议迎来重大更新，引入了全新的Streamable HTTP传输机制。这一更新解决了当前HTTP+SSE传输方式的关键限制，同时保留了其优势。这项改进得益于来自Shopify、Pydantic、Cloudflare、LangChain、Vercel、Anthropic团队及MCP社区众多成员的宝贵反馈。
主要变更 与当前HTTP+SSE传输相比，新版本有以下变化： -移除了`/sse`端点 -所有客户端→服务器消息通过`/message`(或类似)端点传输 -所有客户端→服务器请求都可由服务器升级为SSE，用于发送通知/请求 -客户端在请求头中提供会话ID；服务器可根据需要关注此ID -客户端可通过空GET请求到`/message`端点来初始化SSE流 这种方法可以向后兼容实现，并允许服务器根据需要完全无状态运行。
更新动机 当前的远程MCP通过HTTP+SSE传输工作，存在以下问题： -不支持恢复性 -要求服务器维护高可用性的长连接 -服务器消息只能通过SSE传递
主要优势 1.无状态服务器可行性：不再需要高可用性的长连接 2.纯HTTP实现：MCP可在纯HTTP服务器中实现，无需SSE支持 3.基础设施兼容性：仅是"普通HTTP"，确保与中间件和基础设施兼容 4.向后兼容：现有传输机制的增量演进 5.灵活升级路径：服务器可根据需要使用SSE进行流式响应
应用场景
无状态服务器 一个完全无状态的服务器可以不支持长连接： -始终确认初始化（无需保存状态） -通过单个JSON-RPC响应处理工具列表请求 -执行工具调用请求，完成后将响应作为HTTP响应体返回
带流式处理的无状态服务器 无状态服务器仍可利用流式处理： -接收工具调用请求时，服务器指示响应将使用SSE -执行工具时发送进度通知 -工具执行完成后发送响应并关闭SSE流
有状态服务器 类似当前实现，但需要处理会话ID头，以便在水平扩展部署中正确路由消息。
为何不选择WebSocket 团队详细讨论了将WebSocket作为主要远程传输的可能性，但决定暂不采用，原因如下： -在"RPC式"使用场景下会产生不必要的运营和网络开销 -浏览器无法附加授权等头信息 -只有GET请求可透明升级到WebSocket，需要复杂的两步升级过程
总结 此次更新为MCP协议带来更高的灵活性和稳健性，使其能够适应更广泛的应用场景。虽然当前选择了基于HTTP的方案，但未来仍可能探索WebSocket等其他传输方式。 通过这次技术升级，MCP协议将更好地满足现代应用架构的需求，为开发者提供更强大、更可靠的消息通信能力。
| 
