UDP會話網路流
netflow 如何定義 udp 會話的結束。也就是說，據我了解，隨著時間的流逝，如果沒有來自動態埠的請求，則必須有一些超時，然後形成該埠的新會話。如果是，它是如何實現的，如果有超時它持續多長時間
這是一個可能會寫大量內容的領域，但這裡有一些要點：
1.) 任何 Netflow 實現都有一系列計時器，當超過這些計時器時，會導致流記錄被導出並從記憶體中刷新。
2.) 其中一個計時器是最大計時器。這裡的想法是，即使是正在進行的流程也會導致生成記錄。一個長期存在的流實際上可能會生成數十個（或數百個）連續記錄。一個很好的例子是 TCP 流持續，比如說，60 分鐘的實現，最大計時器為 5 分鐘。該流實際上可能由 12 (+/-) 條記錄表示。換句話說，即使沒有 FIN（或根本沒有會話結束），也會生成記錄。
3.) 另一個定時器是非活動/空閒定時器。在這種情況下，如果在x秒內沒有看到給定流的流量，則記憶體條目超時並導出記錄。這就是 Netflow 如何辨識任何非 TCP 流的結束（提示：並非所有實現都將 TCP FIN 正確地處理為關閉方法）。這裡有一個關鍵點要考慮：如果這個計時器很長，那麼您可能無法非常準確地了解給定流程實際結束的確切時間。
4.) 讓事情變得更有趣 - 如果有足夠的流量超出 Netflow 收集器上的記憶體，那麼許多實現實際上會提前老化流量以騰出空間。理想情況下，它會選擇具有較長空閒計時器的流，但如果記憶體耗盡變得足夠糟糕，我們實際上可以達到退化狀態，即每個數據包都會生成一個新流。順便說一句，這就是為什麼在大多數現代 DC 交換機中完整（即未採樣）的 Netflow 幾乎已成為過去，因為流記憶體的絕對大小變得完全站不住腳。
所以，一如既往，魔鬼在細節中。Netflow 實現在記憶體大小和採樣率、這些計時器（以及其他一些計時器）可以設置多低（或多高）、它們是否正確跟踪 TCP 標誌等方面有所不同。在 IPFIX/v9 中進行計算，其中本地可程式聚合在流收集等方面增加了另一層中介。