5. 戳記成本改善機制
5.2 戳記壓縮
由於使用正常戳記方式的成本過高，因此本節介紹三種使用壓縮的方法，透過壓縮 技巧讓整體戳記大小下降，以達到減少成本的效用。我們同樣使用 1024 個節點的二維 網路模型、小世界網路、Waxman 網路模型和 BA 網路模型來分析各節點接收到訊息中 戳記所用的空間大小，這 1024 個節點使用的是上述由 Facebook 社群平台隨機取樣的 1024 個電子郵件地址來當作節點名稱。
經過廣播後，二維網狀模型中每個節點所收到的封包中戳記量累積圖與戳記大小累 積圖如圖 5-1及圖 5-2所示，我們可以發現使用進階戳記法和混合戳記法下由於要多紀 錄鄰居的戳記，因此戳記量比起基本戳記法來得多。基本戳記法下節點收到的戳記大小 較為集中，約在 300 Bytes至 700 Bytes間，從發送者端經過的層數約在 12 層到 36 層間，
而大多節點會收到 14 至 24 個戳記；進階戳記法的節點所收到的戳記大小分布範圍約在 800 Bytes至 2300 Bytes間，大多數接收節點所接收到的戳記數量約在 37 至 100 個之間；
混合戳記法則與進階戳記法則相同，大多數節點收到的戳記大小範圍也介於 800 Bytes 至 2300 Bytes間，接收節點所接收到的戳記數量分布也約在 37 至 100 個之間。
0%
20%
40%
60%
80%
100%
0 10 20 30 40 50 60 70 80 90 100
Number of Stamps
Ratio of Nodes
Basic Advanced Hybrid
圖 5-1 二維網狀模型中節點收到封包中戳記量之累積圖
0%
0 200 400 600 800 1000 1200 1400 1600 1800 2000 2200 Stamp Size (bytes)
Ratio of Nodes
Basic Advanced Hybrid
圖 5-2 二維網狀模型中節點收到戳記大小之累積圖
而小世界網路下每個節點所收到的封包中戳記量累積圖與戳記大小累積圖如圖 5-3及圖 5-4所示。大部分基本戳記法下節點收到的戳記大小較為集中，約在 200 Bytes 至 370 Bytes間，從發送者端經過的層數約在 10 層到 17 層之間，所以其他大多節點會
Number of Stamps
Ratio of Nodes
0 Basic Advanced Hybrid
圖 5-3 小世界網路中節點收到封包中戳記量之累積圖
0%
0 200 400 600 800 1000 1200 1400 1600 Stamp Size (bytes)
Ratio of Nodes
Basic 數量約在 37 個至 60 個間，而大小約略在 900 Bytes至 1200 Bytes。Waxman中的混合戳 記法廣播的路徑與進階戳記法類似，因此在戳記大小上非常相近，分布狀況則如圖 5-5
Number of Stamps
Ratio of Nodes
60 Basic
Advanced Hybrid
圖 5-5 Waxman網路模型中節點收到封包中戳記量之累積圖
0%
0 200 400 600 800 1000 1200
Stamp Size (bytes)
Ratio of Nodes
Basic Advanced Hybrid
圖 5-6 Waxman 網路模型中節點收到戳記大小之累積圖
圖 5-7和圖 5-8可以看出BA模型每個節點所收到的戳數量和戳記大小狀況，基本戳 記法在BA模型中更為集中且戳記整體大小很小，約在 100 Bytes下，由於發送者端至其 他接收節點經過的層數接不超過 4 層，所以封包內所記錄的戳記量也不超過 4 個；進階
Number of Stamps
Ratio of Nodes
Basic Advanced Hybrid
圖 5-7 BA網路模型中節點收到封包中戳記量之累積圖
0%
20%
40%
60%
80%
100%
0 500 1000 1500 2000 2500 3000
Stamp Size (bytes)
Ratio of Nodes
Basic Advanced Hybrid
圖 5-8 BA 網路模型中節點收到戳記大小之累積圖
5.2.1 分類法壓縮
在郵件地址中，郵件伺服器的重複率往往比使用者帳號來得高，因此只要將記錄加 以分組(Grouping)，就可以有一定幅度的改善。第一種方法就是利用分組的技巧，把戳 記記錄的使用者依不同郵件伺服器分組歸類，規格則如以下所示：
X-stamp: {User1, User2, ...}@Hostname1 {User1, User2, ...}@Hostname2
這樣一來查詢的時候只需要查找相同 Hostname 上的使用者紀錄即可，還可以省下 許多重複 Hostname 的空間。以先前的例子，設 n 個郵件地址中有 s 種不同的伺服器名 稱，則使用分組壓縮方法後需要耗掉 n* AL(user)+s*( AL(host)+3) Bytes。以實際取樣 1,024 個電子郵件來分組，可以找出 77 種不同的伺服器名稱，計算其需要的空間大小約 為 10.79 KB 左右，相對於基本的記錄方式來說，壓縮比約為 2.02 倍且查詢時間也從原 本 O(n)降為 (O n ) ，不僅降低了成本也加快查詢的速度。
5.2.2 雜湊法壓縮
除了利用Grouping的技巧去做壓縮之外，第二種選擇是使用常見的雜湊法(Hash)，
雜湊可以有效的壓縮資料量，查詢時間複雜度為O(n)，郵件地址也不會以明文顯示，故 還具有簡單的加密附加效果。如MD5[21]的Hash方法，我們可以將原本不定長度的字串 壓縮成 128 bits的二元碼，但壓縮郵件地址並不需要這麼多的位元來儲存，經過實驗測 試結果，我們僅需使用MD5 編碼之後 32 bits紀錄即可，並不會發生碰撞的情形。當然 也可以使用比 32 更少的bits來做紀錄，但碰撞的情形有可能會因此而發生。需要注意的 是在電子郵件傳送不能直接以位元轉換成ASCII碼，所以需轉換成Base64 編碼來做傳 送，因此 32 Bits會被編成 6 Bytes，對於整個郵件地址來做雜湊的話則所需要的空間大 小為 6n Bytes；而若是一般傳輸則僅需 4 Bytes，全部的郵件地址雜湊後也只需 4n Bytes。
以上述 1,024 個郵件地址為例，若用Base64 編碼則為 6 KB，壓縮比為 3.65 倍；若是一 般傳輸則為 4 KB，壓縮比變為 5.47 倍，比起分組法又降低約一半左右。
5.2.3 布隆過濾器壓縮
第三項選擇是使用布隆過濾器(Bloom filter)[5][7]，布隆過濾器是由k個雜湊函數組 成(Hash function)，在m位元大小的空間放入n個元素個數，這些元素會透過這k個雜湊函 數對應到布隆過濾器並將對應到的位元改成 1，直到將全部的元素都對應完為止。所以 伺服器在比對每個郵件位址時只要其中一個雜湊函數對應的位置是 0 的，就可代表此郵 件位址並不存在於戳記中。經過Base64 編碼後，同樣地，我們可以計算其壓縮後需要 的欄位大小為m/6 Bytes，假設建構一個大小為 10,000 bits的布隆過濾器，則壓縮後所需 的空間為 1.67 KB與先前的基本記錄方式比較，壓縮比為 13.88 倍；若使用在一般傳輸，
欄位大小則是m/8 Bytes，壓縮後之大小為 1.25 KB，壓縮比為 17.52 倍。除了壓縮性能 優越外，它還有可以在O(1)的時間內完成查詢動作的優點。
雖然布隆過濾器的壓縮比例比起其他的方法來得高了許多，不過它卻有個缺點，就 是會有一定機率發生False positive。所謂的False positive是指過濾器在判斷過濾的時候，
把不存在於此集合裡的元素，誤以為存在此集合中。舉個簡單的例子：建立一個 5 bit 的布隆過濾器只放入一個元素 8，透過二個除法雜湊函數h1(x)=x % 2 和h2(x)=x % 3 對應 至過濾器中，並將對應到的位址 0 和位址 2 由 0 設為 1。現在過濾器要判斷元素 14 是 不是在過濾器中，結果經過二個雜湊函數對應出來位址 0 和位址 2 剛好都為 1，因此過 濾器認為元素 14 存在於此過濾器中，但事實上過濾器中僅存一個元素 8，並沒有元素 14 的資料，這樣的誤判現象就稱為False positive。這個誤判機率p我們可以由[5]文中得 知為
1 0.6185 2 雜湊函數可以有最小的 False positive，而機率則為 0.0081921，也就是說會有 8.3 個地址 會被誤判。若想要有更低的誤判率，則要增加布隆過濾器的位元數，但壓縮比也會因此 而降低。
我們對蒐集來的 1024 個郵件地址做壓縮分析，將前文中所提到的三種方法與沒有 做壓縮的原始方法放在表 5-1一併做比較，以便清楚了解各種壓縮的效果。
表 5-1 三種壓縮比較
Compression ratio Cost
Simple case 1.00 21.90 KB
Grouping 2.02 10.79 KB
Hash (Base 64) 3.65 6.00 KB
Hash 5.47 4.00 KB
Bloom filter (Base 64) 13.88 1.67 KB Bloom filter 17.52 1.25 KB