HTTP + SSE vs Streamable HTTP

长按二维码关注

4.1 TCP 连接数对比

 

利用 Python 程序模拟 1000 个用户同时并发访问远程的 MCP Server 并调用获取工具列表,图中可以看出 SSE Server 的 SSE 连接无法复用且需要长期维护,高并发的需求也会带来 TCP 连接数的突增,而 Streamable HTTP 协议则可以直接返回响应,多个请求可以复用同一个 TCP 连接,TCP 连接数最高只到几十条,并且整体执行时间也只有 SSE Server 的四分之一。

在 1000 个并发用户的测试场景下,Higress 部署的 Streamable HTTP 方案的 TCP 连接数明显低于 HTTP + SSE 方案:

HTTP + SSE:需要维持大量长连接,TCP连接数随时间持续增长

Streamable HTTP:按需建立连接,TCP连接数维持在较低水平

 

4.2 请求成功率对比

 

实际应用场景中进程级别通常会限制最大连接数,linux 默认通常是 1024。利用 Python 程序模拟不同数量的用户访问远程的 MCP Server 并调用获取工具列表,SSE Server 在并发请求数到达最大连接数限制后,成功率会极速下降,大量的并发请求无法建立新的 SSE 连接而访问失败。

在不同并发用户数下的请求成功率测试中,Higress 部署的 Streamable HTTP 的成功率显著高于 HTTP + SSE 方案:

HTTP + SSE:随着并发用户数增加,成功率显著下降

Streamable HTTP:即使在高并发场景下仍能保持较高的请求成功率

 

5. 性能对比

 

这里对比的是社区 Python 版本的 GitHUB MCP Server【2】 和 Higress MCP 市场的 GitHUB MCP Server

利用 Python 程序模拟不同数量的用户同时并发访问远程的 MCP Server 并调用获取工具列表,并统计调用返回响应的时间,图中给出的响应时间对比为对数刻度,SSE Server 在并发用户数量较多时平均响应时间会从 0.0018s 显著增加到 1.5112s,而 Higress 部署的 Streamable HTTP Server 则依然维持在 0.0075s 的响应时间,也得益于 Higress 生产级的性能相比于 Python Starlette 框架。

性能测试结果显示,Higress 部署的 Streamable HTTP 在响应时间方面具有明显优势:

Streamable HTTP 的平均响应时间更短,响应时间波动较小,随并发用户数增加,响应时间增长更平

HTTP + SSE 的平均响应时间更长,在高并发场景下响应时间波动较大

 

6. 客户端复杂度对比

 

Streamable HTTP 支持无状态的服务和有状态的服务,目前的大部分场景无状态的 Streamable HTTP 的可以解决,通过对比两种传输方案的客户端实现代码,可以直观地看到无状态的 Streamable HTTP 的客户端实现简洁性。

Streamable HTTP

MCP(Model Context Protocol)协议是一个用于 AI 模型和工具之间通信的标准协议。随着 AI 应用变得越来越复杂并被广泛部署,原有的通信机制面临着一系列挑战。近期 MCP 仓库的 PR #206引入了一个全新的 Streamable HTTP 传输层替代原有的 HTTP+SSE 传输层。

 

扫二维码

关注我们

不迷路^_^


我们愿景

城市更繁荣

乡村更美丽