如何在C语言中实现RFC 3393（Ipdv数据包延迟变化）？

Question

我正在构建一个以太网应用程序，在其中我将从一侧发送数据包并在另一侧接收。我想要在接收器端计算数据包的延迟，就像RFC 3393中所述。因此，我必须在发送方的数据包中放置时间戳，然后在接收方尽快接收数据包时获取时间戳。通过减去这些值，我将得到时间戳之间的差异，然后通过减去此值与后续差异的值，我将获得单向IPDV延迟。两个时钟不同步。因此，任何帮助都将不胜感激。 谢谢。

- sagar

---

两台机器上的时钟同步是你的问题，我认为是这样的吧？ - Pratik Deoghare

阅读RFC 2679，该文解释了为什么对于类似RFC 3393的单向测量，时钟的紧密同步是强制性的。 - bortzmeyer

bortzmeyer，或者阅读我的答案，其中详细解释了为什么它不是。RFC 2679被3393引用。它们测量不同的事物。2679测量延迟本身。3393测量延迟的方差。3393不需要同步时钟。 - Jon Bright

Answer 1

RFC 3393是用于测量数据包延迟的方差，而不是测量延迟本身。例如：您正在编写视频流应用程序，希望尽可能少地缓冲视频数据（以便视频尽快开始播放）。假设数据从A机器到B机器始终需要20ms，那么在这种情况下（并且假设A机器可以按照需要播放的速度发送视频数据），您根本不需要任何缓冲区。一旦接收到第一帧，您就可以开始播放，并确信在需要下一帧时，它将到达（因为数据始终需要20ms到达，且A机器发送的速度至少与您播放的速度相同）。无论这个20ms有多长，只要始终相同即可。它可能是1000ms-第一帧需要1000ms才能到达，但您仍然可以在其到达后立即开始播放，因为下一帧也将需要1000ms，并紧随第一帧发送-换句话说，它已经在途中，马上就会到达。显然，现实世界并非如此。如果大部分时间数据都在20ms内到达，除了有时需要5000ms，那么如果您不保留缓冲区并且1到50帧的延迟为20ms，则可以播放前50帧而没有任何问题。然后第51帧需要5000ms才能到达，您将在5000ms内没有任何视频数据。用户去访问其他网站观看可爱的猫咪视频。您真正需要的是一个5000ms的数据缓冲区-然后您就可以正常工作了。简单点说，您不关心数据包上的绝对延迟时间，而是关心该延迟的方差大小-这就是您需要多大的缓冲区。要测量绝对延迟，您必须使两台机器上的时钟同步。A机器将发送一个带有时间戳12337849227 28的数据包，当它在B机器上的时间为12337849227 48时，您将知道该数据包需要20ms才能到达那里。但由于您关心的是方差，因此需要（如RFC 3393所述）从A机器接收多个数据包。A机器发送带有时间戳1233784922 72 8的数据包1，然后10ms后发送带有时间戳1233784922 73 8的数据包2，然后再过10ms发送带有时间戳1233784922 74 8的数据包3。

机器B在其所认为的时间戳1233784922 12 8接收到数据包1。从机器B的角度来看，机器A和机器B之间的单向延迟在这种情况下为-600毫秒。显然，这完全是胡说八道，但我们并不关心它。机器B在它认为的时间戳1233784922 15 8接收到数据包2。单向延迟为-580ms。机器B在它认为的时间戳1233784922 16 8接收到数据包3。单程延迟再次为-580ms。

同上，我们不关心绝对延迟有多少，所以即使它是负数、三个小时或其他任何值也无所谓。我们所关心的是延迟量变化了20ms。因此，您需要一个20ms的数据缓冲区。

请注意，在这里我完全忽略了时钟漂移的问题（即运行在机器A和B上的时钟以稍微不同的速率运行，例如每秒实际经过的时间机器A的时间会以每秒1.00001秒的速度增加）。虽然这确实引入了测量不准确性，但在大多数应用中其实际效果可能不是一个问题。

- Jon Bright