个人主页艾莉丝努力练剑❄专栏传送门《C语言》《数据结构与算法》《C/C干货分享学习过程记录》《Linux操作系统编程详解》《笔试/面试常见算法从基础到进阶》《Python干货分享》⭐️为天地立心为生民立命为往圣继绝学为万世开太平 艾莉丝的简介文章目录1 ~ 协议背景为什么需要 WebSocket1.1 HTTP 固有模型限制1.2 WebSocket 的设计目标2 ~ WebSocket 协议核心原理2.1 握手流程协议升级2.2 通信特性3 ~ SSE 协议核心原理3.1 通信模型3.2 内置能力3.3 典型适用场景4 ~ SSE 与 WebSocket 关键对比5 ~ 面试重点大模型流式对话为什么优先选用 SSE而不是 WebSocket5.1 业务模式匹配5.2 工程架构层面优势5.3 补充边界6 ~ 典型业务选型总结6.1 补充案例在线五子棋结尾1 ~ 协议背景为什么需要 WebSocket1.1 HTTP 固有模型限制HTTP 是一问一答的请求‑响应模型默认短连接服务端无法在客户端没有发起请求的情况下主动推送数据。现有方案局限轮询客户端周期性发起 HTTP 请求查询服务端是否有新数据缺陷大量无效请求存在时间差数据无法做到实时HTTP1.0 每次轮询都要重建 TCP 握手。HTTP 长连接 轮询复用 TCP 连接依旧无法解决无效请求、实时性差的根本问题。SSEServer‑Sent‑Events基于 HTTP 长连接单向通信仅服务端向客户端推送。适用场景新闻推送、股票行情、大模型流式输出。局限不支持客户端向服务端实时回传消息无法实现双向交互群聊、多人在线游戏、在线五子棋这类双向实时场景无法直接使用 SSE 实现。1.2 WebSocket 的设计目标建立全双工长连接连接建立完成后客户端与服务端双方都可以随时向对方发送数据。典型业务场景在线五子棋、群聊、多人网络游戏、实时协作编辑。2 ~ WebSocket 协议核心原理2.1 握手流程协议升级客户端发起普通 HTTP GET 请求携带协议升级相关请求头请求将连接升级为 WebSocket 协议。服务端校验请求返回 101 Switching Protocols 响应。HTTP 握手完成底层 TCP 连接保留后续通信不再使用 HTTP切换为 WebSocket 帧格式通信。协议标识ws://WebSocket 明文协议wss://WebSocket over TLS加密传输对应 HTTP/HTTPS 关系。2.2 通信特性全双工客户端、服务端可独立随时发送消息不受请求‑响应次序约束。支持文本帧、二进制帧两种数据载荷。属于应用层协议构建在 TCP 之上。连接一旦建立持续保持直到任意一方主动关闭、网络异常断开。3 ~ SSE 协议核心原理3.1 通信模型SSE 并非独立网络协议是 HTTP 之上的扩展能力基于Transfer‑Encoding: chunked分块传输实现。通信模式一问多答。客户端发起一次 HTTP 请求服务端持续分块推送事件数据推送完毕返回[DONE]标记连接关闭。通信方向半双工仅服务端 → 客户端单向推送客户端无法在该长连接内回传数据如果需要发数据需要发起全新 HTTP 请求。3.2 内置能力自动断线重连浏览器原生支持断开后自动重连。Last‑Event‑ID客户端重连时携带上次接收事件 ID服务端可补发丢失消息实现消息断点续传。3.3 典型适用场景大模型 LLM 流式输出、实时日志推送、消息通知、比分行情。4 ~ SSE 与 WebSocket 关键对比特性SSEWebSocket通信方向半双工仅服务端推送给客户端全双工客户端↔服务端双向自由收发底层依赖HTTP/1.1、HTTP/2基于 chunked 分块传输TCP通过 HTTP 握手完成协议升级数据格式仅文本文本、二进制均支持断线重连浏览器原生内置自动重连、Last‑Event‑ID无原生支持需要业务层手动实现心跳、重连、消息去重网络穿透兼容 CDN、Nginx、负载均衡、老旧防火墙运维成本低ws/wss 协议部分老旧防火墙、代理会拦截协议升级报文服务端资源开销单向输出流高并发场景内存 CPU 开销更低全双工需要维护状态机、双向缓冲区资源开销更高业务适配场景单向流式输出大模型对话、通知、日志流双向强交互在线游戏、群聊、实时协同编辑5 ~ 面试重点大模型流式对话为什么优先选用 SSE而不是 WebSocket5.1 业务模式匹配LLM 聊天交互模式客户端发起请求 → 服务端流式返回结果一轮对话结束连接结束。属于请求‑流式响应不需要在生成过程中客户端往长连接内持续发送消息。SSE 天然适配。WebSocket 为全双工长连接如果用于该场景长连接会大量占用服务端资源大量用户空闲时依然维持连接服务端连接数压力巨大。5.2 工程架构层面优势网络基础设施兼容性SSE 走标准 HTTP各类代理、CDN、负载均衡兼容度远高于 WebSocket。断线恢复能力SSE 浏览器自带重连与事件 ID 断点续传WebSocket 全部逻辑需要开发者手写。模型推理状态管理大模型推理依赖 KV‑Cache 显存上下文。SSE一次请求对应一次推理任务请求结束释放资源生命周期清晰不会出现生成中途客户端乱发消息带来的竞态问题。WebSocket 长连接允许客户端随时下发新消息需要额外处理生成中收到新指令是丢弃、排队还是打断业务逻辑复杂度显著上升。如何实现停止生成Stop Generation面试官高频追问不需要 WebSocket。客户端发送独立 POST 请求携带任务 ID服务端找到对应流式任务终止输出流即可。遵循关注点分离。5.3 补充边界WebSocket 本身完全可以实现大模型流式输出不是技术不可行只是 SSE 以更低编码、运维、资源成本满足业务需求。SSE 在大模型行业爆发之后大规模普及找到了自身核心落地场景。6 ~ 典型业务选型总结选用SSE业务只需要服务端向客户端推送客户端不需要在长连接通道内回传消息例如 AI 流式输出、监控日志、消息通知。选用WebSocket业务需要双方频繁实时交互例如在线对战游戏、聊天室、实时文档协同。6.1 补充案例在线五子棋SSE 无法实现玩家 A 落子服务端主动推送给玩家 B。SSE 要求客户端必须发起请求才能收到数据。普通轮询B 不停询问 “A 是否落子”实时差大、无效请求多。WebSocket 最优A、B 分别建立 ws 长连接A 落子发送给服务端服务端立刻转发给 B双向实时同步棋局状态。结尾uu们本文的内容到这里就全部结束了艾莉丝在这里再次感谢您的阅读艾莉丝努力练剑C/C Linux 底层探索者 | 一个正在努力练剑的技术博主【关注】跟随我一起深耕技术领域见证每一次成长。❤️【点赞】让优质内容被更多人看见让知识传递更有力量。⭐【收藏】把核心知识点存好在需要时随时查、随时用。【评论】分享你的经验或疑问评论区一起交流避坑不要忘记给博主“一键四连”哦“今日练剑达成”“技术之路难免有困惑但同行的人会让前进更有方向。”结语希望对学习Linux相关内容的uu有所帮助不要忘记给博主“一键四连”哦往期回顾【AI大模型接入SDK】SSE协议博主在这里放了一只小狗大家看完了摸摸小狗放松一下吧૮₍ ˶ ˊ ᴥ ˋ˶₎ა
