最近在学一个harness架构，其中MCP层与客户端的连接有三种方式，考虑到MCP协议与通信协议之间的关系，在这里做一个详细区分。

通信协议

传输层通道

1、stuio——本地单机内置工具服务

进程内部调用，无网络通信；

适用于单会话，单进程

2、SSE——服务端长连接，单向连接——底层复用http1.1

客户端-服务端仅一次单向握手；

单机多会话（所有stuio客户端）复用所有服务实例；

适用于单服务多会话

3、http 短链接（REST POST）

一问一答，每次新建TCP连接，响应完成后关闭连接；

每次响应携带会话ID，会话缓存在服务端内存，由多对话共享。

4、长轮询（JSON）

客户端接收到 HTTP 请求后挂起，有数据返回后立刻重连，伪长连接

只能客户端主动拉取数据，服务端无法主动推送（作为SSE/websocket的降级方案）。

5、websocket——双向实时传输

全双工双向实时通信，客户端、服务端可随时互发消息，天然支持多对话。

调用范式

1、RPC

基于 HTTP 短链接，用 JSON 承载调用方法、参数、返回值，就是 REST-RPC / JSON-RPC POST。可底层替换 Stdio/WebSocket/gRPC

2、gRPC——Google 标准化 RPC 框架

基于http2实现

序列化：Protobuf 二进制，强类型要求，浏览器兼容性差

MCP

MCP的目标：客户端调用服务器的方法，服务器可以返回结果。根据这个需求，结合适用场景设计以下方案：

1、stuio

不依赖任何 HTTP

通过进程 stdin/stdout 二进制流通信——通过进程的标准输入（stdin）发送请求、从标准输出（stdout）读取响应，无 TCP/HTTP 层。

2、streamable http（官方远程标准）

基于http1.1实现

在远程场景下，客户端通过网络连接访问服务器：客户端POST RPC格式的消息，服务器根据需求选择直接返回JSON或者流式返回；

更适合多人协作的场景：服务器部署在云端，用户在客户端通过网络连接进行访问，相应的，在使用时会受到延迟、网络抖动的影响（这是stuio不需要担心的）。

3、SSE（server-sent-events）【弃用】

属于早期MCP协议规范，分离/sse、/message双端点，会话、流、故障排查割裂——

在一组对话中，客户端向服务器的请求通过POST端口发送，而服务器向客户端的同送通过另一个端点，上行/下行出现问题时无法定位对应的SSE流或者发送流是否出现问题。

补充：http版本对比

http1.0：

基于TCP实现，无持久连接；

无host头部（一个IP只能绑定一个域名），无头部压缩；

http1.1：

基于TCP实现，默认持久连接（keep-alive）；

Pipeline 允许连续发多个请求，但响应严格 FIFO，引发 HTTP 层队头阻塞；

http2.0：

基于TCP实现，复用TCP语义，底层重构传输层架构，拆分为Header帧、Data帧、控制帧；

单TCP多路复用：一条连接内多独立Stream，帧携带StreamID乱序传输，接收端按ID重组，解决HTTP层队头阻塞；单TCP丢包时会导致全部流阻塞。

头部压缩；

gRPC强制依赖http2.0

http3.0（QUIC，下一代实时通信）：

基于UDP实现；

每隔http流独立传输，不存在阻塞问题；

浏览器兼容性好，网关兼容差。