因此，您需要了解给定的交换设备如何定义流。有明显的识别内容——源和目标端口/地址、IP 协议号等的元组。显然还有一个开始时间，当然还有一个结束时间。

开头很简单。这是观察到识别元组的第一个点。然而，结局要复杂得多。在 TCP 会话的情况下，看到 FIN 序列可能会触发停止时间，但通常流结束时间将由超时（即在n秒内未看到数据包的 UDP 会话）或-在实践中更有可能 - 流缓存已填满，并通过触发旧流的清除和导出来为新流腾出空间。

问题是流程（正如我们定义的那样）实际上可能还没有结束。事实上，一个长期存在的流实际上可能由许多连续的流记录来表示。分析工具的工作是将所有这些单独的记录联系在一起，形成某种健全的整体。

正是出于这个原因，您的问题实际上没有意义。实际的流收集器/导出器可能不知道它所使用的流缓存条目是代表线路上实际流的开始还是结束。关于基于流的收集机制的一个令人讨厌的事实是，缓存的相对有限的大小意味着在识别线路上的元组时适当大的变化可能导致流记录在被推送之前只看到几个数据包的退化情况出去。这就是为什么在大型互联网核心盒上使用此类分析往往非常有限，并且在基于流的测量发生的地方（聚合/边缘平台）几乎完全是采样的。

所以 - 如果您只想查看流程的前几秒，请将收集设备上的老化时间设置为非常短。这将导致大量流记录被导出（并消耗更多资源），但会在很短的时间间隔内为您提供数据。反过来，在分析时，您可以选择忽略除生成的第一条记录之外的所有记录。我看不到这种方法的胜利，但它至少在名义上符合您的要求。