五一假期结束后，我打开公司笔记本，第一件事自然是运行ping检查网络。本该是一次 routine 的排查，却收获了一个意外的提示：「ping 竟然在周一早上就对我采取了反制措施！」
事情是这样的：电脑刚开机，系统 NTP 服务还没来得及同步时间，时钟被回拨到了更早的时刻。这时我启动了 ping，它测得的往返时间（RTT）竟然是负数。按照常理，既然算出来是负的延迟，ping 大可以当作 Bug 处理，输出一串毫无意义的数字然后跳过。但 ping 的开发者选择了另一条路——它把这个负值标记为 0 毫秒，在统计里把它当作一次有效的测量。这，就是那条神秘的「countermeasures」信息的由来。
ping 测量时间的方式值得多说两句。现在的默认模式不再依赖本地时钟，而是调用 SO_TIMESTAMP 来获取更精准的网络时间戳。但在早期以及使用 -U 参数时，ping 会调用 gettimeofday 记录发送和接收的墙钟时间。如果在这之间系统时钟被调低，差值就会变成负数。这种情况确实不常见——大多数网络工具遇到这种异常可能直接忽略或报错，而 ping 选择静默处理，把「坏数据」伪装成正常测量。
这其实是一个很小但很贴心的设计：ping 没有让用户看到一笔乱码，而是在后台悄悄做了修正。对普通用户来说，这甚至不会被注意到，但背后是开发者对边界情况的周全考虑。
编注：信源为 Cloudflare 技术博客，作者为该公司工程师，材料涵盖一次偶然发现的技术细节与源码分析，可读性强。