1 效果演示

在和机器人对话时,经常都是流式方式,这里使用hertz的SSE来实现一个流式接口。最终效果如下
b822a4b5-40ed-44cd-8490-9181c6fb6d0e

2 代码实现

1、依赖

2、 后端
3、 前端 chat.html

3 http sse可以用再构建app场景吗,还是只有在浏览器使用

HTTP SSE(Server-Sent Events,服务器发送事件)不仅限于浏览器,完全可以用于构建 App 场景,其核心是基于 HTTP 协议的单向实时通信能力,只要客户端能解析 HTTP 响应并处理文本流,即可使用。

3.1 浏览器场景:原生支持,开箱即用

浏览器是 SSE 的经典场景,因为浏览器提供了原生的EventSource API,无需额外依赖,可直接建立连接、监听服务器推送的事件:

3.2 App 场景:需手动实现客户端解析(无原生 API,但可实现)

App(如 iOS、Android 原生 App,或 Flutter、React Native 跨平台 App)没有内置的 “EventSource”,但只需遵循 SSE 的协议规范,手动处理 HTTP 响应流即可实现,核心是解析特定格式的文本响应

SSE 协议核心规范(客户端需适配):

  • 响应头必须包含:Content-Type: text/event-stream 和 Cache-Control: no-cache
  • 服务器推送的消息格式为 “键值对”,每行以\n分隔,空行表示消息结束,例如:
    plaintext

主流 App 平台的实现方式:

  • iOS:用URLSession发起 HTTP 请求,设置accept头为text/event-stream,通过dataTask监听响应流,逐行解析文本。
  • Android:用OkHttp(推荐)或Retrofit,开启response.body().source()获取字节流,按行读取并解析 SSE 格式。
  • 跨平台(Flutter/React Native):调用原生网络库(如 Flutter 的http包 + 流处理),或使用成熟的第三方库(如 Flutter 的sse包),简化解析逻辑。

4 SSE 和 http streamable 区别

http streamable 介绍

Streamable HTTP 是基于标准 HTTP 的通用流式传输模式,而 SSE(Server-Sent Events,服务器发送事件)是基于 HTTP 设计的、面向 “服务器到客户端单向实时消息” 的特定协议,二者是 “通用方案” 与 “专用方案” 的关系,核心差异体现在设计目标、数据格式和适用场景上。

对比维度 Streamable HTTP SSE (Server-Sent Events)
本质定位 通用流式传输模式(基于 HTTP 协议的 “能力扩展”) 专用实时消息协议(基于 HTTP 的 “标准化方案”)
设计目标 解决 “大文件 / 动态数据” 的分段传输(边传边用) 解决 “服务器到客户端” 的单向实时消息推送(低延迟)
数据格式 无固定格式(可传二进制 / 文本,如视频块、文件片段) 有严格的文本格式(需遵循 event/data/id 字段)
传输方向  双向 / 单向均可(如客户端传分片文件、服务器传流)  仅单向(服务器 → 客户端,客户端无法通过同连接回传)
 响应头标识 核心头:Transfer-Encoding: chunked  核心头:Content-Type: text/event-stream
客户端处理  需自定义实现(如断点续传需处理 Range 头)  浏览器原生支持(通过 EventSource API 自动解析)

http streamable实现方式

参考

分类&标签

Category : AI