如何验证实时通知从服务端到客户端的端到端延迟

端到端延迟要先定义成一条时间线：事件生成、入队、发出、客户端收到、渲染完成五个点。只报“总耗时”无法判断慢在排队、传输还是渲染。代理IP 只影响传输段，所以必须先把排队和渲染从总时延里拆出来，否则会把服务端排队误判成代理慢。

用 t0 到 t4 标记实时通知的端到端耗时

t0： 表示事件生成，由服务端业务逻辑记录。

t1： 表示进入发送队列，由服务端记录。

t2： 表示写入连接，由服务端记录。

t3： 表示客户端收到，由客户端记录。

t4： 表示渲染完成，由客户端记录。
端到端是 t4−t0，入队前是 t1−t0（事件生成到入队），排队是 t2−t1，传输是 t3−t2，渲染是 t4−t3；各段之和应当等于总时延。缺中间打点时，端到端仍可报，但要把总时延标为“未分解”；只有 t0 或 t4 缺失，才不能谈端到端，只能谈某一段。

测量跨服务器延迟前先校准系统时钟

服务端和客户端的时钟不同步时，t3−t2 可能算出负数。先同步 NTP，或记录两台机的 offset 及测量不确定度；只有不确定度显著低于目标延迟时，才报跨机单向时延，否则用同机时钟或往返时延，并在结论里标注限制。

分别测量通知排队、网络传输和客户端渲染时间

排队突增看服务端队列长度和消费速度；传输突增看 RTT、代理链路和带宽；渲染突增看客户端主线程和长任务。三段一起涨，通常是服务端或网络整体变化；只有传输段涨，才优先怀疑出口。

排队段： 主要受队列、消费速度、突发流量影响，先检查队列长度与积压时间。

传输段： 即 t3−t2，更准确的说法是“写入连接至客户端收到回调的间隔”；受 RTT、代理、带宽、TLS 握手，以及客户端缓冲和事件循环调度影响，握手只在新建或重连时计入。

渲染段： 主要受主线程、长任务、批量更新影响，先检查客户端帧率与任务耗时。
设置代理对照组时，可先按代理设置帮助核对接入参数。

使用 p50、p95 和 p99 比较通知延迟

均值受长尾影响，但均值本身不能展示长尾分布。报告至少给出 p50、p95、p99，并写清样本量、采样窗口和分位数置信限制；样本有限时给原始分布与中位数，标注不稳定，不把 p99 当确定结论，也不设通用的条数门槛。分位数要注明针对哪类样本（全部通知、成功送达、还是超时也算），否则不同人报的 p95 不可比。

对照直连和代理链路并记录延迟结果

取直连基线时，保持同服务端、同时段、同事件流，只改出口。不能直连就注明“缺少对照”，不要默认代理无影响。

记录样本量和采样时间、t0 至 t4 的分段耗时、各分位数、是否有直连对照及时钟偏差。每条通知带唯一的 event/trace ID，能把服务端记录与客户端记录对上；t4 要写明是 DOM 更新完成、下一帧还是可观测呈现，三种口径的数值不同。记录字段里区分“应投递、已收到、超时、丢失”和观察截止时间。
验收看 p95 是否在预算内，且突增能落到具体分段。测试影响到生产订阅者或通知量超出预算时立即停止。

第一次配置代理对照实验时，可参考全球代理使用流程了解从获取代理到接入测试的步骤。

前端计时口径可参考：

• MDN Performance API

常见问题

端到端延迟和网络延迟有什么区别？

端到端包含服务端排队和客户端渲染，网络延迟只是传输一段。

为什么不能只看平均值？

均值会被长尾拉高或拉低，但不能说明分布形状；p95/p99 才能反映大多数用户的实际体验。