全文共18000字，講解了網路測量和計數中的多方面知識：網路測量的意義、網路測量的手段分類、網路測量在實現上的挑戰、以及解決這些挑戰所用到的技術和協同方案等等。
參考書籍有：《Network Algorithmics: An Interdisciplinary Approach to Designing Fast Networked Devices (2nd Edition)》
本博文首發於部落格園：https://www.cnblogs.com/grapefruit-cat/
本文作者：grapefruit-cat ，轉載需在文章頭部標明出處。
1 前言
在現實中要對某些任務做出最佳化，必定要先進行一定的測量。只有進行了對效能的測量量化，你才能知道任務的瓶頸在哪，才能對相應執行位置做出好的最佳化。不要在未做測量的情況下帶著主觀臆斷去做最佳化！！
Premature optimization is the root of all evil. ——D. E. Knuth.
這個原則在計算機網路裡面同樣適用。對一個特定網路的流量使用軟體或者硬體工具進行測量，不僅可以描述這個網路的特徵，而且可以在測試出網路的執行狀態，如在流量不穩定或者流量過多時採取相應的最佳化措施，從而更好地設計網路。
2 為什麼需要網路測量？
從架構視角上看，網路測量可以描述出當前網路的流量狀態，可以得到當前網路的拓撲資訊和效能資訊，還可以對一個具體的協議的執行結果進行觀測，這就使得當一個新的想法出現時，可以將網路測量當成一種實驗的手段，來摸索出新想法的效能表現。
而從提供服務的視角來看，網路測量可以根據測量出的流量特徵（如用了什麼型別的流量、用了多少）向客戶計費；可以檢查網路的QoS並觀測診斷解決存在的問題；可以為以後增添升級裝置做好開銷預算。
舉一個例子，在服務提供商網路中，資料包計數和流量日誌記錄為以下任務的最佳化提供了資料支撐：
- 容量規劃（Capacity Planning）: 網際網路服務提供商(ISP)需要確定流量矩陣，即他們所連線的所有源子網和目的子網之間的流量資訊。這些得到的資訊可以在短時間尺度(例如，幾個小時)內使用，透過重新配置光交換機（optical switches）來執行流量工程（traffic engineering）;它也可以用於較長的時間尺度(例如，幾個月)來升級鏈路容量。
- 計費工作（Accounting）：ISP與客戶和對等體（peer）之間實現了複雜的服務水平協議(service level agreements，SLAS)。基於總體流量（即單純的傳輸資料量）的簡單計費可以由單個計數器輕鬆監控得出；然而，更復雜的基於流量型別的協議需要給每個流量型別安排一個計數器，這樣才能根據流量型別來進行分級計費。資料包計數器也可以用在ISP之間的互聯對等關係上。假設ISP-A目前正在透過ISP-B向ISP-C傳送資料包，並且正在考慮與B直接連線(對等互聯)，那麼A進行計費的合理方法是統計到達B對應網路字首的流量。（ISP-C 並沒有直接參與到對等互聯關係中，而僅僅是透過 ISP-B 來間接地與 ISP-A 通訊。因此，針對ISP-C 的流量並不會作為對等互聯計費的一部分。）
- 流量分析（Traffic Analysis）：網路的管理者們通常需要時刻留意著不同種類流量的表現。例如測量到點對點流量激增，就需要對其做出一定的速率限制；再例如ICMP訊息型別的流量激增意味著有可能發生了Smurf攻擊。
3 網路測量的分類
從測量目標去分類，可以把網路測量分為以下三類：
-
端到端效能測量：透過主動測量方式來測量網路中各個節點之間的效能指標，如網頁下載的平均時間、TCP批次吞吐量等。
-
狀態測量：主要集中在對網路拓撲、配置、路由等的測量，如當前活躍的路由、活躍的拓撲部分、鏈路的誤位元速率等。
-
流量測量：主要集中在對資料包和資料流的測量，以及對鏈路的統計資訊，如鏈路使用率、流量矩陣、需求矩陣等。
從測量方式去分類，可以劃分為主動測量和被動測量兩大類。定義上，主動測量方式透過向目標鏈路或目標節點主動傳送資料包，來測量鏈路或端到端的延遲、頻寬和丟包率等網路效能引數，這種方式比較精確但往往會對網路效能總體產生影響；而被動測量方式透過接入網路的測量探針被動地嗅探網路流量，透過記錄和統計網路鏈路或節點上業務流量的資訊來分析網路效能。兩種測量都可以在控制平面和資料平面上執行，在同一類平面上兩種測量得到的結果種類均相同，即在控制平面上可以得到網路的拓撲、配置以及路由資訊，在資料平面上可以得到端到端效能資訊、鏈路統計資訊以及資料包和資料流的特徵資訊。
從測量物件來分類可以分為資料包測量和資料流測量。
下面將從兩種測量物件出發作闡述。
4 包測量
包測量是一種被動測量方式，透過被動地在一或多個鏈路上收集資料包，記錄包中各層的路徑資訊。它的測量範圍主要集中在記錄使用者行為的細粒度資訊，被動地監測網路基礎設施的執行，描述當前流量特徵和診斷相關問題。下圖描述了包測量的中心監測器測量鏈路時，在不同的網路拓撲中所處的測量位置：
4.1 測量獲得的後設資料
包測量在開始時需要根據我們測量的需求，對測量的流量進行後設資料提取——而不是對單個包包含的所有資訊都進行提取分析。我們需要根據一定的標準對資料包進行不同方面的測量分析，具體的分析標準可舉例如下：
- 對資料包的IP做特定分析，如需要測量某個特定站點來的流量時，需要區分出特定的IP或IP字首；
- 對資料包的執行協議做特定分析，如區分為TCP、UDP或ICMP包；
- 對資料包的埠號做特定分析，某些特定的埠上執行著特定的協議，如HTTP、DNS、BGP等。
對於如何拿到這些後設資料資訊，我們可以透過接收資料包時擷取頭部欄位的位元組來完成這份工作，這頭部的前n個位元組往往能夠實現對資料包種類的區分。以下展示了一些不同協議的頭部欄位位元組範圍：
| 頭部種類 | 位元組長度 |
|---|---|
| Ethernet MAC | 14 |
| IP header | 20或36(IPv6) |
| IP+UDP | 28或44 |
| IP+TCP | 40或56 |
| 應用層資訊 | 整個資料包（應用層頭部+overload） |
在對資料包頭部包含的資訊做分析提取後設資料時，不同協議型別的頭部欄位分析的重點也不同。
對於IP頭部資訊的測量，對源地址和目標地址的測量可以獲取哪一個伺服器或哪一個站點在當前是流量較高、熱門的；對兩個特定地址之間吞吐量的測量可以對效能問題進行檢測和診斷；對途經路由器的資料包時延分佈情況的測量，可以識別出典型的延遲和異常情況；測量大小欄位可以獲取資料包大小的流向分佈情況，可以得到路由器工作負載模型；如果測量出鏈路上某些特定方向的流量激增，那麼就可以將該資訊用於重新分配鏈路容量和重新配置處理佇列。
而在TCP頭部資訊中，源埠和目的埠的測量記錄可以推斷出當前熱門的應用；對TCP序列號或ACK編號以及資料包時間戳的測量可以得到當前傳輸中無序或丟失的資料包有哪些，可以得到丟包率、吞吐量和延遲資訊；對每個TCP連線的傳輸的資料包數或位元組數的測量可以得到批次傳輸的頻率；對來自客戶端的SYN資料包測量，則可以知道當前失敗的請求數量，以及可以檢測出是否存在Dos攻擊；對來自客戶端的FIN或RST資料包，可以得到由客戶端中止的Web傳輸的頻率，以及推斷出相關應用程式的行為。
而在應用層資訊的測量中需要對整個資料包內容分析，對不同的應用層頭部，如HTTP請求和響應報頭、SMTP命令和響應資訊、DNS查詢和響應資訊、OSPF/BGP訊息等，可以做不同的測量；而對應用層overload的測量主要集中在附帶資訊上，如請求的HTTP資源有什麼，RPC中的key-value cache操作有哪些，RPC中的pub-sub訊息分佈等。但要注意的是這些測量在當下加密通訊中變得越來越困難。
5 流測量
與包測量以單個資料包為監測單位不同，流測量以”屬於同一組“資料包為單位，多個同一組的資料包被劃分到一個資料流中去測量。
對”屬於同一組“的劃分標準，同樣可以使用資料包中的頭部欄位資訊。與包測量的流量選取相似，我們可以根據源地址和目的地址、源埠和目的埠、執行協議型別、ToS種類等進行劃分。除了資料包本身附帶的資訊，我們還可以使用路由器上資料包的出入埠資訊來進行流劃分。另外，資料包還需要根據時間進行劃分。同一組的資料包即同一個資料流在時間尺度上不能距離太遠，即使是在資訊上劃分為同一組的資料包，也可能因為時間上的相差而劃分到不同的資料流中。
5.1 為什麼做資料流的抽象？
資料流劃分的意義在於讓測量的物件更加接近於“應用程式級別“的互動單元，採用資料流作為測量的基本單位可以更好地反映應用程式的實際行為和需求。
與資料包相比，資料流可以更好地描述應用程式的互動過程。例如，在影片流媒體應用中，一個資料流可能由多個資料包組成，這些資料包共同構成了一個連續的影片幀或音訊樣本。如果僅考慮單個資料包，則無法完整地描述影片或音訊流的特徵。
此外，資料流也反映了應用程式之間的互動關係。例如，一個Web頁面可以由多個HTTP請求和響應資料流構成，並且這些資料流在應用程式之間的互動中扮演著重要角色。透過對資料流進行分析和測量，我們可以更好地理解應用程式之間的互動方式並評估網路效能。
此外，以資料流為測量單位還可以針對轉發或訪問控制對路由器進行最佳化。如採用IP-over-ATM技術的流交換正規化可以利用其快取結果對路由器進行轉發或訪問控制決策上的最佳化，再如Netflow技術可以聚合透過路由器的流量資訊。
5.2 測量獲得的後設資料
我們從流測量提取後設資料的過程展開論述。首先流測量要對接收到的資料包做一定的劃分，如上面所述，劃分可以依靠讀取資料包頭部欄位資訊來完成，主要讀取的資訊有源地址和目標地址、埠號、其他 IP 和 TCP/UDP 標頭欄位（如協議欄位、ToS欄位等）。劃分出資料包子集（準資料流）後，便對整個子集的一些資訊做一定的聚合，生成流記錄資訊，如準資料流的開始和結束時間（第一個和最後一個資料包的時間），流中的總位元組數和資料包數量，TCP 標誌位序列資訊等，這種對整個流的資料特徵測量可以幫助我們分析網路流量趨勢和週期性變化，以及預測未來流量的可能方向。
除了資料流中來自資料包“自身”的資訊以外，還需要測量該資料流的路由資訊。常見的路由資訊有資料包在路由器交換結構中的轉發方向，即資料包的出入埠；還需要記錄其源子網和目的子網的資訊，這個可以透過記錄源和目的IP地址字首來實現。
流測量獲取的資訊和包測量有一些異同之處。在基本資訊的獲取上面，它們兩者都可以計算收到資料包的平均大小，可以獲取不同IP地址、埠號、協議的混合的流量資訊，但在按時間尺度測量流量方面，除了兩者都能完成的中長期時間尺度上測量之外，包測量還可以測量出短期時間尺度上網路流量的突發激增。另外在運輸層的測量上，兩者都能測量出特定連線中傳輸的總資料量大小，但包測量因其以單個包做測量的特性，能夠測量出資料傳輸中的亂序率或丟包率。
5.3 流測量的底層實現
5.3.1 在何處生成流記錄？
流測量生成流記錄的過程在哪裡實現是一個需要多方考慮的問題。如果由路由器中的CPU負責流記錄生成，那麼就有可能影響到路由器的路由效能；如果由路由器埠處的線卡負責生成，雖然能夠更有效地支援測量，但線卡的適用性和可擴充套件性受制於其裝置相容性，需要額外的部署和維護成本；除了CPU和線卡，我們還可以利用在資料流途徑路由上的資料包監視器來生成流記錄。
我們來看一些流測量的底層支援機制。
5.3.2 硬體機制 Flow Cache
Flow Cache是一種基於硬體的快取機制，可以在網路節點上快取每個資料流的後設資料，例如源 IP 地址、目標 IP 地址、埠號、協議型別、資料包數量等。這些後設資料可以用於識別特定型別的資料流，如影片、音訊、檔案傳輸等等，並確定它們在網路中的來源和目的地。同時， Flow Cache 還可以記錄資料流的持續時間、流量大小和延遲等流特徵。
Flow Cache的韌體可以使用TCAM或SRAM等方式來實現，而快取操作依賴於Flow Cache中的控制器（Flow Cache Controller ）來實現。Flow Cache Controller 是一個獨立的元件，它負責管理整個 Flow Cache 的生命週期，包括快取的建立、維護和刪除等操作。
當一個新的資料包到來時，Flow Cache Controller會根據源和目的地以及埠號三者計算出一個鍵值（key），並將其作為建立或更新快取中流條目（entry）的依據—— Flow Cache Controller會檢查該 Flow 是否已經存在於快取中，並根據配置的快取規則判斷是否需要快取該 Flow。如果需要快取，則會計算出該 Flow 的後設資料儲存位置並將其儲存到快取中。圖示為Controller 計算鍵值和索引到快取條目。
在計算後設資料儲存位置時，Flow Cache Controller 會考慮多種因素，如儲存裝置的容量、負載均衡、資料安全性等因素，以保證快取的高效性和可靠性。同時，它還會監控快取的使用情況，自動調整快取策略和儲存位置，以最大化快取的利用率和效果。
當Flow Cache條目達到一些條件如超時、對映衝突的時候，就需要對條目進行刪除或替換。超時是指快取中的資料流條目在一段時間內沒有被訪問。Flow Cache Controller 會對資料進行週期性排序，對於超時的資料流，即最近未接收到資料包的流，會被Controller自動清除。當快取被填滿時，Controller會根據一定的演算法，如LRU、隨機選擇等，去用新的條目替換掉演算法計算對映到的舊條目。
5.4 流測量的開銷
流測量的開銷主要集中在兩個方面：對每個資料包的處理和對每個資料流的處理。
對資料包的處理開銷主要集中在Controller計算鍵值和索引到快取條目上。在資料流中如果資料包的平均大小較小，那麼測量處理的速度就可能會跟不上當前鏈路的傳輸速率——當存在許多大小較小的資料包時，測量就必須捕獲和分析更多數量的資料包才能獲取與大資料包相同的資訊量，這會增加處理開銷，對儲存的要求也更高（要求讀寫更快），從而影響測量的效能。
對資料流的處理開銷則主要集中在Controller建立和替換條目上。這主要由資料流的多少來決定。如果資料流中包含的資料包數量較少，那麼總體上的流數量就會較大，接收分析資料流的工作量就會加大，這同樣影響測量的效能。
6 網路測量的挑戰性
你可能會認為測量工作是一件非常平凡且簡單的事情——即使它很必要。但是對於高速運轉的網路來說，網路流量測量是一個很困難的問題。
6.1 為什麼測量很困難？
首先我們要知道，網路協議提供的資訊有時候並不完全符合我們作為使用者的需求，例如traceroute工具記錄路由路線，它是依賴於資料包的TTL來鑑別路由資訊的——而TTL的本意是告訴網路路由器該資料包在網路中的時間是否太長而應被丟棄。顯然，資料包承載的資訊並沒有明確告訴我們該包的路由資訊，我們不得不透過其它的手段來獲得我們想要的資訊。對於網路測量也是如此，網路並沒有給我們直接提供明確的測量特徵，但我們可以用對不同種類資料包計數的方式去巧妙地獲得流量測量資訊。
然而，資料包計數並不簡單。要想做到精確的網路流量測量，需要精妙的計數器。傳統路由器只提供執行SNMP協議的介面計數器，這類計數器很容易物理上實現——由於一個路由器介面僅僅只有幾個計數器（如位元組計數器、錯誤計數器等），如此少的數量可以很輕鬆地用晶片的暫存器來做到。但傳統的計數器只能用於很粗糙的計費（accounting）計算，無法做到按流量型別計算的計費，如對收費更高的實時流量的區分，以及對途徑不同等級的ISP的區分。所以我們需要精妙的具有過濾功能的計數器。
舉一個例子，我們可以透過簡單的辨認網路地址字首的方式來實現過濾計數，但物理上支援基於字首的計數會有不少的開銷：
- 考慮到即使是當前的路由器也支援500000個字首，未來的路由器可能達到1000000個字首，那麼一個路由器就需要支援上百萬個實時計數器；
- 每個資料包在路由時都要被不同的計數器進行資訊記錄，一個資料包可能對應多個流和多個字首；
- 隨著鏈路速率不斷上升，如從最初乙太網標準的10Mbps升至現在的400 Gbps乙太網標準，如此高的資料包接收速率意味著計數器的讀寫速度也要相應提高；
- 計數器的高讀寫速度意味著達到計數值溢位的時間將變得更短，需要將32位寬度的計數器升級為64位。
要保證高速讀寫，計數器的儲存介質就需要使用昂貴的SRAM或TCAM；但單單對於這一種支援字首計數的計數器來說，一百萬個64位計數器就意味著要使用64Mbit的記憶體，這代價是不可接受的。所以在當下的主要問題就集中在如何保證計數器高速執行的同時減少計數器的處理量以及所需要的儲存開銷。
下面我們來介紹一些對這類問題的最佳化方法，主要從減少儲存開銷和減少處理量兩方面展開。
6.2 減少儲存開銷
6.2.1 DRAM Backing Storage
我們先集中討論資料包計數的具體問題。實現資料包計數儲存的最簡單方法下圖所示。圖示中有100萬個基於目的地字首進行區分的64位計數器，每一個都使用SRAM來實現，當資料包到達時，相應的計數器將值遞增。
整整64Mbit的SRAM！如此大容量的SRAM非常昂貴的。我們不禁想到，真的有必要使用如此大容量而昂貴的介質去做計數嗎？能不能使用DRAM替代SRAM？但如果有一個資料包每8ns到達一次，我們就必須透過SRAM計數器來處理這個資料包，而不能使用DRAM——因為DRAM延遲高達40ns。顯然SRAM在處理需要快速響應的任務時的速度是DRAM遠遠比不上的，然而從直覺上來說，使用完整的64位SRAM是一種顯而易見的浪費。
但我們往往可以透過快慢結合的方式來解決這種矛盾的問題。DRAM和SRAM的最佳硬體特性可以結合起來使用，在價格上，DRAM至少比SRAM便宜四倍甚至十倍，但在速度上，DRAM速度較慢。這與計算機中的記憶體層次結構非常類似（Cache-記憶體-硬碟 結構）。這種類比表明，DRAM和SRAM可以組合使用，提供既廉價又快速的解決方案。我們可以使用DRAM作為SRAM的備份儲存器（Backing Storage）。
觀察一下，如果路由器為N個計數器的每個計數器都配置一個64位的DRAM，並再分配一個較小的寬度（例如12位）的SRAM，那麼只要每個SRAM計數器在溢位之前能夠將自身的值重新整理到DRAM，那麼計數就是準確的。這會大大減少SRAM的使用開銷！該方案上圖所示。然而，這需要一個好的演算法來決定何時以及如何重新整理SRAM計數器。
假設計數器允許每經k次SRAM訪問就重新整理一次到DRAM。那麼我們需要選擇足夠大的k，使得k次的SRAM訪問時間對應1次DRAM訪問時間。也就是說，k是DRAM訪問速度與SRAM訪問速度的比值。那麼如何決定所需的最小SRAM寬度呢？D.Shah等人在論文Maintaining statistics counters in router line cards中指出，在“pick-a-counter-to-flush”的演算法框架下，“條件最優”的計數器重新整理管理演算法，是每次重新整理都應選擇重新整理當前數值最大的SRAM計數器。透過這種演算法，SRAM計數器的寬度c可以明顯小於DRAM計數器的寬度M，準確來說有以下的量化關係：
其中N為計數器數量，k為計數器SRAM重新整理頻率，c為SRAM寬度。
注意到當k值較大時，分母的影響可以被忽略，那麼\(c\)的值就與\(log (log\ kN)\)掛鉤。舉一個例子，當資料到達速率為每8ns到達一次時，對於一百萬級別的N，在3個64位的DRAM的幫助下，僅僅需要空間消耗為8 Mbit、訪問速度為2.5μs的SRAM，DRAM的訪問速度也只需要達到51.2μs。此時k的值為\(51.2/2.5\approx21\)。如果不使用DRAM，也就是用最笨的辦法來實現SRAM計數器，那麼就需要使用高達192Mbit的SRAM！
但是還有一個問題需要解決：如何找出當前計數值最大的SRAM計數器。在2000年Bhagwan和Lin描述了一種流水線堆結構的實現，該結構可以在硬體複雜性和空間上以相當高的代價確定最大的值。它們的堆結構需要每個計數器的配置一個大小高達\(log_2N\)的指標，用以識別當前需要重新整理的計數器。在N高達百萬的量級下，這種指標反而會破壞我們將所需的SRAM位數從64減少到10的整體目標。
每個堆值都配置一個指標，這似乎很難避免。一方面，計數器必須位於固定的位置，以便在資料包到達時進行更新，但堆中的值必須不斷移動以維護堆屬性。另一方面，當最大值到達堆的頂部時，必須將其與計數器索引相關聯，以便將索引對應計數器SRAM重新整理到DRAM中。還要注意的是，堆中所有值的儲存，包括指標和值，都必須在儲存在SRAM中以提高訪問速度。Ramabhadran和Varghese在2003年提出的一種LR演算法最佳化了這個問題（Efficient implementation of a statistics counter architecture），它可以達到相同的SRAM計數器寬度，並使用點陣圖去維護所有高於重新整理頻數k的計數器。
從表面上看，整個方法與通常使用的記憶體層次結構類似，其中較快的SRAM充當較慢的DRAM的快取。然而，與傳統的單一快取方式不同，這種設計確保了最壞情況下的效能而不是預期的情況下的效能，即在任何情況下都能提供一定程度的效能保證，而不僅僅是在常見情況下。不同之處還有，傳統的快取只儲存一些頻繁訪問的資料，而不是全部資料；而計數器快取則會為所有接收到的資料儲存條目，但會試圖去減少每個條目所佔用的儲存空間，以便在記憶體有限的情況下儘可能多地儲存資料。
6.2.2 隨機計數
使用DRAM作為備份儲存器可以大幅度減少儲存開銷，但減少的SRAM計數器寬度會換來更多的處理量和複雜性。那麼我們的第二種方法就是用結果的準確性和確定性來換取計數器寬度的減少，即“精度換開銷”。
精確的統計資料通常過於昂貴且難以獲得，而許多問題的近似答案是可以接受的，如流量大小的分佈、出現頻率前N的流等，對於這些資訊，其實只需要記錄一個近似的值就足夠了。
隨機計數的基本思想為：對一個寬度為b的計數器，其記錄值最大上限為\(2^b\)，即如果按照傳統的確定性的方式計數，一個b位的計數器最多隻能計數\(2^b\)次；但如果引入隨機計數，假設一個計數器被選中後進行計數的機率為\(1/c\)，那麼它的計數次數最高可以達到\(2^b*c\)次。計數上限整整高了c倍！
為什麼隨機計數也能獲得相對正確的結果？這是因為在隨機計數的基本思想中，標準結果與實際結果的標準差（即計數器誤差的期望值）大致為幾個c的大小，其中c對於計數器值來說是非常小的。即在基本的隨機計數方法中，當計數器值遠大於計數機率c時，標準差會變得很小。也就是說，如果計數器的值足夠大，則誤差會相對較小且可控，從而使得估計的結果更加精確可靠。因此，這種方法可以在保證一定精度的同時，降低演算法的複雜度和記憶體需求。對此R. Morris提出的隨機計數思想也是如此，他注意到，越高的計數值可以容忍計數結果中越高的誤差絕對值。例如，如果標準差等於計數器值，則真實值可能在計數器確定的值的一半到兩倍之間。允許誤差隨著計數器值的增加而縮放，反過來可以使用更小的計數器寬度，即要實現\(2^b\)的計數上限，只需要k的計數器寬度，使得\(2^b=2^k*c\)。
對於計數機率c的確定，Morris的理論將c的值設定為一個不確定的值——c將會隨著計數器當前值x變動。而c與x的關係可以用下式表示：
這樣計數誤差的範圍會隨著計數器值的大小而變動。而計數器值x可以表示出結果的近似值，近似值為\(2^x\)（要注意，計數器值並不等於結果數值！）。因此，對同樣的結果上限值MAX，採用隨機計數後，計數器的寬度k僅僅為\(log\ (log MAX)\)。關係式梳理如下：
6.2.3 閾值聚合（Threshold Aggregation）
前面講的都是如何將計數器的寬度減少，接下來我們需要關注的是如何將計數器的數量減少。我們可以使用計數器閾值聚合的方法。
愛因斯坦有一句這樣的話，“Not everything that is counted counts, and not everything that can be counted .”
不是所有的值都是值得保留的。計數也是如此，計數是為了得到滿足我們需求的值，在這過程中難免會有一些額外的值被計算進來，要儲存這些值就需要額外的計數器。所以我們有必要拋棄掉這些用途不大的額外值，此時閾值聚合計數技術就派上用場了。
在傳統的計數器中，每個計數器通常都需要單獨儲存，並且可能需要佔用大量的記憶體空間。而且當計數器數量非常大時，對這些計數器進行處理和分析的時間和資源成本也會顯著增加。閾值聚合是一種常見的減少計數器的方法。該技術主要透過將原始計數器的值進行聚合來實現減少計數器的目的，從而降低計算和儲存成本。
閾值聚合可以用於在流測量中對”大象“流和”老鼠“流的區分上。在我們日常生活中，我們會開通各種的流量套餐，每種流量套餐有它自己的流量額度——所用流量低於這個額度時按照套餐計費，高於這個額度時則動態計費，這個額度就是一個閾值。另外，對於一個關心著路由流量熱點或網路是否正在被攻擊ISP運營商來說，大象流顯然比老鼠流更值得留意。
（大象流是透過網路鏈路進行大量的，持續的傳遞資料的過程；而老鼠流是透過網路鏈路進行少量的，短時間的資料傳遞過程。具體區分的臨界點，不同的場景是不一樣的。參見定義：Elephant flow和Mouse flow）
下面來結合上圖來簡單解釋一下閾值聚合。圖中展示了一種最簡單的閾值聚合方式：將高於或等於特定閾值的計數器值儲存下來，其它的計數器值扔掉。閾值可以選取一個與總流量大小有關的值，如總流量大小的0.1%，這個值就可以作為區分大象流和老鼠流的標準，留下了的計數器值就代表了當前存在的大象流。假如網路中最多隻有1000個大象流，我們只需要使用1000個計數器就能完成流測量！
但是很明顯我們發現了一個悖論問題：閾值聚合可以減少計數器數量，但要應用閾值聚合，就必須先對所有輸入的資料流進行計數器計數。這就違背了我們開始減少儲存開銷的意願。所以怎樣才能做到，既不用跟蹤所有的流，也能辨別出大象流呢？下面我們來看一種依賴於流雜湊的方法。圖中為對多個流進行並行雜湊對映並判斷是否為需要的流：
計算識別大象流的核心在於多個雜湊層（圖中的stage）的並行協作。其中，一個雜湊桶由多個計數器組成，每當有資料包到達時，Controller會根據雜湊函式來計算該包的索引鍵值，並將其存進相應的計數器中。也就是說，一個計數器記錄著一個流的資訊。
首先讓我們考慮僅僅存在一個雜湊層的情形。當一個屬於資料流F的資料包到達時，Controller將其計算並索引到相應的計數器，並將資料包的大小新增到計數器值中；當資料流F傳送的位元組數大於閾值T時，對應F流的計數器的值也就超出了閾值，那麼我們就意識到這是一個屬於大象流的計數器，就可以將該流的資料送進流記憶體做進一步的分析處理。
但單個雜湊層有一個明顯的缺陷：由於我們需要減少計數器數量，所以雜湊層中的計數器數量是少於所有流的數量的，那麼不同的流就有可能雜湊到同一個計數器中。這會導致兩種測量上的誤差：老鼠流會雜湊到屬於大象流的計數器中，或多個老鼠流雜湊到同一個計數器而導致計數值高於閾值，使得Controller認為這是一個大象流。
所以我們使用並行的多個雜湊層來做流雜湊對映，不同的雜湊層使用不同的雜湊函式。對一個資料包，只有其雜湊到各層的計數器值都大於閾值，才能認為這是一個大象流，才可以將流資料送進流記憶體中。如圖所示，假設對於一個屬於資料流F的資料包到達Controller，它在不同雜湊層分別被雜湊到3，1，7這三個計數器中，只有Controller判斷三個計數器值都大於閾值時，流F的資料才會被送到流記憶體中。
我們繼續做一個簡單的分析。假設有一條100 MB/s的鏈路，流的數量為100,000，我們希望在1秒的測量間隔內識別鏈路傳輸量1%以上的流量，即流量大小為1MB以上的流。如果按照傳統方式，我們至少需要100,000個計數器。但現在，假設每個雜湊層有1000個計數器，閾值為1MB。讓我們來計算一下，一個流傳送了100KB大小的資料並被識別送到流記憶體的機率是多少。
要使該流成功在一個雜湊層中被識別出，即該流的計數器需要達到閾值，那麼該計數器中在該流輸入前的值，即其他流雜湊到該計數器的總和，需要達到1 MB-100KB=900KB。而在每個雜湊層的1000個桶中，至多有99.9MB/900KB=111個這樣的準備達到閾值的桶。因此流在一個雜湊層被識別成功的可能性至多為11.1%。而對於四個並行的雜湊層，不大於100KB的小流量透過所有雜湊層的機率是一個非常小的值，其最大值為\(1.52*10^{-4}\)。
這種閾值聚合方案的可擴充性極高。如果流的數量增加到100萬，我們只需新增第五個雜湊層即可獲得相同的效果。因此，處理10萬個流需要大約4000個計數器和大約100個儲存單元的流記憶體；而處理100萬個流僅僅需要大約5000個計數器和相同大小的流儲存器。這僅僅是一個對數級別的增長速度。另外，在資料包到達時，每個雜湊層會做一次讀取和一次寫入。如果雜湊層足夠少，即使在高速情況下，這種訪問次數是可以負擔得起的——因為雜湊層的訪問可以並行執行。
6.3 減少處理量
到目前為止，我們已經在資料包計數方面做出了儲存開銷的最佳化。但是，除了單純的計數以外，我們還需要對資料包中的日誌資訊進行處理分析——資料包日誌有助於分析人員對網路執行模式和受到的網路攻擊進行回顧性分析。
在網路中，有一些通用的流量測量分析系統，如Cisco的NetFlow技術，在極細粒度下（對於資料流的粒度，每個流由單獨的一條TCP或UDP連線標識），它可以分析並報告每個流記錄。但要注意的是，儲存資料包日誌所需的大量記憶體需要使用DRAM來實現（流記憶體，並非計數器的儲存結構）——顯然，如果在每次資料包到達時寫入DRAM，這個寫入速度對於傳輸鏈路的高速率來說是不可行的，就像對於計數器不能單純使用DRAM計數一樣。由此，最基礎的NetFlow技術面臨著兩個問題：
- 處理流資訊開銷上：更新DRAM會降低轉發速率。
- 收集報告資訊開銷上：NetFlow生成的資料量太大，可能超過收集伺服器或其網路連線的處理能力。基礎NetFlow技術的資訊丟失率甚至可以高達90%。
兩個問題都與處理量過大密切相關。所以為了減少處理量，Cisco建議在使用NetFlow技術時，需要搭配取樣技術去使用。
6.3.1 取樣技術
我們先來直觀地感受一下NetFlow中取樣技術帶來的好處：
上圖為對資料包進行流取樣的過程。如圖，應用了取樣技術後，只有取樣的資料包才會更新DRAM流快取。例如，對16個資料包中的I或1000個資料包的1個進行取樣，這是被允許而且是較為常見的。取樣的優點在於，如每16個資料包到達時，DRAM最多寫入1個資料包，這使得DRAM的訪問時間可以比資料包到達時間慢16倍。但要注意的是，抽樣在估計中引入了相當大的不準確性，不過對於長時間的測量（誤差平均值）以及應用程式不需要精確的資料，這種不準確性無關緊要。
下面我們來系統地闡述取樣技術。
我們之前進行流測量的方式，是對所有的資料包都進行處理和記錄然後根據後設資料生成流記錄。但是，處理和記錄每個資料包會佔用大量的計算和儲存資源，從而影響網路效能並增加成本。特別是在高速網路環境下，需要處理可能非常巨大，這使得準確測量和分析網路流量的代價變得非常高昂。所以我們引入了取樣技術。
取樣技術在生成資料流記錄之前就對資料包進行取樣。它首先透過隨機取樣（1-out-of-n）的方式對資料包取樣，然後再基於取樣的資料包構建流記錄。這樣可以有效減輕網路測量的計算和儲存開銷，避免在另外n-1個資料包上產生額外的計算和儲存開銷，同時避免為許多小型的資料流建立流記錄，從而提高記錄效率並降低儲存成本。
當前的取樣技術有幾種比較先進的處理方式：
不維護流狀態
在裝置不維護任何流狀態的情況下，對流的隨機子集中的資料包進行取樣。
在此前的處理中，我們需要用計數器將流分別劃分出來，再將流資料送到流記憶體中進行處理。我們可以對此做最佳化：在裝置中不維護任何流狀態，即丟棄流計數的步驟，直接對資料包進行流劃分後取樣。為了實現這一過程，可以對每個資料包的五元組（源IP地址、目標IP地址、協議型別、源埠、目標埠）進行雜湊處理，並對雜湊結果符合某種條件的資料包進行抽樣。這樣可以達到在不維護流狀態的情況下，對隨機一部分流量取樣的目的（相當於假定了符合某種條件的資料包屬於同一個流）。
軌跡取樣 Trajectory Sampling
軌跡取樣可以確保資料包在多跳路由器之間得到一致的取樣處理。
在取樣過程中，對多個路由器來說，即使經過它們的流是一樣的，但對流的取樣卻是相互獨立不受影響的——這會導致路由器之前的取樣結果有差異！如果我們有對路徑效應分析的需求，那麼這種差異是不能接受的。管理人員可以使用軌跡取樣來檢視路徑效應，例如資料包迴圈、資料包丟失和多個最短路徑，這些效應可能無法使用普通取樣的NetFlow進行區分。
所以我們引入了軌跡取樣技術。軌跡取樣的主要思想是讓資料流路徑上的路由器使用一個公共的雜湊函式做出相關的包取樣決策。上圖顯示了進入路由器線卡的資料包的處理過程。對於每個資料包，都使用一個雜湊函式h，透過將資料包的雜湊值與指定的範圍進行比較，來決定是否對資料包進行取樣。如果對包進行取樣，則使用包上的第二個雜湊函式g再次雜湊，並進行日誌儲存。
軌跡取樣有兩個要注意的地方：
- 如何確保路由器使用相同的雜湊函式？
- 資料包裡面的內容在傳輸過程中是會變化的，如何確保雜湊函式的輸入相同？
對第一個問題，我們可以讓管理人員去配置路由器，以確保路由器使用相同的g和h雜湊函式；對第二個問題，對於要進行雜湊的資料包頭部欄位，我們只選擇傳輸過程中不變的欄位來計算雜湊值。例如，可以選擇使用五元組（源IP地址、目的IP地址、協議型別、源埠和目標埠）與IP識別符號或者五元組加上TCP標誌作為雜湊函式的輸入。
軌跡取樣和NetFlow正常取樣有兩個差異：
- 使用雜湊函式而不是隨機數來決定何時對資料包進行取樣；
- 對不變的資料包內容使用第二個雜湊函式，可以更緊湊地表示資料包頭部資訊。
布隆過濾器（Bloom Filter）
我們可以只抽樣每個資料流的第一個資料包進行分析，而不對整個資料流進行分析。
使用Bloom Filter是一種實現這種資料取樣技術的方法。Bloom Filter是一種基於雜湊函式的快速、空間效率高的資料結構，用於判斷某個元素是否存在於一個集合中。它使用位陣列（BitSet）標記某個元素是否出現過，而不需要儲存元素本身。
具體地說，Bloom Filter包括一個位陣列和多個雜湊函式。將要檢查是否存在的元素透過多個雜湊函式分別對映到位陣列的不同位置上，並將對應的位設定為1。當檢查新元素是否存在時，將該元素經過相同的雜湊函式計算得到的位進行比較，若所有位均為1，則認為該元素存在於集合中，否則認為不存在。雜湊函式的設計可以使誤判率控制在可接受範圍內。
Bloom Filter的設計原理與上文閾值聚合中並行雜湊層的思想類似。如上圖，假設一個Bloom Filter中有三個雜湊函式\(h1\)，\(h2\)，\(h3\)，那麼它會將輸入的值，如x，計算得到\(h1(x)=1\)，\(h2(x)=4\)，\(h3(x)=9\)，然後將BitSet的1，4，9位設定為1——這樣就將輸入值x對映到BitSet中的3個二進位制位了。之後檢查x是否已被記錄只需要計算出對應的二進位制位並檢查是否全為1即可。要注意的是，當輸入值計算得到的二進位制位全為1時，實際上是不能100%的肯定該輸入值已被Bloom Filter記錄過的，因為有可能該輸入值的所有位都剛好是被其他輸入值設定為1）這種將劃分錯誤的情況，稱為誤判（wrong position）。計算誤判率的公式為：
其中插入Bloom Filter中的元素數目為n，BitSet位數為m，雜湊函式的數目為k。從上式可以看出，當BitSet位數m增大或插入Bloom Filter中的元素數目n減小時，均可以使得誤判率P下降。
在這種情況下，我們可以將正在傳輸的所有資料流的ID儲存在Bloom Filter中。然後，當接收到新的資料包時，我們可以使用Bloom Filter檢視該資料包所屬的資料流是否已經被分析過，如果已經被分析過，則將其丟棄；否則，將其作為該資料流的第一個資料包進行分析。這樣可以減少需要分析的資料包數量，從而提高網路流量分析的效率。
7 協同方案
本節要解決的具體問題有關協同方案（concerted schemes）。例如，ISP希望收集客戶傳送的流量統計資訊，並根據流量型別和目的地向客戶收費，一方面，這需要解決如何將Accounting正確進行的問題，另一方面，解決方案執行的開銷要在可承受範圍內。要想在整個網路中進行這般操作，就需要一個全面的協同的方案。
前文在講述取樣技術的過程中，我們從只需要單個本地路由器支援的單點方案轉向了軌跡取樣這樣的協同方案——這要求多個路由器的合作來提取更多有用的資訊。協同方案可以在不同的時間尺度（例如，路由計算，轉發）上涉及網路系統的所有方面（例如，協議，路由器）。
我們接下來將看到兩個使用協同方案的示例，分別為 Juniper networks 提出的DCU Accounting方案，以及協同思想進行流量矩陣計算。
7.1 Destination Class Usage
我們先來看一個單點Accounting帶來的反面例子：
如圖為一個小型的 ISP 網路，假設ISP Z希望以一個價格a向客戶A收取透過ISP X流出的所有流量的費用，並以另一個價格b向客戶A收取透過ISP Y流出的所有流量的費用。這樣的話，一種最笨的解決方案是讓 路由器R1 為傳送到每個字首的流量維護一個單獨的計數器。在圖中，R1至少需要維護10,000+20,000 = 30000個字首計數器！這不僅使實現更加複雜，而且也與使用者需求不符，因為使用者最終將這30000個字首聚合成僅僅兩個資費類別。此外，如果路由變化頻繁，每個ISP的字首數量可能會快速變化而丟失，這就需要不斷更新用於對映的Controller。
Juniper Networks公司給出了一個漂亮的協同計費方案：DCU計費（destination class usage，目標類使用 ） ！
“DCU 透過執行 IP 目標地址查詢來對來自客戶的資料包進行計數，並且可以跟蹤來自客戶邊緣且發往提供商核心路由器上特定字首的流量。”
DCU由兩個部分組成，分別為硬體實現和協議制定：
-
使用類計數器（Class Counters）。Class Counters是網路路由器中的一種計數器，用於記錄每個流包含的資料包數量。在路由器的轉發表中，每個條目都有一個16位的類ID，每個類ID中的1個bit表示一個類別。當資料包傳輸時，如果它與某個字首匹配，並且具有關聯的類ID，則與該類別對應的位的計數器會遞增。
類計數器支援最多16個不同的類別，但單個資料包可以導致多個類計數器的遞增。因此，這種方法能夠更精確地記錄每個流量的使用情況。同時，該解決方案也符合硬體設計實際情況，因為16個計數器與一個計數器相比並沒有顯著增加處理難度，並且可以在晶片上維護這些計數器以實現並行遞增，從而提高效率。這種計數器通常被用於ISP等場景中，用於實現更精細化的計費策略和QoS（服務質量）控制。
-
路由支援（Routing Support）：為了解決字首變動的問題（這會導致Controller不斷將每個字首對映到不同的類中），DCU方案藉助路由協議來解決。其想法是，來自ISP X的所有字首都被賦予一種顏色（可以使用簡單的路由策略過濾器進行控制），而來自ISP Y的字首則被賦予另一種顏色。因此，當像上圖R1這樣的路由器收到帶有顏色c的字首P的路由資訊時，它會自動將字首P對映到類c中。這個路由協議上的小改變可以極大地減少Controller的工作量。
Juniper Networks還有其他方案，包括使用基於分組分類器的計數器和基於MPLS隧道的計數器。這些方案比DCU計費稍微靈活一些，因為它們可以在確定資料包的類時考慮資料包的源地址。但是這些方案因為缺乏路由支援，所以不具備DCU計費的管理擴充套件性。
7.2 計算流量矩陣
雖然DCU解決方案僅對Accounting有用，但它的一些基本思想可以幫助解決流量矩陣問題。流量矩陣問題是許多網際網路服務提供商非常感興趣的問題。
7.2.1 流量矩陣的意義
流量矩陣（Traffic Matrix）是指在網路中各個節點之間的流量量化資訊。它記錄了從源節點到目標節點的流量量級或流量比例。流量矩陣可以根據不同的時間尺度（從幾小時到幾個月）進行測量和分析。
我們繼續利用 7.1 圖中的ISP網路來介紹，來自ISP Z中的路由器的一些鏈路會到達屬於其他ISP (如E2, E3)或客戶(如E1, E4, E5)的路由器，我們稱這種聯絡為external links；指向從外部指向ISP內部路由器的external links稱為input links，而從ISP指向外部路由器的external links稱為output links。
流量矩陣列舉了網路中每對input和output links之間傳送的流量(在某個任意時間段，例如一整天)。例如，在 7.1 圖中，流量矩陣可以告訴ISP Z的管理者，custom A 白天有60mbps的流量input，其中有20mbps作為output通往 ISP X 的peer-link E2上，剩餘的40mbps由link E5作為output通往custom B。
對於網路運營商來說，流量矩陣是必不可少的。它們可用於：
- 做出更優的路由決策：透過分析流量矩陣，ISP可以瞭解當前網路中的流量分佈情況，並根據需要調整路由設定，例如可以透過改變OSPF權重或建立MPLS隧道來解決次優路由問題)；
- 用於瞭解何時建立
circuit switch，以用於避免hot spot產生（為hot spot流量分配專用的物理路徑，避免與其他流量競爭網路資源，使得hot spot流量可以在專用路徑上獨立傳輸） - 用於網路診斷，瞭解網路堵塞的原因；
- 以及用於網路規劃（瞭解不同鏈路的負載情況，從而決定是否需要升級或調整特定鏈路的頻寬或容量，以滿足未來的流量需求)。
流量矩陣很好！但是現在存在一個問題：傳統路由器只提供單個聚合計數器（即 SNMP link byte counter），而從聚合計數器獲得的值去推斷流量矩陣是有大問題的。
為什麼 SNMP link byte counter 不能用來推斷流量矩陣？
聚合計數器： SNMP link byte counter 提供的是對整個鏈路上所有流量的聚合計數（位元組流量的總數）。它無法提供對特定流量對（例如源IP地址和目標IP地址）的細分計數。
稀疏網路：許多網路都是稀疏的，即只有少數幾個external link。在這種情況下， SNMP link byte counter 的數量可能與連結數量（即已知量數量）相當。缺乏足夠的計數器使得推斷流量矩陣變得更加困難。
變數數量：流量矩陣中可能存在大量的 input/output link pair，而 SNMP link byte counter 的數量相對較少。在已知流量路由的情況下，我們會產生O(V)個方程和O(V^2)個變數，其中V是external link的數量。這樣的方程數量不足以解決所有的變數。例如假設有3個external link，T_xy為由E_x到E_y的流量，方程右側為external link 流量計數值：
\[T_{12}+T_{13}+T_{21}+T_{31}= Traffic\ \ E1\\ T_{21}+T_{23}+T_{12}+T_{32}= Traffic\ \ E2\\ T_{31}+T_{32}+T_{13}+T_{32}= Traffic\ \ E3 \]明顯該方程無法求解。
對於存在的流量矩陣推斷難題，我們接下來將介紹三種協同方案。
7.2.2 網路層析
Internet tomography（網際網路層析成像）是一種利用從端點資料中獲取的資訊來研究網路內部特徵的方法。它類似於醫學中的CT（計算機斷層掃描）技術，旨在透過檢查來自"邊緣節點"（即資料的起源和請求節點）的資訊來繪製資料在網際網路中的路徑，方法核心在於多資訊源和統計推斷。
在推斷流量矩陣時，由於SNMP計數器的特性導致不可能進行確定性的推斷，所以需要採用統計推斷的方法（儘管存在一定的誤差）。Internet tomography利用統計學和機率模型來推斷流量矩陣中的未知變數，它基於多處協同觀察到的資料和一些假設的流量分佈模型（如 Gaussian Distribution 高斯分佈， 或 Gravity Model 重力模型），使用統計學原理（如maximum likelihood，最大似然估計）或最佳化技術（如quadratic programming，二次規劃）來推斷流量矩陣中的變數值。
Internet tomography 的最大優點是它不需要改造現有的路由器（它透過在網路中部署測量裝置，如探針，來觀察流量資料，而不需要對路由器進行任何修改或新增額外的硬體），而且在路由器中實施成本較低（利用現有裝置，無需額外測量節點）。
這種方法的缺點在於：
- 推斷結果的潛在誤差：誤差可能高達20%！見Robust Traffic Matrix Estimation with Imperfect Information: Making Use of Multiple Data Sources）
- 對路由錯誤的敏感性：如果存在單個鏈路故障或路由錯誤，推斷結果可能會出現50%的偏差（如一個鏈路斷開而沒有被發現，明面上拓撲結構照舊）
- 對網路拓撲的敏感性：網路拓撲的變化或結構的複雜性可能導致推斷結果的不準確性。
7.2.3 per-prefix 計數器
前文中介紹的DCU計費方案其實可以算是一個用來解決流量矩陣問題的基於路由器實現和路由協議變化的系統解決方案，DCU體現了現代路由器的設計思想。而這節內容延續這種協同工作思想，繼續介紹一種用於流量矩陣計算的路由器計數器設計——per-prefix計數器。
在使用per-prefix計數器的方案中，每個輸入line card都有一個轉發引擎（forwarding engine），其中包含轉發字首表的副本。假設轉發字首表中的每個字首 P 都有一個關聯的計數器，那麼每個字首與 P 匹配的資料包在進入line card時，都會使計數器增加相應的位元組數。最後，透過彙總 input link 尾端路由器中的per-prefix計數器，就可以構建流量矩陣。為了實現這一點，該方法必須有一定的關鍵資訊支援：包括路由協議（如OSPF）計算的路由資訊和字首路由與 output link 之間的對映關係。
我們來舉一個例子：在7.1的圖中，如果R1在來自鏈路E1的流量上使用per-prefix計數器，那麼就可以對來自ISP X的10,000個字首對應的計數器求和，從而找到Customer A和ISP X之間的流量關係。
這種方案的一個優點是它提供了堪稱完美的流量矩陣！第二個優點是它可以用於像DCU那樣的基於目的地址的差異性流量計費。但也存在兩個缺點：一方面是在實施上維護 per-prefix計數器 的複雜性。傳統路由器中缺乏這樣的設計，支援這種方案意味著需要對傳統路由器進行改進或引入新的路由器實現。另一方面，由於協同工作，需要從每個路由器收集和合成大量資料以形成流量矩陣，這可能需要大量的頻寬和儲存資源，並且需要高效的資料處理和分析演算法來處理這些大規模的資料集。
7.2.4 類計數器
class counter（類計數器）在我們介紹DCU章節中已經有所提及，這節我們繼續介紹它在流量矩陣計算中的使用。
我們可以將每個字首透過轉發表對映到一個小的類別ID，該ID通常為8至14位（256至16,384個類別）。當一個輸入資料包與字首P匹配時，P的轉發條目將資料包對映到一個類計數器，並對該計數器進行遞增操作。對於多達10,000個計數器，類別計數器可以輕鬆儲存在轉發ASIC的片上SRAM中，從而允許在內部並行進行遞增操作和其他功能。
在前文的DCU Accounting中，DCU建議路由器使用策略過濾器按計費類別為路由進行分類著色，並使用路由協議傳遞這些顏色分類資訊，這些分類資訊可以用來在每個路由器上自動設定類別id。對於流量矩陣計算，可以使用類似的思想，根據矩陣等價類對路由進行著色。
矩陣等價類：所有源自同一 external link 或網路的字首都屬於同一個類別。
那麼原理知道了，類計數器是怎樣使用在流量矩陣計算中的呢？
我們知道，許多ISP在主要城市設有PoP，這就需要計算聚合的PoP到PoP流量矩陣。透過將不同的PoP分配到不同的類別中，可以直接依靠類別計數器來計算和分析PoP到PoP之間的流量矩陣，這樣可以更加方便地獲取和處理與特定PoP相關的流量資訊，而無需對完整的 路由器--路由器矩陣 進行聚合。例如，在7.1圖中，R4和R5可能屬於同一個PoP，那麼E4和E5就可以被對映到同一個類別中。
根據2003年的測量資料，類別計數器的數量大大減少——使用150個計數器就足以處理最大的ISP的情況。這意味著透過合理的分類和計數器使用，可以在保證高效效能的前提下，減少需要處理的計數器數量，從而降低了系統的複雜性和資源消耗。
8 被動測量的例子：Sting
到目前為止，前文都專注於涉及對路由器實現（如計數器）和其他子系統（如路由協議）進行更改的路由器測量問題。但是這類方案需要多個路由器供應商進行合作，由於更改需要與現有的網路裝置和協議進行相容，所以使用這類方案會面臨著逐步部署的困難。與之相比，被動測量側重於透過 “欺騙網路” 來獲得有用的測量資料，而無需改變網路內部結構。被動測量的基本思想是克服網際網路協議套件所提供的測量支援的缺乏。
假設你不再是一個ISP，而是某個公司的網路管理員。一家新興的 ISP 聲稱可以提供比你現在使用的 ISP 更好的服務。那麼你肯定想測試一番來驗證他們說的真假！為了驗證，你將輪流使用兩個 ISP ，從你的站點到全國各地的各種Web伺服器進行端到端的效能測量。
標準解決方案是使用基於傳送ICMP訊息的Ping和Traceroute等工具。但是這些工具存在一個問題：ISP 經常過濾或限制此類訊息（你可以自己試試看，ISP 會隱藏它們的路由節點，避免你搞到它們的網路拓撲）。為了克服這個限制，Stefan Savage發明的Sting 工具提出了一個繞過這個限制的想法：
將測量資料包偽裝成TCP資料包，網際網路服務提供商和Web伺服器無法丟棄或限制此類資料包（因為在它們眼裡這不屬於垃圾資料）——這意味著透過利用TCP協議的各種機制，Sting工具能夠提供更多的測量自由度。
我們先來看如何確定源和遠端Web伺服器之間丟包機率。
確定丟包機率有助於瞭解大多數流量在網路上是不是僅僅為單向傳輸。對於Ping工具，即使Ping沒有受到速率限制，它也只是提供了雙向丟包機率的綜合資訊。而Sting工具提出了一種從源到遠端Web伺服器確定丟包機率的演算法：
data seeding階段：首先透過與伺服器建立正常的TCP連線，並按順序向伺服器傳送N個資料包。此階段忽略了Acknoledgement，因為我們關注的是測量，而不是資料傳輸；hole filling階段：接下來，傳送一個帶有比data seeding階段中最後一個傳送的資料包序列號大1的資料包。如果收到Acknoledgement，說明一切正常，沒有丟失任何資料包。如果沒有，在進行足夠的重傳之後，接收方會回覆已經按順序接收到的最大序列號X。傳送方現在只傳送與 X+1 相對應的段。最終，接收方會傳送一個更新的Acknoledgement，其中包含下一個按順序接收到的最大序列號。接收方會填充下一個"hole"，並繼續進行，直到填充完所有的"hole"。在第二階段結束時，傳送方準確地知道在第一階段中丟失了哪些資料包，並可以計算出丟包率。
計算反向丟包率更加具有挑戰性，因為接收方的TCP可能會將確認資訊批次傳送，而不是對每個資料包進行單獨的確認。然而由於Sting工具並不遵守真正意義上的TCP連線，那麼就可以透過改變工具的行為來欺騙接收方：Sting在第一階段傳送亂序的資料包，而不是按順序傳送，以引誘接收方提供更準確的確認資訊。透過這種方式，Sting能夠繞過接收方TCP的批次確認機制，獲得所需的資訊以計算反向丟包率。
（這聽起來和hacker做的事情沒有什麼區別……但這就是Sting的思想所在，"Stop thinking of a protocol as a protocol"！）