为 VPN 上的实时流量设定延迟预算

实时 VPN 投诉需要一个可以据以判定失败的截止时间，而“低延迟”并不是这样的截止时间。先确定通话或远程会话必须交付什么，再在既定条件下按这一要求测量路径。没有迟到包阈值，任何结果都可以争论。下面的分配是一项设计决定，它的存在是为了让测量有可回答的对象。

在碰探头之前先写下截止时间

截止时间来自应用及其用户，而不是供应商的营销页面。实时语音通话、远程桌面会话和夜间备份能忍受的等待时间完全不同，而真正要紧的失败通常出现在尾部而不是中位数。把这个数字和它所属的工作负载一起写下来。

然后把它分配下去。采集和打包占用预算的一部分，接入链路和隧道占用另一部分，接收端的去抖动缓冲会有意滞留数据包，应用处理占用剩余部分。给这些阶段命名，能让隧道加密保持在应有的比例内，而不是让它成为每个慢包默认的嫌疑对象。

最后用四行定义测量契约：端点与方向、流量形态、运行期间的条件，以及你将报告的结果。安静的周日样本和满载的周二样本回答的是不同问题，所以要说明你采集的是哪一种。如果四行都填不出来，这次运行就不具备开始的条件。这份清单也正是让两份报告在几个月后仍可比较的东西，那时没人记得链路还承载了什么。

把预算拆分到每个阶段

这张表是规划辅助，不是采集到的数据。在第一次测量前就为每一行填上负责人，因为当该阶段超出它的份额时，你要找的就是负责人。

有两行通常让人意外。接收端缓冲在增加延迟时并不是故障，因为它在做被配置去做的事。而隧道的份额往往比它前面的排队更小，尤其是在上传期间被占满的上行链路。

当某个阶段没有负责人时，预算就是虚构的。在测量前指定一个，否则下一次会议就会花在争论谁的数字错了上。

用诚实的时钟测单向延迟

单向延迟才是截止时间在意的数字，它需要两端都有同步时钟。单向延迟指标 要求你在结果旁边报告同步方法、分辨率和估计偏差。两台未同步的主机可以为错误的量给出一个非常精确的数字。

采集几百个包而不是一小把，并同时记录时钟状态：

$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3

往返时间是独立的测量，不是两个单向值相加。把 RTT 减半假定路径对称、排队对称，而移动上行链路之上的隧道经常同时打破这两个假定。把 RTT 当成 RTT 报告，并把它排除在单向预算之外。

报告尾部和迟到包

总结分布：中位数、95 和 99 百分位、最坏情况、丢包，以及晚于截止时间允许才到达的包数。对实时工作负载来说，平均值是这些数字中最没用的，因为平滑的平均值会掩盖一个毁掉每三通电话其中一次的尾部。

延迟变化会直接进入接收端缓冲。更多缓冲会掩盖变化并增加等待，因此一条流可以在超出截止时间的同时看起来稳定。选择一种变化表述，说明你测量的时间区间，并在多次运行之间保持一致。

用有代表性的交叉流量重复运行。一条在空闲时满足预算、在备份窗口期间又不满足的路径，已经告诉了你关于调度的有用信息，这是任何一次安静测量都不会揭示的。把条件记在结果旁边，否则下一位工程师会去比较两个从来就不可比的样本。

当测得的尾部在你实际运行的工作负载下符合预算时接受该设计，并在报告中点名超支的阶段来否决它。