确定NetFlow数据包中数据流的绝对时间的最佳方式是什么？看起来只有相对时间信息包含在流程中（流程开始和结束时的SysUpTime）。NetFlow时间戳
对于Netflow v5和v9，可以通过Unix Seconds计算包头中的一个SysUptime字段：UnixSeconds - SysUptime + FlowStartSysUptime。但是，UnixSeconds字段只有一秒的精度。在IPFIX（v10）中，报头仅包含创建数据包的系统时间，但不包含系统正常运行时间。
某些IPFIX导出程序通过使用较新的绝对时间戳字段（例如flowStartSeconds（150），flowEndSeconds（151））来避免此问题。有毫秒精度，微秒精度等变体。请参阅： http://www.iana.org/assignments/ipfix/ipfix.xhtml
（另请注意，在IPFIX报头中的绝对时间应该是接近当数据包实际完成并送到，所以你至少有一个镜头在造型时钟出口商之间的偏移和你的收藏家： https://tools.ietf.org/html/rfc7011#page-14）
但正如你指出，问题当IPFIX出口发送老式字段flowEndSysUpTime（21）和flowStartSysUpTime（22）出现。这对于NetFlow v1-9来说是可以的，因为头文件的时间戳也是用sysUpTimeSeconds表示的，但是使用IPFIX它会让你搁浅。
一个简单的解决方法是假设流动总是及时冲洗，计算出它们的持续时间，并与现在排队：
duration = flowEndSysUpTime - flowStartSysUpTime
start = (NOW - duration)
end = NOW
另一种方法是假设至少一些流及时刷新，并使用flowEndSysUpTime数保持每个设备启动时间的估计：
boot-time = MIN(NOW - flowEndSysUpTime)
start = boot-time + flowStartSysUpTime
end = boot-time + flowEndSysUpTime
但你必须要小心，以检测启动时，如果在德维你估计的阶跃变化ce实际上是重新启动的。如果连续快速重启两次，该步骤更改可能只有约30秒。有些事情需要考虑 - 但由于这些传统领域只能精确到1秒，所以并不清楚聪明是值得的。