大家通过上面这张图简单了解一下什么是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协议将更好地满足现代应用架构的需求，为开发者提供更强大、更可靠的消息通信能力。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |