![[Full Clock 技术复盘] 一、浏览器前端如何实现百毫秒级时间校准？时间 API 推荐、模拟 NTP 算法原理及局限](images/news1.jpg)
道理很简单客户端发出一个请求100 ms后收到服务器答复服务器在00:00:30.000时收到请求在00:00:30.006时返回请求。客户端怎么知道自己要把时间设置到什么地方呢显然没有任何软件手段能获知请求的去程和响应的回程在路上传输的时间。所以我们必须引入一个核心假设去程和返程的延迟是相同的。这很合理因为一般而言往返走的线路不会有太大差异但是也引入了 NTP 的最大误差幸运的是通过多次请求和寻找最佳服务器线路精度可控制在亚毫秒级别。若你想了解生产生活中人们如何获取更高的精度的授时可以搜索PTPGNSS/GPS 授时技术。回到具体的例子我们可以发现“在路上”的请求时间是100-694 ms通过假设计算得单程延迟94/247 ms所以我们只需将本地时间设置为00:00:30.006 0.047 00:00:30.053即可。前端的思路就是模仿这种策略吸取其核心假设去程和返程的延迟是相同的。那么时间同步的服务去哪里找自己后端搭一个当然可以但是前提是保证服务器的时间准确。有没有现成的我询问了各大 AI给了我很多网站有的需要认证有的已经停止维护。我进行了逐家验证最后向大家我推荐两个截至发文无需认证免费使用、较为稳定的后端时间请求 APIhttps://api.shijian.online/timestamp/。它的返回格式如下{status:1,data:{timestamp:1780057227741}}https://timeapi.io/api/Time/current/zone?timeZoneUTC。它的返回格式如下{year:2026,month:5,day:30,hour:13,minute:17,seconds:51,milliSeconds:112,dateTime:2026-05-30T13:17:51.1120409,date:05/30/2026,time:13:17,timeZone:UTC,dayOfWeek:Saturday,dstActive:false}都至少精确到毫秒。所以我们比较服务器接受到请求的那一刻的本地和云端时间本地时间(start_time end_time) / 2估计最大误差为(end_time - start_time) / 2云端时间API 返回的时间。如能访问成功两个同步服务器我们选择逆方差加权如有想了解的读者可自行搜索。简单来说延迟越低可信度权重呈平方级增长。为防止超时我们将超时设为 1.5s因为长时间低精度的时间同步本就失去了意义。尤其注意时区处理和校准调时的前后方向重点测试不要闹笑话一下子差掉几个小时或者越调越偏。代码实现interface TimeSyncProvider {name: string;url: string;toTimestamp(json: any): number;}interface SyncResult {drift: number; // 定义偏移量 服务器时间 - 本地时间rtt: number; // 往返延迟 (Round-Trip Time)}/*** 获取单个源的时间偏移*/async function getOneDrift(provider: TimeSyncProvider): PromiseSyncResult | null {const start Date.now();try {const response await fetch(provider.url, {cache: no-store,signal: AbortSignal.timeout(1500) // 1.5s 超时断开});const json await response.json();const end Date.now();const serverTime provider.toTimestamp(json);const rtt end - start;// 核心逻辑假设服务器收到请求的时刻是 (start end) / 2// drift serverTime - (start end) / 2const drift serverTime - (start rtt / 2);return { drift, rtt };} catch (e) {console.warn(同步源 ${provider.name} 请求失败:, e);return null;}}/*** 逆方差加权融合多个源的结果*/async function getWeightedDrift(providers: TimeSyncProvider[]): Promisenumber | null {const results await Promise.all(providers.map(p getOneDrift(p)));const validResults results.filter((r): r is SyncResult r ! null);if (validResults.length 0) return null;// 逆方差加权逻辑权重 w 1 / (rtt^2)。延迟越低可信度呈平方级增长。let totalWeight 0;let weightedDrift 0;validResults.forEach(res {const weight 1 / Math.pow(Math.max(res.rtt, 1), 2);weightedDrift res.drift * weight;totalWeight weight;});return weightedDrift / totalWeight;}const providers: TimeSyncProvider[] [{name: shijian.online,url: https://api.shijian.online/timestamp/,toTimestamp: (json) json.data.timestamp},{name: timeapi.io,url: https://timeapi.io/api/Time/current/zone?timeZoneUTC,toTimestamp: (json) new Date(json.dateTime).getTime()}];getWeightedDrift(providers).then(finalDrift {console.log(最终计算得到的本地时间偏差: ${finalDrift.toFixed(2)}ms);// 展示时间 Date.now() finalDrift});误差来源分析读者有没有好奇为什么我们一直在说这种方式是“粗略”的难道说NTP 和我们 HTTP 走的不是同一条线路并非如此。网络路径的不对称性本身即是造成 NTP 的最大误差来源而在浏览器中我们看到的是加剧误差的机制TCP为了保证安全可靠的传输浏览器不支持裸 UDP而要再进行三次握手极大增加的请求处理的延迟。
[Full Clock 技术复盘] 一、浏览器前端如何实现百毫秒级时间校准？时间 API 推荐、模拟 NTP 算法原理及局限
道理很简单客户端发出一个请求100 ms后收到服务器答复服务器在00:00:30.000时收到请求在00:00:30.006时返回请求。客户端怎么知道自己要把时间设置到什么地方呢显然没有任何软件手段能获知请求的去程和响应的回程在路上传输的时间。所以我们必须引入一个核心假设去程和返程的延迟是相同的。这很合理因为一般而言往返走的线路不会有太大差异但是也引入了 NTP 的最大误差幸运的是通过多次请求和寻找最佳服务器线路精度可控制在亚毫秒级别。若你想了解生产生活中人们如何获取更高的精度的授时可以搜索PTPGNSS/GPS 授时技术。回到具体的例子我们可以发现“在路上”的请求时间是100-694 ms通过假设计算得单程延迟94/247 ms所以我们只需将本地时间设置为00:00:30.006 0.047 00:00:30.053即可。前端的思路就是模仿这种策略吸取其核心假设去程和返程的延迟是相同的。那么时间同步的服务去哪里找自己后端搭一个当然可以但是前提是保证服务器的时间准确。有没有现成的我询问了各大 AI给了我很多网站有的需要认证有的已经停止维护。我进行了逐家验证最后向大家我推荐两个截至发文无需认证免费使用、较为稳定的后端时间请求 APIhttps://api.shijian.online/timestamp/。它的返回格式如下{status:1,data:{timestamp:1780057227741}}https://timeapi.io/api/Time/current/zone?timeZoneUTC。它的返回格式如下{year:2026,month:5,day:30,hour:13,minute:17,seconds:51,milliSeconds:112,dateTime:2026-05-30T13:17:51.1120409,date:05/30/2026,time:13:17,timeZone:UTC,dayOfWeek:Saturday,dstActive:false}都至少精确到毫秒。所以我们比较服务器接受到请求的那一刻的本地和云端时间本地时间(start_time end_time) / 2估计最大误差为(end_time - start_time) / 2云端时间API 返回的时间。如能访问成功两个同步服务器我们选择逆方差加权如有想了解的读者可自行搜索。简单来说延迟越低可信度权重呈平方级增长。为防止超时我们将超时设为 1.5s因为长时间低精度的时间同步本就失去了意义。尤其注意时区处理和校准调时的前后方向重点测试不要闹笑话一下子差掉几个小时或者越调越偏。代码实现interface TimeSyncProvider {name: string;url: string;toTimestamp(json: any): number;}interface SyncResult {drift: number; // 定义偏移量 服务器时间 - 本地时间rtt: number; // 往返延迟 (Round-Trip Time)}/*** 获取单个源的时间偏移*/async function getOneDrift(provider: TimeSyncProvider): PromiseSyncResult | null {const start Date.now();try {const response await fetch(provider.url, {cache: no-store,signal: AbortSignal.timeout(1500) // 1.5s 超时断开});const json await response.json();const end Date.now();const serverTime provider.toTimestamp(json);const rtt end - start;// 核心逻辑假设服务器收到请求的时刻是 (start end) / 2// drift serverTime - (start end) / 2const drift serverTime - (start rtt / 2);return { drift, rtt };} catch (e) {console.warn(同步源 ${provider.name} 请求失败:, e);return null;}}/*** 逆方差加权融合多个源的结果*/async function getWeightedDrift(providers: TimeSyncProvider[]): Promisenumber | null {const results await Promise.all(providers.map(p getOneDrift(p)));const validResults results.filter((r): r is SyncResult r ! null);if (validResults.length 0) return null;// 逆方差加权逻辑权重 w 1 / (rtt^2)。延迟越低可信度呈平方级增长。let totalWeight 0;let weightedDrift 0;validResults.forEach(res {const weight 1 / Math.pow(Math.max(res.rtt, 1), 2);weightedDrift res.drift * weight;totalWeight weight;});return weightedDrift / totalWeight;}const providers: TimeSyncProvider[] [{name: shijian.online,url: https://api.shijian.online/timestamp/,toTimestamp: (json) json.data.timestamp},{name: timeapi.io,url: https://timeapi.io/api/Time/current/zone?timeZoneUTC,toTimestamp: (json) new Date(json.dateTime).getTime()}];getWeightedDrift(providers).then(finalDrift {console.log(最终计算得到的本地时间偏差: ${finalDrift.toFixed(2)}ms);// 展示时间 Date.now() finalDrift});误差来源分析读者有没有好奇为什么我们一直在说这种方式是“粗略”的难道说NTP 和我们 HTTP 走的不是同一条线路并非如此。网络路径的不对称性本身即是造成 NTP 的最大误差来源而在浏览器中我们看到的是加剧误差的机制TCP为了保证安全可靠的传输浏览器不支持裸 UDP而要再进行三次握手极大增加的请求处理的延迟。
