好的，这可能看起来微不足道，但由于我的应用程序所需测试的性质，我需要获得精确的时间戳。
我正在使用 WireShark 来分析数据包。
假设我有一个包含 2 个主机 h1 和 h2 的网络。
h1和h2分别通过接口h1-eth0和h2-eth0相互连接。
当我在主机 h1 上运行 Wireshark 来捕获接口 h1-eth0 时，我能否绝对确定记录的时间戳与主机 h1 的系统时间相对应？
虽然情况应该如此，但除了您的有用评论之外，如果我能获得引用相同的链接，那将非常有帮助（这只是为了使我的申请正式化）。
[结束语]：tcpdump 时间戳模块的手册页。投射式电容。
注意：手册页是由 Guy Harris 自己编写的。:)
引用：
捕获流量时，每个数据包都会被赋予一个时间戳，表示传入数据包的到达时间，以及传出数据包的传输时间。此时间是到达或传输时间的近似值。
答案1
假设我有一个包含 2 个主机 h1 和 h2 的网络。
h1和h2分别通过接口h1-eth0和h2-eth0相互连接。
当我在主机 h1 上运行 Wireshark 来捕获接口 h1-eth0 时，我能否绝对确定记录的时间戳与主机 h1 的系统时间相对应？
如果你运行Wireshark（或tcpdump、WinDump、snoop、Microsoft Network Monitor、Sniffer、OmniPeek、Commview或任何其他嗅探器；答案并不特定于 Wireshark...）在主机 h1 上，数据包来自在主机 h1 上运行的操作系统的网络堆栈中的捕获机制，时间戳对应于该网络堆栈为数据包打上时间戳的时间（即，由主机 h1 打上时间戳），或者在某些情况下，对应于插入主机 h1 的网络适配器为数据包打上时间戳的时间（或者，在 HP-UX 上，对应于 libpcap 读取数据包的时间从主机 h1 上的网络堆栈，因为 HP-UX 的捕获机制本身不会对数据包进行时间戳记）。
因此，时间戳最接近于运行嗅探器程序的机器上的主机时间。它确实不是必须与数据包到达主机 h1 的网络适配器的精确时间相对应，精确到微秒或纳秒（除非网络适配器为数据包打上时间戳；大多数不支持）。数据包到达网络适配器的时间与打上时间戳的时间之间可能存在延迟，可能包括：
- 数据包到达和发出中断信号（告诉主机数据包已到达）之间的时间（不一定每个数据包都发出中断信号）；
- 发出中断信号和主机响应中断之间的时间；
- 主机响应中断和数据包被交给捕获机制之间的时间；
- 数据包被交给捕获机制和被捕获机制打上时间戳之间的时间。
因此，如果您所说的“我是否可以绝对确定记录的时间戳与主机 h1 的系统时间相对应？”是指“我是否可以绝对确定记录的时间戳与数据包到达时主机 h1 的系统时间高度精确地相对应？”，答案是“不一定，即使您在主机 h1 上运行”。它更接近数据包到达主机 h1 的时间，而不是数据包从主机 h2 发送的时间，但如果您需要知道高精度和高准确度的时间戳值，则需要专门的硬件来在网络适配器上对数据包进行时间戳记，或者需要经过特殊调整的接收代码路径（这可能意味着您必须破解接口驱动程序代码和网络堆栈代码；这种经过特殊调整的接收代码路径不是 Linux 内核的配置选项或 Windows 内核的注册表选项）。
（顺便说一句，Mitch 的回答只适用于 Windows；例如，在我的个人电脑上没有这样的例程KeQuerySystemTime- 数据包带有时间戳，并使用名为 的例程返回的值进行标记microtime。）
答案2
请记住，Wireshark 是查看器，winpcap 是捕获应用程序。
根据代码和邮件列表中的有用帖子，时间戳来自查询系统时间在非 x86 系统上，以及 KeQuerySystemTime 和韋斯特電腦非 x86 系统上的指令。
无论如何，相对于系统时钟，您的精度应该高于 100ns。
答案3
在您提到的配置中捕获网络流量时，您根本无法获得精确的时间戳，原因如下：
- 在 Windows、Linux 和 FreeBSD 上，您必须记住，由于主机上的负载以及网络驱动程序和 NIC 本身的实现性质，时间戳很容易偏离至少几毫秒（最多 10-25 毫秒）。特别是网络中断处理以及内存分配和其他硬件中断处理（例如来自硬盘驱动器的中断处理）会导致延迟。认识到这个问题后，现代操作系统通常使用两步中断处理。将中断处理分为短段和长段进一步造成了对接收此或该数据包的确切时间的混淆，因为在同一台机器上必须进行所有其他过程。因此，您无法确定任何时间测量，并且很难获得任何准确性或精确度。
- 时钟漂移。除非您有专门的硬件，否则随着时间的推移，您的时间戳会漂移。例如，几个小时或几天后，主机 h1 和 h2 上的时间戳会相差几秒或更多。仅供参考：根据英特尔规范（2004 年 10 月），HPET 漂移为 500 到 2000 ppm 或 0.05% 到 0.2%，而较旧的 RTC 甚至更糟。
- 如果突发流量超过了 NIC 驱动程序分配的缓冲区数量，您可能会遇到因硬件流控制而导致的数据包丢失或时间戳不正确的情况。
简而言之，使用在同一台主机上运行的 winpcap 对主机进行基准测试非常困难。我通常使用具有良好时钟的外部数据包捕获设备，例如 USC4060。