1. 背景
在许多应用中，不可避免地遇到多个系统之间的时钟同步，在RTC中也不例外。很多地方不是简单地使用NTP时间，而是会用到这个思想来解决很多问题。举几个常见的使用例子：
- 两个客户端之间的端到端延迟计算：因为大多数音视频系统都需要经过SFU，不是简单地端到端，如果能够对齐两端NTP，那么计算端到端延迟就会变得非常简单。
- 使用时钟同步思想计算端到端延迟（仅P2P）：WebRTC标准里面借用了NTP时钟同步的思想，通过XR来计算端到端延迟。
- 统一整个RTC系统时钟方便分析问题：在分析音视频端到端问题时，很容易遇到的一个问题就是两个客户端以及server之间的时钟不同步，在需要精确到毫秒的场景时会比较麻烦。对于端到端问题自动分析工具来说，时钟不同步也是一个问题。
- KTV合唱场景需要全局时间同步：如今KTV合唱也是一个非常常见的场景，多个客户端如何一起唱也是需要全局时间同步来保障的。在很多需要多端同步的场景都可以使用时钟同步解决问题。
当然，在RTC系统中，应用的地方远不止这么多，个人认为随着RTC系统演进，全局NTP时钟同步是非常必要的。
这篇文章，我们将介绍下NTP时钟同步的原理，以及在WebRTC里面，如何利用时钟同步的原理计算端到端延迟，希望这篇文章能够对大家有所启发。
2. 什么是NTP
NTP，Network Time Protocol。它是一个时钟同步协议，可以用于多个计算机之间的高精度的时钟校正（几毫秒级别）。
我们每天电脑上就自带了时钟同步的客户端，比如windows、mac系统的时间会周期性地和NTP服务器同步。那是不是同步一次就一劳永逸了？肯定不行。我们的PC系统时钟也是基于晶振，虽然说已经较为准确了，但是随着时间推移也会存在一点偏差，时间越长偏差越大。因此，我们才需要定期地和更准确的时钟源同步。这些NTP服务器提供的时钟是UTC时间，准确度也更高，我们任何时候都可以“无条件”相信这个标准时间（实际上NTP服务器也可能不准，后面会介绍如何解决）。
3. NTP时钟同步原理
3.1 基本原理
在同一时刻，有两个端分别是需要同步的端和NTP服务器，他们有各自的NTP时间，但是客户端不是准的，只有NTP服务器的才是准确的，而我们的目标就是得到这两个端的NTP offset，并使用offset校准客户端时间。这两个NTP时间都是随着时间流逝而增加，客户端的精度不是很高，但是能够在一段时间内保持不漂移；服务器的NTP时间增加我们认为是非常准确的。我们只要知道了两个端的NTP时间之差，就可以把客户端时间修正了。即
ntp_offset=NTPb−NTPa
但是，我们不是上帝，是没法“同时”得到两个NTP时间的。不能同时，那么我们一个通过一个请求、响应，并用RTT补偿。这里我们假设正向和反向的网络是对称的，不然会出现问题。后面我们会描述这个问题。
NTP请求响应
即客户端A先发送一条请求到B，B再回响应。那么这个消息里面应该带上什么呢？我们下面分析：
NTP时间同步
t1+ntp_offset+rtt/2=t2,t3+rtt/2=t4+ntp_offset
于是有
ntp_offset=(t2−t1+t3−t4)/2+rtt/2
而rtt：
rtt=(t4−t1)−(t3−t2)
因此offset的估计只需要返回这些时间就可以了。即在A端请求的时候记录请求时间t1（A的NTP时间），B端记录接收到的请求时间t2、响应时间t3（B自己的NTP时间），A收到响应后记录收到响应时间t4。因此B的响应只需要带上两个时间即可。标准里面报文如何实现，这里我们不关注，有兴趣可以看RFC 5905.
3.2 NTP时钟同步的实现
偏听则暗，兼听则明。如果我们只和一台NTP server同步，不一定可靠。客户端和不同NTP服务之间的网络不同，有些RTT小有些RTT大，我们更愿意相RTT小的。不同的NTP server本身也有可靠性问题，如果有NTP server本身存在故障，自己的时钟出现问题，那么会把其他客户端带偏。因此和多个NTP server同步，然后从中选择最靠谱的结果（靠谱的结果可以参考标准里面的介绍），然后综合这些结果，并对多次结果做环路滤波，这样我们的客户端便能得到比较靠谱的时间了。
RFC5905中对于NTP同步的实现如下所示，流程基本上和我们上面描述的一致：
NTP实现
3.3 关于非对称网络、延时问题
上面我们有提到，一般我们都是假设网络上下行对称，即上下行的单向延迟分别是rtt/2。实际上可能会有偏差。但是我们的同步方法有一定的鲁棒性，通过一来一回的方式，两个方向的平均可以降低单向的影响。
实际上我们的估计准确性取决于网络好坏，RTT越低，估计值和实际值约接近。因此我们在多次检测的时候可以更相信RTT较小的值。
4. WebRTC的端到端延迟计算
在WebRTC官方有一个open issue在讨论如何计算end to end delay。基于这个讨论以及WebRTC当前的代码实现，我们来讨论下WebRTC里面如何计算端到端延迟。
端到端延迟（End-to-end Delay）是指音视频采样数据从一个端上采集到另外一个端播放所需的全部时间，这个延迟包含了单向传输延迟以及发送和接收端buffer、处理时间。
假设我们所有的设备系统时间都和NTP server精准同步了，那么计算端到端延迟就非常简单，直接拿接收端的系统NTP时间减去采集NTP时间即可。理想很丰满，现实却很残酷。虽然说我们的PC和手机都会和NTP server周期性同步，但是系统本身时钟存在偏移，在部分时间内可能会存在几百ms误差，这个误差对于实时应用的端到端延迟统计肯定不行。更何况还有部分设备关闭了时钟同步，这些设备的时钟误差不知道偏差到哪了。
因此，我们无法基于系统NTP时钟去计算端到端延迟，但是我们却可以在WebRTC里面借用这个思想，即通过RTC系统对两端时钟进行同步，这里的同步只是应用内的同步，并不会影响系统的时钟。一般可以使用两种方法：
- 使用NTP相关的库，所有客户端和相同的一系列NTP server进行同步，所有设备实现全局NTP时钟对齐。这个方案优点多多，但是商业使用时需要考虑第三方NTP server是否可靠问题。
- 借用WebRTC已有的通道，实现端到端的NTP时钟对齐。这个方案轻量级，WebRTC原生通道支持。
使用NTP库的方式，我们这里不讨论，大家可以自己研究。使用WebRTC已有通道计算的流程大概如下（大家也可以看下open issue这里的讨论）。
e2e delay计算
整个过程分4步：
【第一步】RTP timestamp到采集端NTP的转换：基于原有的SR（SR的每个包携带RTP timestamp和对应的NTP，可以在接收端收到足够的包后拟合关系），能够在接收端将RTP timestamp还原成发送端的NTP时间。使用最小二乘法将rtp timestamp转为NTP的过程见代码RtpToNtpEstimator@rtp_to_ntp_estimator.cc。
拟合rtp timestamp和ntp关系
【第二步】两端RTT的估计：估计RTT是为了估计得到两端NTP offset。这个估计可以基于RTCP，如SR/RR、RRTR/DLRR（具体见RTC 3550和RFC 3611）。【第三步】NTP offset估计：NTP标准里面是一来一回地估计两端ntp offset，但是WebRTC从RTP通道估计，只能使用单向的一次估计。但是我们可以像WebRTC一样滤波。这部分代码见RemoteNtpTimeEstimator@remote_ntp_time_estimator.cc。WebRTC里面采用的是平滑中值滤波MovingMedianFilter来对ntp offset进行滤波，得到一个较为准确的NTP offset估计。
NTP估计
【第四步】计算e2d delay: 基于接收端的ntp时间，用帧的渲染时间 - 帧的采集时间。采集时间是经过上面的两步转换，即RtpToNtpEstimator和RemoteNtpTimeEstimator，将采集时间映射到接收端的时间。
【存在relay如何计算端到端延迟？】以上就是WebRTC如何计算端到端的延迟。当然，WebRTC里面的计算是纯粹的peer to peer的，没有任何relay。如果存在relay，计算就变得复杂了，当软也不是不可能，只要你能深入理解NTP时钟同步的原理就可以。关于存在relay时怎么计算，大家可以关注官方讨论open issue。当然，如果你实现了全局时钟同步，那么这个问题也不是问题了。
【上下行延迟不对称如何解决？】在做同步的时候，当然是rtt越小受网络影响最小，如果上下行的延迟差很多，和NTP标准一样，也会导致计算ntp offset不准确。对于NTP标准来说，可以从多个NTP server的结果中选择，WebRTC实现中客户端的选择只有一个。如果存在弱网，这个问题很难避免，但是可以在算法滤波上做文章，尽量提高准确性。
5. 总结
以上便是NTP时钟同步的原理，以及WebRTC中如何根据这个原理计算端到端延迟。大家如果有疑问，评论区见。
本文使用 Zhihu On VSCode 创作并发布
★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。
见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓