企业官网建设流程全解析

🎬 艾莉丝的简介：

1 ~> SSE（Server‑Sent‑Events）服务器发送事件协议

1.1 背景：HTTP 原生模型的局限

1.1.1 HTTP 基础模型特性

• HTTP 为严格 ** 请求‑响应（一问一答）** 模型：仅客户端发起请求，服务端才能返回响应；服务端无法主动向客户端推送数据。
• HTTP 具备无状态特性：两次独立请求响应之间不存在上下文关联。
• 适用场景：普通网页访问、表单提交等绝大多数业务。
• 不适用场景：需要服务端主动推送实时数据的业务
  • 体育赛事实时比分推送
  • 多人联机游戏状态同步
  • 导航实时信息下发
  • 大模型流式输出对话内容

1.1.2 原始折中方案：轮询（Polling）

• 实现逻辑：客户端周期性主动向服务端发起 HTTP 请求，拉取最新数据，并非服务端真正主动推送。
• 缺陷
  • 大量无效请求：多数请求到达服务端时并无新数据产生，浪费网络、服务端资源。
  • 实时性差：数据更新时刻与客户端拉取时刻存在时间窗口。例：轮询间隔 10s，数据第 11s 更新，客户端最早第 20s 才能拿到数据，最大延迟接近轮询周期。

1.1.3 SSE 发展历史

1. 2004 年 Ian Hickson 提出 SSE 概念，Opera 浏览器首个实现支持
2. 2011 年 Chrome、Firefox、Safari 主流浏览器陆续支持
3. 2015 年 SSE 正式成为 W3C 标准
4. 大模型行业爆发后，流式对话场景带动 SSE 大规模落地

2 ~> SSE 协议核心定义

SSE 全称 Server‑Sent Events，服务器发送事件，是构建在标准 HTTP 之上的 W3C 规范，实现服务端单向向客户端推送实时数据。

• 通信模型：建立单条持久长连接，客户端仅发起一次 HTTP 请求，后续由服务端持续向客户端推送数据分片；客户端不再发送请求。
• 重要特性：单向通信：仅服务端 → 客户端；客户端不能通过 SSE 通道回传数据，客户端如需向服务端发送新数据，必须新建独立 HTTP 请求。

适配大模型流式对话场景：用户发送一次提问请求，大模型分片返回输出内容，完美匹配 SSE 单向长连接模型。

2.1 SSE 核心特点

• 基于标准 HTTP 协议：无需新增协议、不需要额外端口配置，浏览器原生兼容，实现成本低。
• 单向通信：服务端推送至客户端，客户端无回传能力。
• 轻量级：代码实现简单，适合简单实时推送场景。
• 浏览器自动重连：网络断开后，浏览器原生自动尝试重建长连接，业务代码无需手写重连逻辑。
• 支持自定义事件类型：服务端指定event字段，客户端可按事件类型做不同业务处理。
• 支持消息 ID：每条消息携带唯一 id，断线重连后，客户端携带最后收到的消息 id，服务端可恢复断点消息流。
• 支持自定义重连间隔retry字段。

2.2 SSE HTTP 报文规范

1. 请求侧：客户端发起普通 HTTP 请求，通常携带业务标识，例如stream:true，告知服务端期望开启流式 SSE 返回。
2. 响应头（服务端必须设置）

Content-Type: text/event-stream Connection: keep‑alive Cache-Control: no-cache

• Content-Type: text/event‑stream：MIME 类型标记，标识这是 SSE 事件流；
• Connection: keep‑alive：维持长连接；
• Cache‑Control: no‑cache：禁止缓存事件流数据。

2.3 SSE 事件数据格式

每条事件流由多行字段组成，事件块以连续两个换行符\n\n作为结束分隔符。

示例原始 SSE 数据流：

data: 春眠 event: message id:123retry:10000data: 不 event: message id:123retry:10000data: 觉晓 event: message id:123retry:10000data:[DONE]

• data: [DONE]为业务层约定结束标记，代表本次完整数据流推送完毕；浏览器本身协议层面没有规定该标记，属于上层业务约定（各大模型 API 通用约定）。

注意：现实工程实现中，部分大模型 API 没有严格完全遵循 SSE 标准字段格式，会自定义 payload 结构（例如直接在 data 内部封装 JSON 字符串），属于业务层扩展。

3 ~> SSE 大模型流式交互实践

3.1 业务原理

• 全量返回：模型计算完成后一次性返回全部结果；适合生成图片、报表等场景，缺点是用户等待时间长。
• 流式响应（SSE）：客户端发起一次请求，大模型边计算边分片输出 token，服务端通过 SSE 长连接持续把分片推送给客户端；用户可以实时看到输出，降低等待感知。

3.2 API 工具（Apifox）观测现象

1. 请求参数设置stream:true，开启流式返回。
2. 响应流持续输出一块块 JSON 分片 chunk；每个分片携带增量输出内容。
3. 流末尾收到业务标记data: [DONE]，代表本轮对话流式输出结束。
4. 消息 ID：同一次会话流使用同一个消息 ID，用于断线恢复。

注意：标准 SSE 协议中data字段是纯文本；大模型工业 API 会把 JSON 字符串放在data:后面，属于业务封装。

4 ~> SSE 与 WebSocket 核心对比（面试高频）

• SSE
  • 传输层：基于原生 HTTP 协议
  • 通信方向：单向，仅服务端向客户端发送数据
  • 浏览器能力：原生自带自动断线重连
  • 部署：无需特殊代理，复用 HTTP 端口
  • 适用场景：大模型流式输出、消息通知、比分推送；服务端单向下发场景
  • 局限：客户端无法在已有连接上发送数据
• WebSocket
  • 传输层：HTTP 完成握手后升级为 ws/wss 自定义协议
  • 通信方向：全双工，客户端与服务端双向互相收发消息
  • 浏览器能力：无内置重连，业务代码手动实现重连逻辑
  • 部署：部分反向代理需要额外配置
  • 适用场景：聊天室、多人游戏、需要双向交互实时业务
  • 局限：实现复杂度更高

5 ~> 核心易错点总结

1. SSE 不是独立传输协议，是 HTTP 之上的应用层规范，不能脱离 HTTP 运行。
2. SSE 单向指通信通道单向，客户端要发新数据必须新建 HTTP 请求，不能复用 SSE 长连接发送上行数据。
3. [DONE]不是 SSE 协议标准，是大模型 API 行业业务约定，不同厂商实现可以变更。
4. 轮询是客户端不断拉取，SSE 是建立长连接服务端主动推送，二者底层模型本质不同。
5. SSE 消息 ID 作用：断线重连，客户端携带Last‑Event‑Id请求头，服务端据此补发丢失事件，实现断点续流。

结尾

uu们，本文的内容到这里就全部结束了，艾莉丝在这里再次感谢您的阅读！

艾莉丝努力练剑 C/C++ & Linux 底层探索者 | 一个正在努力练剑的技术博主 👀【关注】跟随我一起深耕技术领域，见证每一次成长。 ❤️【点赞】让优质内容被更多人看见，让知识传递更有力量。 ⭐【收藏】把核心知识点存好，在需要时随时查、随时用。 💬【评论】分享你的经验或疑问，评论区一起交流避坑！ 不要忘记给博主“一键四连”哦！ “今日练剑达成！” “技术之路难免有困惑，但同行的人会让前进更有方向。”

结语：希望对学习Linux相关内容的uu有所帮助，不要忘记给博主“一键四连”哦！

往期回顾：

【AI大模型接入SDK】DeepSeek API 基础概述

🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡૮₍ ˶ ˊ ᴥ ˋ˶₎ა