SSE 断线重连：补回 50 条，仍漏 27 条

版权与内容来源声明本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容均在附表 A 中标注来源引用官方原文保持原样不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式也不对任何收益结果作承诺。转载请注明出处。先给结论补回 50 条和漏掉 27 条差的不是请求头是服务端那圈缓冲带上Last-Event-ID重连只解决「告诉服务端我从哪断的」这一件事补不补得全由另外两个变量决定事件 id 能不能被服务端按值定位服务端内存里还留着多少条。请求头只把 id 交出去一条补发都不承诺很多接入文档把重连写成两步客户端记下最后一条事件的 id重连时塞进请求头。写到这里就结束了。可真到线上客户端拿回来的可能是 20 条也可能是 200 条还可能一条都没落在正确的断点上。原因是Last-Event-ID是个请求头承载的是一个字符串。服务端拿到的是一串字节不是一个可二分查找的坐标。这串字节在服务端存储里没有索引时能做的只有两件事——从缓冲区最老的一条全推或干脆不推。浏览器这一侧反而好预测。它自己维护last event ID缓冲收到带id:字段的事件就覆盖重连时自动把缓冲内容写进请求头。这段逻辑在标准里写得很死不用你写一行代码。麻烦全在服务端那一侧而服务端的行为没有标准可依。三种 id 策略的失效形态不一样兜底逻辑不能共用线上见得最多的是三种 id自增序号、UUID、秒级时间戳。它们在「能不能补全」这个问题上的表现完全不同坏法也不一样。id 策略生成方式可比较可按值定位客户端能自检缺口典型失效自增序号每流一个计数器依次递增是是是窗口不够时退到缓冲头前段永久缺失UUID随机生成全局不重复否否否只能整段重推重复量大缺口看不出来秒级时间戳取到达时刻的整秒是是粒度一秒否同一秒内断线只能补到秒边界之前第三列和第四列是关键。「可比较」是说两个 id 能判先后「可按值定位」是说服务端能拿它直接算出数组下标或索引键。UUID 两样都不满足——它保证的是不重复不是有序。哈希表能回答「这条在不在」但答不了「从哪条开始」。秒级时间戳是容易被高估的选项。它能比较、能定位看上去两全可粒度只有一秒。到达率 40 条每秒时同一秒内断线客户端无法表达「我要第 123 条之后的」只能说「我要 3 秒之后的」。粒度差被放大成固定缺口跟窗口开多大无关。标题里的 50 和 27 分别来自哪一档50 是窗口只有 50 条时序号策略实际补回来的条数27 是补完之后仍然缺的条数。这次断线真正欠下的其实是 77 条40 条每秒乘 1.925 秒窗口 50 只够还上其中 50 条。同一份代码、同一次断线只把窗口从 50 抬到 200补回 77 条、缺口归零。所以标题里的两个数字是同一档读数补回来的和还欠着的加起来正好是 77。这也是本文最容易读错的一处——如果把 77 当成「补回的条数」、27 当成「还漏的」两个数加起来就对不上账了。所以这篇文章要回答的不是「要不要带Last-Event-ID」那个问题没有讨论价值。要回答的是带上之后还差多少差在哪一档以及什么条件下这条路径根本走不通。评测方法是协议语义模拟40 条每秒、600 条事件、一次 1.925 秒的断线本文所有读数来自一段 55 行的标准库脚本它模拟的是补发协议的语义——事件流、环形缓冲、重连补发——不是抓某家服务的真实数据包。这一点必须先讲明白否则读数会被误当成某个厂商的实际行为。模型里只有五个参数到达率 40 条每秒事件时刻按序号除以 40 折算保留三位小数事件总数 600 条覆盖 15 秒断线与重连都落在中段客户端在 t3.075 断线此刻最后一条完整收到的是第 122 条时刻 3.050客户端在 t5.000 重连断线时长 1.925 秒服务端每个流保留最近 N 条N 取 20、50、200 三档超出就从头淘汰。时间轴用浮点秒而非整数毫秒是让断点落在两条事件的空隙里而不是正好压在一条事件上——真实网络中断不挑时间落在空隙更接近实际。断线那一刻客户端手里只有一个 id断线时客户端并不知道自己缺了多少条它只知道自己最后收到第 122 条。这个信息就是重连时能交给服务端的全部。服务端收到重连请求后把缓冲区里的 id 取出来找第 123 条的位置。找到就从那里往后发找不到序号策略退化成从缓冲区最老的一条开始发。UUID 没有「找位置」这个动作只能整段重推。秒级时间戳按「大于最后一秒」筛筛出什么发什么筛掉的那部分不会报错。策略服务端如何定位从哪开始发客户端能否判断缺没缺自增序号在缓冲区 id 列表里找「最后一条加一」找到就精确起点找不到退到缓冲头能看首条 id 是否为 123UUID无定位动作缓冲区全部不能收到的 id 与已有 id 无从比较秒级时间戳找第一个大于「最后一秒」的秒边界之后的第一条不能只知道秒不知道条把脚本原样跑一遍环境就是系统自带的 Python没有第三方依赖复制出去就能跑。 实测环境Python 3.13.12 / macOS (darwin) / 仅标准库# -*- coding: utf-8 -*-复现 SSE 断线重连的补发语义三种事件 id 策略 × 三种服务端保留窗口。 注意这是对补发协议的语义模拟事件流 环形缓冲 重连补发不是抓某家服务的真包。RATE40# 每秒事件数TOTAL600# 事件总数DROP_AT3.075# 客户端断线时刻BACK_AT5.000# 客户端重连时刻events[{i:i,t:round(i/RATE,3)}foriinrange(TOTAL)]last_seenmax((eforeineventsife[t]DROP_AT),keylambdae:e[t])# 最后收到的那条print(客户端在 t%.3f 断线最后收到第 %d 条t%.3f%(DROP_AT,last_seen[i],last_seen[t]))print(t%.3f 重连断线期间新增 %d 条\n%(BACK_AT,len([eforeineventsifDROP_ATe[t]BACK_AT])))defresume(window,strategy):window 服务端每个流保留的最近事件条数返回 (补发条数, 重复条数, 缺失条数, 能否自检)published[eforeineventsife[t]BACK_AT]bufpublished[-window:]# 环形缓冲里还剩什么nxtlast_seen[i]1# 客户端真正需要的第一条ifstrategyseq:# 服务端按 id 二分查找找不到就只能从缓冲区最老的一条开始ids[e[i]foreinbuf]startids.index(nxt)ifnxtinidselse0sentbuf[start:]selfcheckTrueelifstrategyuuid:# uuid 不可比较、不可索引服务端只能从缓冲区头部或从当前位置重发sentbuf selfcheckFalseelse:# 秒级时间戳ids[int(e[t])foreinbuf]startnext((kfork,vinenumerate(ids)ifvint(last_seen[t])),len(buf))sentbuf[start:]selfcheckFalsegot{e[i]foreinsent}duplen([iforiingotifilast_seen[i]])missinglen([eforeinpublishedife[i]nxtande[i]notingot])returnlen(sent),dup,missing,selfcheckprint(%-8s %-6s %-6s %-6s %-6s%(id 策略,窗口,补发,重复,缺失))forwin(20,50,200):forsin(seq,uuid,ts):sent,dup,miss,chkresume(w,s)print(%-10s %-7d %-7d %-7d %-7d 自检缺口%s%(s,w,sent,dup,miss,能ifchkelse不能))print(\n窗口 断线期间新增条数时刚好补齐断线时长 1/2/5/10 秒窗口 200 条)foroutagein(1,2,5,10):gapRATE*outageprint( 断线 %2d 秒 → 新增 %3d 条 → 窗口 200 %s窗口 50 %s%(outage,gap,够if200gapelse不够,够if50gapelse不够))客户端在 t3.075 断线最后收到第 122 条t3.050 t5.000 重连断线期间新增 77 条 id 策略 窗口 补发 重复 缺失 seq 20 20 0 57 自检缺口能 uuid 20 20 0 57 自检缺口不能 ts 20 20 0 57 自检缺口不能 seq 50 50 0 27 自检缺口能 uuid 50 50 0 27 自检缺口不能 ts 50 40 0 37 自检缺口不能 seq 200 77 0 0 自检缺口能 uuid 200 200 123 0 自检缺口不能 ts 200 40 0 37 自检缺口不能 窗口 断线期间新增条数时刚好补齐断线时长 1/2/5/10 秒窗口 200 条 断线 1 秒 → 新增 40 条 → 窗口 200 够窗口 50 够 断线 2 秒 → 新增 80 条 → 窗口 200 够窗口 50 不够 断线 5 秒 → 新增 200 条 → 窗口 200 够窗口 50 不够 断线 10 秒 → 新增 400 条 → 窗口 200 不够窗口 50 不够第三列那张表里有一列「自检缺口」值得单独看只有序号策略能在客户端侧判断出缺口。另外两种即使漏了 57 条客户端也无从知道自己漏了——它只是安静地少了一段后面的业务逻辑拿到的是残缺序列。窗口 50 漏 27 条窗口 200 序号补齐、UUID 重复 123 条窗口从 50 抬到 200序号策略从漏 27 条变成漏 0同一档里 UUID 把 200 条全推了一遍其中 123 条是客户端已经收过的秒级时间戳在 20、50、200 三档里都只补 40 条一档都没变。窗口 20 和 50三种策略全漏两种漏得一模一样窗口 20 时三种策略的读数是同一组数字补发 20 条、重复 0、缺失 57。这不是巧合——20 条缓冲只覆盖 0.5 秒77 条缺口里必然有 57 条落在窗口之外。序号策略找不到第 123 条退化成从缓冲头开始发把 20 条全发了剩下的 57 条永远拿不到。窗口 50 时序号策略补发 50 条、漏 27 条UUID 同样是 50 条、漏 27 条。两条读数一样原因却不同序号策略是缓冲不够UUID 是压根没有定位能力。把窗口继续开大前者会好转后者不会。秒级时间戳在这里第一次掉队窗口 50 本该发 50 条它只发了 40 条。因为它只能从「3 秒之后」开始3.000 到 3.050 之间那几条被整段跳过。窗口 200补齐、重发、只补到秒边界三种结果同时出现窗口 200 覆盖 5 秒比 1.925 秒的断线长出不少序号策略终于能精确找到第 123 条补发 77 条、重复 0、缺失 0。这是唯一一档干净的读数。UUID 在窗口 200 时补发 200 条、重复 123 条、缺失 0。数据是齐了但客户端要自己去重 123 条。如果客户端把事件当追加写入这 123 条要么变成重复记录要么靠业务侧幂等兜住。这类重复往往不会立刻暴露等到做统计或者回放的时候才浮出来。秒级时间戳在窗口 200 时还是 40 条、漏 37 条。窗口再大也没用卡点不在缓冲在 id 的粒度。把窗口开到 2000 条也一样因为它筛的条件是「秒」不是「条」。断线时长一旦超过窗口任何策略都救不回来脚本最后一段把断线时长拉到 1、2、5、10 秒看窗口的临界点。40 条每秒的到达率下1 秒欠 40 条、2 秒欠 80 条、5 秒欠 200 条、10 秒欠 400 条。窗口 200 在第 5 秒刚好打平到第 10 秒就不够了。这一段的价值在于窗口不是拍一个「差不多大」的数字它和断线时长是乘法关系。到达率越高、允许的断线越久窗口就得越长而且线性变长。 实测环境Python 3.13.12 / macOS (darwin) / 仅标准库RATE,OUTAGE40,1.9needRATE*OUTAGEforwin(20,50,200):print(窗口 %3d 条 → %s断线 1.9 秒需要 %.0f 条%(w,够ifwneedelse不够,need))窗口 20 条 → 不够断线 1.9 秒需要 76 条 窗口 50 条 → 不够断线 1.9 秒需要 76 条 窗口 200 条 → 够断线 1.9 秒需要 76 条注意这段算出来是 76 条前面脚本里是 77 条——差别来自断线时长取 1.9 还是 1.925 秒。做容量规划时用整数秒估上限就够落到具体实现还是要按真实到达率乘真实断线时长来算。SSE 补发对照脚本与读数表上面三张读数表对应的脚本、原始输出和一张窗口速查表都在资料包里改两个参数就能套到你自己的到达率上。放在资料包里扫码即可获取规范只写到请求头Last-Event-ID 发出去之后标准没有下文WHATWG 的 HTML 标准把last event ID的写入、清理、重连时放进请求头这几步写得很细但在「服务端收到这个头之后补多少条」这一步就停了。规范定义的是客户端行为不是服务端契约。规范把 id 的读写和重连写死了四处原文分别是9.2.6 解析id字段If the field value does not contain U0000 NULL, then set thelast event IDbuffer to the field value. Otherwise, ignore the field.9.2.6 事件派发之后Set the last event ID string of the event source to the value of thelast event IDbuffer.9.2.3 重连Wait a delay equal to the reconnection time of the event source. 随后 Set (Last-Event-ID, lastEventIDValue) in request’s header list.看第三条的顺序先等一个重连延迟再把 id 写进请求头。这两步都在客户端服务端一行都没出现。规范没写的三件事正好是差距的来源规范写了规范没写id字段如何写入last event ID缓冲服务端按 id 补发时从哪一条开始重连时把 id 放进Last-Event-ID请求头服务端缓冲保留多少条、按什么规则淘汰重连延迟的默认值由实现决定缓冲被淘汰后客户端如何得知并补救第二行是这次实测差距的全部来源。规范没有规定服务端要保留多长的历史也没有规定缓冲满了该丢头还是丢尾实现上几乎都丢头。这意味着同一段客户端代码换一个服务端实现补发结果可以完全不同。重连延迟本身也是实现自定义原文是A reconnection time, in milliseconds. This must initially be an implementation-defined value, probably in the region of a few seconds.「probably in the region of a few seconds」这句直接决定断线时长。客户端若不主动控制重连节奏断线时长就是实现给的那个默认值而窗口大小又必须按断线时长来算。两头都不在你的代码里却共同决定补发能不能成立。浏览器端可以在流里发retry:字段覆盖这个延迟原生客户端则要自己实现退避。这段代码通常只有几行但它是唯一能把断线时长按住的抓手。⚠️代码待验证curl-N-HAccept: text/event-stream\-HLast-Event-ID: 122\https://example.com/stream落地判据id 要可索引窗口按到达率乘断线时长算客户端要能自检落到线上只需要盯四个量id 的可比较性、窗口条数、客户端缺口自检、断线时长上限。前两个决定补得全不全后两个决定补不全的时候你知不知道。判据一id 必须可比较、可索引、能判先后UUID 在这条上直接出局。它保证唯一不保证顺序服务端拿它没法定位起点只能整段重推——实测里 200 条补发、123 条重复就是这么来的。能用的形态有两种每流单调递增的整数或者「流标识加递增序号」的复合键。复合键的好处是同一个 id 在多流场景下也不冲突代价是服务端要按流分桶存缓冲。秒级时间戳只在「一条事件就是一秒的全部内容」时够用到达率高于每秒一条的场景它一定会在同一秒内断线时掉链子实测里那 37 条缺口就是这么固定下来的。判据二窗口条数不少于到达率乘断线时长再留余量公式很短所需窗口 ≥ 到达率 × 断线时长。40 条每秒、断线 1.925 秒需要 77 条窗口 50 差 27 条窗口 200 有余量。断线时长40 条每秒欠下的条数窗口 50窗口 2001 秒40够够2 秒80不够够5 秒200不够刚好够10 秒400不够不够「刚好够」是最危险的一格。窗口 200、断线 5 秒两个数相等只要到达率有一点抖动或者重连晚了几十毫秒缺口就出现了。实际取值按峰值到达率算再留出一段余量别按平均值算。判据三客户端要能自检缺口断线超限就全量重拉能自检的前提是 id 连续。客户端收到第一条补发事件时看它的 id 是不是「最后一条加一」是说明接上了不是说明中间有缺口直接走全量重拉不要指望后续事件把缺口填回来。UUID 和时间戳都没有这个能力客户端只能选择相信服务端。断线时长还要单独设上限。超过上限的客户端不再走增量补发直接请求一次全量快照然后用快照里的版本号重新起一条流。这个上限跟窗口是同一个数算出来的窗口 200、40 条每秒上限就是 5 秒再留余量取 4 秒。具体怎么选按这四条走到达率稳定、事件由自己生成用每流自增序号窗口取峰值到达率乘允许断线时长再乘 1.5事件由多个生产者写入、担心 id 冲突用「流标识加序号」复合键服务端按流分桶窗口按单流到达率算已经在用 UUID 且改不动把窗口开到最大也没用必须补一条按写入顺序的辅助序号否则客户端永远判不出缺口允许断线超过窗口覆盖范围改成全量重拉增量补发在这条路径上不再成立继续调窗口只是把失败推迟。SSE 断线重连配置清单上面四条判据整理成了一页检查表含窗口计算公式、id 形态对照和全量重拉的触发条件。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处一手来源本文位置id字段写入last event ID缓冲的规则https://html.spec.whatwg.org/multipage/server-sent-events.html 9.2.6第 4 章事件派发后把缓冲内容写回last event ID字符串同上 9.2.6第 4 章重连时把 lastEventIDValue 写入Last-Event-ID请求头同上 9.2.3第 4 章重连延迟初始值由实现决定同上 9.2.2第 4 章三种 id 策略乘三档窗口的补发、重复、缺失读数本文实测work/exp1102/sse_resume.py取数日期 2026-11-02第 2、3 章断线 1、2、5、10 秒与窗口 50、200 的临界关系本文实测work/exp1102/sse_resume.py取数日期 2026-11-02第 3、5 章写在最后这篇用到的资料写这篇文章时我把补发逻辑抽成一段 55 行的标准库脚本反复调窗口和 id 策略对着读数看才把「补回 77 条、仍漏 27 条」这个差距拆开顺手也整理了几份配套的东西大模型学习路线图从零基础到能自己动手做 Agent按阶段说明每一步该学什么、哪些可以先跳过《LangChain LangGraph MCP 智能体开发实战》视频课7 个模块从私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知识库在线可查Agent Skills 从入门到落地、Claude Skills 完全指南等专题按目录浏览即可640 套 AI 大模型行业报告 经典 PDF 书籍看行业落地案例和别人怎么做的时候用得上大模型零基础到精通教学视频跟着敲一遍比只读文档快得多资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「AI」优先通过。资料按「先路线、再动手、最后查漏」的顺序整理好了建议先看学习路线那一份照着它挑一条适合自己当前基础的路径再往下看。