大模型流式输出：七大底层传输技术对比探究

一、引言

目前大模型逐字逐字流式输出的模式，一个重要因素是因为大模型思考和推理需要时间，为了缓解用户 "等完整输出" 的焦虑，而在用户体验上做出的优化。

在数字化与智能化深度融合的今天，已经不仅是AI对话、代码生成需要流式输出，实时音视频、物联网数据流等应用也对低延迟、高稳定的流式传输提出了严苛要求。而这一切的背后，都绕不开底层传输技术的支撑，也正是本文要深入对比分析的内容。

现代应用已不再满足于 "单次请求 - 响应" 的静态数据交互，而是对 "持续、高效、低延迟的数据流传输"（即流式传输）提出迫切需求。传统 HTTP 请求 - 响应模式的固有局限性被进一步放大，而两类差异化技术 ------"非流式的模拟实时方案" 与 "原生支持流式的传输技术"，共同构成了流式传输需求下的技术选择谱系。

从技术演进历程来看，流式传输的发展始终围绕 "突破非流式瓶颈、优化数据流连续性" 展开：

1. 非流式技术的过渡阶段：早期为模拟 "准实时" 效果，短轮询（客户端高频主动请求）、长轮询（客户端发起请求后保持连接至数据返回）成为临时方案，但二者均不具备 "持续数据流传输" 能力 ------ 短轮询存在高频空请求导致的带宽浪费，长轮询虽减少请求次数，却仍以 "单次连接 - 单次数据返回" 为核心，无法实现数据的流式推送，本质属于 "伪流式" 过渡方案；
2. 原生流式技术的奠基阶段：随着 HTML5 标准落地，WebSocket（全双工原生流式，支持客户端与服务器双向持续传输）、Server-Sent Events（SSE，服务端单向原生流式，专注服务器向客户端持续推送）成为首批原生支持流式传输的技术，打破了 "请求触发响应" 的桎梏，奠定了流式传输的技术基础；
3. 流式技术的细分与优化阶段：HTTP/2、HTTP/3 的普及推动了 Streamable HTTP 的发展，通过多路复用、二进制帧等特性优化流式传输效率，实现 "基于 HTTP 协议的高效数据流拆分与传输"；物联网场景的爆发催生了 MQTT（轻量级发布 / 订阅式流式协议，适配低带宽、弱网环境下的设备数据流）；跨语言、跨平台的服务通信需求则让 gRPC-Web（基于 HTTP/2 的流式 RPC 技术，支持客户端与服务端的流式调用）成为分布式系统中的重要选择。

2025 年，HTTP/3 的全面普及与 WebTransport 等新技术的补充，进一步丰富了流式传输的技术生态。本文将对短轮询、长轮询、WebSocket、Server-Sent Events (SSE)、Streamable HTTP、MQTT和gRPC-Web等七种数据传输技术，从延迟、带宽效率、实现复杂度、浏览器兼容性等维度进行对比，为不同场景下的技术选型提供参考。

二、短 轮询 技术详解

2.1 技术原理与工作机制

短轮询是最基础的数据传输技术，它基于传统的HTTP请求-响应模式，核心思想是客户端周期性地向服务器发送HTTP请求，询问是否有新数据。若有新数据，服务器返回响应；若无新数据，服务器也会立即返回空响应。

短 轮询 的工作流程：

1. 客户端向服务器发送HTTP请求

2. 服务器立即返回响应（无论是否有新数据）

3. 客户端收到响应后，等待一段时间（通常是固定的间隔）

4. 客户端再次发送请求，重复上述过程

这种技术的核心特点是简单直接，不需要特殊的服务器或客户端支持。

2.2 优劣势分析

优势：

• 实现简单：客户端和服务器逻辑都非常简单

• 兼容性 好：支持所有浏览器和HTTP服务器

• 无需特殊配置：不需要修改现有网络架构

• 易于调试：可以通过浏览器开发者工具直接查看请求和响应

• 对服务器压力可控：通过调整轮询间隔，可以控制服务器负载

劣势：

• 延迟高：数据更新的实时性取决于轮询间隔，平均响应延迟通常在300-500ms之间

• 资源浪费：即使没有新数据，客户端仍会定期发送请求

• 服务器负载高：在高并发场景下，大量无效请求会增加服务器压力

• 带宽消耗大：每个请求都包含完整的HTTP头，造成带宽浪费

• 电池消耗：在移动设备上，频繁的网络请求会快速消耗电池电量

2.3 适用场景与应用案例

适用场景：

• 实时性要求不高的场景（如非实时通知、数据更新频率低等）
• 简单的状态查询（如在线状态检测）
• 对服务器负载不敏感的小流量应用
• 需要兼容老旧浏览器的场景

典型案例：

• 简单的状态更新提示（如邮件提醒）
• 低频数据展示（如内部管理系统中的通知）
• 监控系统的状态更新（如服务器负载监控）

2.4 性能指标

指标	数值	说明
平均延迟	300-500ms	取决于轮询间隔
资源消耗	低	每次请求资源消耗小，但频繁请求累计消耗大
带宽利用率	低	HTTP头占比较大
实现复杂度	极低	只需基本的HTTP请求/响应处理
最大并发连接	高	取决于服务器配置
实时性	低	非真正的实时通信

三、长 轮询 技术详解

3.1 技术原理与工作机制

长轮询是对短轮询的改进，它通过延长服务器响应时间来减少不必要的请求次数。其核心思想是客户端发送HTTP请求后，服务器不立即返回响应，而是保持连接打开，直到有新数据或超时后才返回响应。客户端收到响应后立即发送下一个长轮询请求，形成"持续等待-即时响应"的循环。

长 轮询 的工作流程：

1. 客户端向服务器发送HTTP请求

2. 服务器接收请求后，如果没有新数据，将连接保持打开状态

3. 当有新数据到达或连接超时时，服务器返回响应

4. 客户端收到响应后，立即发送新的请求，重复上述过程

这种技术在保持简单实现的同时，显著降低了轮询的频率和延迟。

3.2 优劣势分析

优势：

• 实时性优于短 轮询：延迟取决于数据产生时间，而非固定轮询间隔

• 减少无效请求：相比短轮询，服务器在没有数据时不会立即响应

• 实现相对简单：不需要特殊的协议支持，基于标准HTTP

• 兼容性 好：支持所有浏览器和HTTP服务器，兼容性良好

• 资源利用率高于短 轮询：减少了请求数量和带宽消耗

劣势：

• 服务器资源消耗高：长时间保持连接会占用服务器资源

• 可能超时：网络波动或服务器负载高时，连接可能会超时

• 实现复杂度高于短 轮询：需要处理连接超时和重试逻辑

• 不支持真正的双向通信：客户端仍需主动发起请求

• 对代理服务器不友好：某些代理服务器可能会断开长时间保持的连接

3.3 适用场景与应用案例

适用场景：

• 实时性要求较高但不需要双向通信的场景
• 服务器资源相对充足的应用
• 需要兼容各种网络环境的应用
• 不能使用WebSocket等新技术的环境

典型案例：

• 早期的Web版股票行情系统
• 简单的即时通讯应用（如内部沟通工具）
• 物流信息的实时跟踪系统

3.4 性能指标

指标	数值	说明
平均延迟	100-200ms	低于短轮询，但仍有一定延迟
资源消耗	中等	连接保持需要一定资源
带宽利用率	中等	比短轮询高，但仍有HTTP头开销
实现复杂度	中低	需要处理连接超时和重试
最大并发连接	中	受服务器连接数限制
实时性	中等	比短轮询好，但仍非真正实时

四、WebSocket技术详解

4.1 技术原理与工作机制

WebSocket是HTML5定义的一种在单个TCP连接上进行全双工通信的协议，允许客户端和服务器之间进行实时的双向通信。它的核心特点是在建立初始连接后，允许数据在客户端和服务器之间双向传输，而无需客户端频繁发起请求。

WebSocket的工作流程主要分为三个阶段：

1. 握手阶段 客户端通过HTTP/HTTPS发送一个特殊的请求，请求升级到WebSocket协议：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

服务器如果支持WebSocket协议，将返回101状态码，表示协议切换成功：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

2. 数据传输阶段

一旦连接建立，客户端和服务器可以随时相互发送数据帧。数据帧可以是文本或二进制格式，这使得WebSocket非常灵活，适用于多种数据类型。

3. 连接关闭阶段

当一方决定关闭连接时，会发送一个关闭帧，另一方确认后连接终止。

4.2 优劣势分析

优势：

• 全双工通信：客户端和服务器可以同时发送和接收数据，实现真正的实时双向通信

• 低延迟：一旦连接建立，数据传输几乎没有延迟，适合高频实时场景

• 二进制数据支持：直接支持二进制数据传输，适用于多媒体和文件传输

• 协议效率高：相比HTTP请求-响应模式，数据包开销更小，传输效率更高

• 持久连接：一次连接可以传输多次数据，减少了频繁握手带来的开销

• 压缩支持：可以结合压缩算法进一步减少数据传输量

劣势：

• 连接管理复杂：需要处理心跳检测、断线重连、负载均衡等复杂逻辑

• 代理/防火墙 兼容性 问题：某些企业网络环境可能会阻止WebSocket连接

- 资源占用大：每个WebSocket连接都需要服务器维护一定的资源（如线程、内存等）

• 连接保持成本高：长时间保持连接会占用服务器资源

• 浏览器 兼容性 限制：虽然现代浏览器都支持，但旧版浏览器可能不支持

• 安全考虑：需要额外的安全措施，如WSS加密

4.3 适用场景与应用案例

适用场景：

• 需要双向实时通信的Web应用（如在线聊天、多人游戏）
• 实时协作工具（如白板、文档协作）
• 实时数据可视化（如监控仪表盘）
• 金融交易平台（如股票交易、加密货币交易）
• 实时监控系统（服务器性能监控、物联网设备状态监控）

典型案例：

• 微信网页版聊天功能
• 在线多人游戏（如棋牌游戏、休闲小游戏）
• 实时协作设计工具
• 金融市场实时交易系统

4.4 性能指标

指标	数值	说明
平均延迟	50-100ms	远低于轮询技术
资源消耗	高	每个连接需要保持一定资源
带宽利用率	高	协议开销小，数据传输效率高
实现复杂度	高	需要专门的WebSocket库和服务器支持
最大并发连接	中	受服务器内存和配置限制
实时性	高	接近实时的通信体验

五、Server-Sent Events (SSE)技术详解

5.1 技术原理与工作机制

Server-Sent Events (SSE)是一种基于HTTP长连接的单向通信技术，允许服务器主动向客户端推送数据。与WebSocket不同，SSE仅支持服务器到客户端的单向通信，适合于大多数推送场景。

SSE的工作流程：

1. 连接建立

客户端向服务器发送一个HTTP请求，请求头中包含Accept: text/event-stream，表示期望接收事件流数据：

GET /stream HTTP/1.1
Host: example.com
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

2. 服务器响应

服务器返回200 OK状态码，并设置Content-Type: text/event-stream，表示返回的是事件流数据：

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

3. 数据传输

服务器持续向客户端发送数据，数据格式为文本流，每个事件以data:开头，后跟具体数据：

data: {"price": 1499}\n\n
id: 42\n
event: stockUpdate \n
data: {"symbol": "TSLA"}\n\n

4. 连接维护

SSE使用三种机制确保连接可靠性：

• 自动重连：浏览器内置重试逻辑（默认3秒间隔）

• 事件ID追踪 ：通过Last-Event-ID头实现消息连续性

• 心跳维持：通过注释行保持连接活性

5.2 优劣势分析

优势：

• 简单实现：基于HTTP协议，实现和维护成本低，学习曲线平缓

• 自动重连：浏览器内置了断线重连机制

• 轻量级：相比WebSocket，SSE的协议开销更小，建立连接的成本更低

• 文本数据传输：支持UTF-8编码的文本数据，便于处理

• 浏览器原生支持：现代浏览器都原生支持SSE API

- 与HTTP/2协同工作：SSE与HTTP/2完美兼容，可利用HTTP/2的多路复用和头部压缩特性

劣势：

• 单向通信：只支持服务器向客户端发送数据，客户端不能主动向服务器发送数据

• 数据大小限制：某些浏览器对单次发送的数据大小有限制

• 代理 兼容性 问题：某些代理服务器可能会缓存或断开SSE连接

• 浏览器 兼容性：IE浏览器完全不支持SSE

• 无法传输二进制数据：只能传输UTF-8编码的文本数据

5.3 适用场景与应用案例

适用场景：

• 实时通知系统（如新闻推送、社交媒体更新、系统告警）
• 流式数据展示（如股票行情、体育比分等需要持续更新的数据）
• 进度跟踪（文件上传/下载进度、长时间任务执行进度）
• 日志监控（服务器日志实时显示在监控页面）
• AI聊天机器人（如ChatGPT的流式输出）

典型案例：

• 某电商平台的订单状态更新功能使用SSE技术，替代传统的轮询方式，节省了70%的流量消耗
• ChatGPT使用SSE实现"打字机"效果，让回答一句句"蹦"出来

5.4 性能指标

指标	数值	说明
平均延迟	100-200ms	与长轮询相当
资源消耗	低	比WebSocket消耗少
带宽利用率	中等	比WebSocket略高
实现复杂度	低	比WebSocket简单得多
最大并发连接	高	比WebSocket支持更多并发连接
实时性	中等	与长轮询相当

六、Streamable HTTP技术详解

6.1 技术原理与工作机制

Streamable HTTP是2025年初引入的一种新型数据传输技术，主要作为MCP（Model Context Protocol）协议的传输机制。它是对HTTP协议原生流式传输能力的创新应用，旨在提供更高效、更灵活的实时通信解决方案。

Streamable HTTP的核心思想是提供一个统一的HTTP端点，同时支持POST和GET方法：

• POST方法：用于客户端向服务器发送请求和接收响应
• GET方法（可选）：用于建立SSE流，接收服务器实时推送的消息

与传统HTTP+SSE不同，Streamable HTTP不要求维护单独的初始化连接和消息端点，简化了协议设计并提高了可靠性。

Streamable HTTP的核心特性包括：

• 多路复用：在单个连接上可以传输多个独立的数据流

• 请求优先级：可以为不同的请求设置优先级

• 二进制帧：使用二进制格式传输数据，提高效率

• 头部压缩：使用HPACK算法压缩HTTP头部，减少带宽消耗

Streamable HTTP的工作流程：

1. 客户端和服务器建立HTTP/2或HTTP/3连接
2. 客户端发送请求，服务器可以立即开始发送响应数据
3. 服务器可以分块发送数据，客户端可以流式处理数据
4. 连接保持打开状态，直到所有数据传输完成或连接关闭

6.2 优劣势分析

优势：

• 高性能：多路复用和二进制帧格式大大提高了传输效率

• 低延迟：请求和响应可以并行处理，减少了队头阻塞

• 头部压缩：HTTP头部压缩显著减少了带宽消耗

• 请求优先级：可以优化关键资源的加载顺序

• 与现有HTTP生态兼容：可以利用现有的HTTP工具和基础设施

劣势：

• 浏览器 兼容性：需要现代浏览器支持（Chrome 40+、Firefox 36+等）

• 服务器要求：需要服务器支持HTTP/2或HTTP/3协议

• 实现复杂度：相比传统HTTP，实现更加复杂

• 调试困难：二进制格式和多路复用使得调试更加困难

• 代理服务器 兼容性：某些代理服务器可能不支持HTTP/2或HTTP/3

6.3 适用场景与应用案例

适用场景：

• 实时视频和音频流传输
• 大型文件上传和下载
• 需要传输大量小文件的Web应用
• 实时数据分析和可视化
• 需要低延迟的API调用

典型案例：

• YouTube、Netflix等视频流平台使用HTTP/2优化视频加载
• 大型软件的分块下载和更新
• 实时音视频会议系统
• 金融数据的实时流式传输
• 云存储服务的文件上传下载

6.4 性能指标

指标	数值	说明
平均延迟	75ms (100并发)	低延迟，适合实时应用
资源消耗	极低 (5KB/请求)	高效的资源利用
带宽利用率	高	头部压缩和二进制格式提高效率
实现复杂度	高	需要HTTP/2或HTTP/3支持
最大并发连接	极高	多路复用支持大量并发请求
实时性	高	适合实时数据传输

七、 MQTT 技术详解

7.1 技术原理与工作机制

MQTT（Message Queuing Telemetry Transport）是一种专为物联网设备设计的轻量级发布-订阅消息协议，在低带宽、高延迟或不稳定的网络环境中表现出色。它基于TCP/IP协议，通过Broker（消息代理）进行消息分发。

MQTT 的核心特性包括：

• 发布/订阅模型：消息通过主题（Topic）进行发布和订阅

• 服务质量等级（ QoS ） ：支持三种不同的消息可靠性级别

• 轻量级：协议头最小仅2字节，适合资源受限设备

• 会话保持：支持持久会话，确保消息不会丢失

• 心跳机制：通过定期心跳包保持连接活跃

MQTT 的工作流程：

1. 客户端（发布者或订阅者）连接到MQTT Broker
2. 订阅者订阅感兴趣的主题
3. 发布者向特定主题发布消息
4. Broker将消息分发给所有订阅该主题的客户端

7.2 优劣势分析

优势：

• 极低的协议开销：协议头最小仅2字节，适合资源受限的IoT设备

• 低功耗设计：心跳机制和持久会话支持长时间运行在电池供电设备上

• 灵活的服务质量：通过QoS机制确保消息传递的可靠性

• 支持多种网络环境：在不稳定网络中表现良好，适合物联网场景

• 消息可靠性：通过QoS机制确保消息传递的可靠性

• 扩展性强：支持大量设备连接和高并发消息传输

劣势：

• 需要Broker支持：增加系统复杂度，需要维护Broker服务（如EMQX、HiveMQ）

• 浏览器支持有限：原生不支持浏览器，需要通过WebSocket桥接（MQTT over WebSocket）

• 非HTTP协议：与现有 Web 基础设施兼容性较差，需要特殊配置

• 学习曲线 较陡：需要理解发布/订阅模型和QoS机制

• 安全配置要求高：默认不加密，需要手动开启TLS/SSL等安全措施

7.3 适用场景与应用案例

适用场景：

• 物联网设备通信（如智能家居设备、工业传感器）
• 移动应用推送（作为推送通知的底层协议）
• 实时监控系统（远程监控设备状态和环境数据）
• 边缘计算场景（本地网关聚合多个设备数据）
• 大规模设备部署（对流量成本敏感的场景）

典型案例：

• 智能家居系统中，温湿度传感器通过MQTT上报数据，手机App通过MQTT控制智能设备
• 工业物联网中，工厂PLC设备通过MQTT实时传输运行状态至 SCADA 系统
• 农业监测系统中，土壤湿度传感器通过MQTT上传数据，网关汇总后批量上传至云端

7.4 性能指标

指标	数值	说明
协议头大小	2-4字节	比 HTTP小得多
平均延迟	50-150ms	与网络环境和QoS设置有关
最大并发连接数	百万级	取决于Broker的性能
数据传输效率	极高	二进制格式，协议开销小
资源消耗	低	适合嵌入式设备和低功耗场景
电池寿命影响	小	心跳机制优化，减少电量消耗
支持的QoS级别	3 级	QoS 0、1、2，满足不同可靠性需求

八、gRPC-Web技术详解

8.1 技术原理与工作机制

gRPC-Web是一个JavaScript客户端库，使Web应用程序能够直接与后端gRPC服务进行通信，而无需HTTP服务器充当中介。它允许通过使用.proto 文件定义客户端和服务器端数据类型和服务接口，构建真正的端到端gRPC应用程序体系结构。

gRPC-Web的核心特性包括：

• 强类型接口：使用.proto文件定义接口，自动生成客户端代码

• 二进制数据传输：使用Protocol Buffers二进制格式，比JSON更小更快

• 支持流式通信：支持客户端流式、服务器流式和双向流式通信

• 跨语言支持：客户端和服务器可以使用不同的编程语言实现

• 高性能：相比REST API，gRPC-Web具有更低的延迟和更高的吞吐量

gRPC-Web的工作流程：

1. 使用.proto文件定义服务接口和数据类型
2. 使用protoc工具生成客户端JavaScript代码
3. 客户端通过gRPC-Web库直接调用gRPC服务
4. 数据通过HTTP/1.1或HTTP/2传输，支持流式通信

8.2 优劣势分析

优势：

• 高性能：相比REST API，gRPC-Web具有更低的延迟和更高的吞吐量

• 强类型接口：编译期校验接口，避免REST常见的字段类型不匹配错误

• 二进制传输：使用Protocol Buffers二进制格式，比JSON小3-10倍，解析速度快2-10倍

• 支持流式通信：原生支持流式传输，适合实时数据场景

• 减少开发工作量：自动生成客户端和服务器代码，减少样板代码

• 跨语言一致性：客户端和服务器使用相同的接口定义，确保一致性

劣势：

• 学习曲线 陡：需要学习Protobuf语法和gRPC概念

• 浏览器 兼容性：需要gRPC-Web库支持，不是所有浏览器都原生支持

• 调试困难：二进制数据难以直接查看和调试

• 集成复杂性：需要与现有REST API集成时增加复杂性

• 工具链依赖：依赖protoc等工具生成代码

• 消息大小限制：默认配置存在4MB消息大小限制，大数据传输可能受限

8.3 适用场景与应用案例

适用场景：

• 微服务内部通信（特别是对性能要求高的场景）
• 金融交易系统（高频股票交易指令需要低延迟）
• 实时数据分析（需要处理大量数据并实时展示）
• 跨语言服务集成（不同语言编写的服务之间通信）
• 需要严格接口定义的企业级应用

典型案例：

• Netflix 将推荐服务的通信从REST换成gRPC后，平均延迟从167ms降到42ms，带宽消耗减少68%
• 某电商平台将内部服务通信从REST迁移到gRPC，QPS从3k提升到18k，提升500%
• 金融交易系统使用gRPC实现8ms延迟的交易指令传输，比REST快20倍

8.4 性能指标

指标	REST ( JSON )	gRPC-Web (Protobuf)	提升幅度
平均延迟	15ms	8ms	46.7%
吞吐量	5000QPS	12000QPS	140%
网络带宽消耗	1.2MB/s	380KB/s	315%
CPU利用率	38%	12%	216%
数据大小	较大	小3-10倍	-
解析速度	较慢	快2-10倍	-

九、七大技术的全面对比分析

9.1 核心指标对比

技术特性	短 轮询	长 轮询	WebSocket	SSE	Streamable HTTP	MQTT	gRPC-Web
通信方向	单向	单向	双向	单向	双向/单向	双向	双向
协议基础	HTTP	HTTP	WS/WSS	HTTP	HTTP	MQTT	HTTP/2
数据格式	文本	文本	文本/二进制	文本	文本/二进制	二进制	二进制
连接方式	每次请求新建	保持连接	一次握手	一次请求	标准HTTP请求	TCP连接	HTTP请求
平均延迟	300-500ms	100-200ms	50-100ms	100-200ms	75ms (100并发)	50-150ms	8-15ms
高并发延迟	线性增长	线性增长	稳定	指数增长	稳定 (7.5ms@1000并发)	稳定	稳定
浏览器支持	100%	100%	97.33%	93.7%	现代浏览器	需WebSocket桥接	现代浏览器
服务器资源消耗	低	中等	高	低	极低	中等	高
协议开销	高	中高	低	中	低	极低	低
实现复杂度	低	中低	高	中	高	中	高
双向通信	不支持	不支持	支持	不支持	支持	支持	支持
自动重连	需手动实现	需手动实现	需手动实现	浏览器内置	需手动实现	需手动实现	需手动实现
流支持	不支持	不支持	支持	支持	支持	支持	支持

9.2 资源消耗对比

技术 选型	每个连接 内存 消耗	最大并发连接数	连接建立成本	带宽利用率
短 轮询	低	高	高	低
长 轮询	中等	中	中	中
WebSocket	高 (约5MB)	中	低	高
SSE	低 (约 2MB)	高	低	中
Streamable HTTP	极低 (5KB/请求)	极高	低	高
MQTT	低	极高	低	极高
gRPC-Web	高	中	中	高

9.3 延迟与 吞吐量 对比

技术 选型	平均延迟 ( ms )	吞吐量 ( QPS )	数据传输效率	高并发表现
短 轮询	300-500	低	低	差
长 轮询	100-200	中等	中等	中等
WebSocket	50-100	高	高	好
SSE	100-200	中等	中等	差 (高并发延迟飙升)
Streamable HTTP	75 (100 并发)	高	高	极好
MQTT	50-150	极高	极高	好
gRPC-Web	8-15	极高	极高	极好

9.4 浏览器 兼容性 对比

技术 选型	现代浏览器支持	IE 支持	移动端支持	兼容性 备注
短 轮询	100%	全支持	全支持	无兼容性问题
长 轮询	100%	全支持	全支持	无兼容性问题
WebSocket	97.33%	IE10+	全支持	微信小程序需适配
SSE	93.7%	不支持	iOS15+受限	IE完全不支持
Streamable HTTP	逐渐提升	不支持	部分支持	依赖现代浏览器特性
MQTT	需WebSocket桥接	需WebSocket桥接	需WebSocket桥接	原生不支持浏览器
gRPC-Web	现代浏览器	有限	支持	需要客户端库支持

十、未来趋势与技术展望

10.1 HTTP/3对实时传输的影响

HTTP/3（基于QUIC协议）的普及正在改变实时数据传输的格局：

• 0- RTT 连接建立：显著降低首次连接延迟

• 连接迁移：设备在不同网络间切换时，连接可以无缝迁移

• 前向纠错：在高丢包环境下仍能保持较高的传输可靠性

• 多路复用：客户端和服务器可以使用不同的编程语言实现

• 高性能：彻底解决TCP的队头阻塞问题

HTTP/3对SSE和WebSocket的性能提升尤为明显。在HTTP/3环境下，SSE可以实现更快的连接建立、更低的延迟和更高的可靠性，特别适合在弱网环境下使用。

10.2 WebTransport的崛起

WebTransport是一种新兴的实时数据传输协议，在2025年已开始在部分浏览器中支持。它提供了比WebSocket更高效的传输能力，主要特点包括：

• 多路复用流：支持在单个连接中传输多个独立的流，每个流可以有不同的可靠性要求

• 无连接语义：基于HTTP/3的QUIC协议，支持0-RTT和连接迁移

• 灵活的可靠性选项：可以为不同的数据选择不同的可靠性级别

• 浏览器 API：提供简单的JavaScript API，便于开发者使用

WebTransport 的出现可能会对 WebSocket 形成挑战，但在短期内，WebSocket 仍将是主流的实时数据传输技术，WebTransport 将在特定场景（如游戏、实时媒体传输）中发挥优势。

10.3 边缘计算与实时传输

边缘计算的普及对实时数据传输提出了新的要求和机遇：

• 低延迟 需求：边缘节点更接近终端设备，需要毫秒级的响应速度

• 带宽优化：边缘节点可以缓存和处理数据，减少不必要的长距离数据传输

• 分布式架构：实时数据传输技术需要适应分布式边缘架构

• 浏览器 API：提供简单的JavaScript API，便于开发者使用

Streamable HTTP和MQTT在边缘计算场景中具有明显优势，前者适合Web应用与边缘节点的通信，后者适合IoT设备与边缘节点的通信。

10.4 AI 驱动的实时数据传输优化

人工智能技术正在改变实时数据传输的方式：

• 流量预测：基于机器学习预测设备流量，动态调整传输策略

• 智能路由：根据网络状态和设备性能，智能选择最佳传输路径

• 自动协议切换：根据网络环境自动切换传输协议（如WebSocket与SSE之间的切换）

• 数据压缩 优化：基于AI的压缩算法可以进一步提高数据传输效率

gRPC-Web和Streamable HTTP在AI驱动的实时数据传输中具有优势，前者提供了高效的远程过程调用机制，后者提供了灵活的流式传输能力。

十一 、结论与建议

11.1 结论

• 技术多样性：实时数据传输领域没有 "银弹"，多种技术并存，各有优势和适用场景

• 简单性的价值：在许多场景下，简单的技术（如SSE）可能比复杂技术（如WebSocket）更合适

• 混合使用趋势：复杂应用越来越倾向于混合使用多种技术，根据不同场景选择最合适的工具

• 未来发展方向：HTTP/3、WebTransport和边缘计算将推动实时数据传输技术进一步创新

• 性能与复杂度权衡：高性能通常伴随着高复杂度，需要根据项目需求进行权衡

11.2 技术选型建议

• 优先考虑 SSE 或 Streamable HTTP的场景：单向数据推送、简单实现、浏览器环境

• 优先考虑 WebSocket的场景：双向实时交互、高实时性要求、现代浏览器环境

• 优先考虑 MQTT的场景：IoT设备、低带宽或不稳定网络、需要发布 - 订阅模式

• 优先考虑 gRPC-Web的场景：内部微服务通信、高性能要求、强类型接口需求

• 优先考虑 轮询的场景：老旧系统兼容、低实时性要求、简单应用

2025年人工智能大模型领域，核心热点当属MCP（Model Context Protocol）。对AI大模型而言，调用外部工具是其从对话机器人向多功能助手AI Agent进化的关键；而MCP技术正凭借大模型Function Calling的基础能力，以及高效的开发规范，成为行业关注的焦点。

2025年5月9日，MCP（Model Context Protocol）迎来重磅升级------Streamable HTTP正式发布，取代了HTTP SSE, 成为AI模型通信的新标准！。其显著的性能优势迅速引发行业广泛热议，若想深入了解Streamable HTTP MCP 服务原理，敬请期待下篇《Streamable HTTP MCP服务技术详解》的分享。

本文作者：钟离离

原文发表：公众号"木昆子记录AI"