實作與實驗數據

在這個章節我們實作了一系列的實驗來證明此架構的可行性以及詳細執行時間，包含產生 root hash、Merkle tree 的時間和各種步驟所需要花的時間。

首先我們看到我們實驗所使用的三個不同的帳戶，如表三.1 所示分別是(1) 帳 戶 A，屬於檔案數目以及容量小的範例，(2) 帳戶 B 為檔案數目眾多，但是每個檔案容量皆不大，(3) 帳戶 C 為實際使用 20 年的一個資料夾，所以有參考價值。

表三.1：實驗數據中的三個範例帳戶

帳戶 A 帳戶 B 帳戶 C

Number of files

44 22968 28404

Number of folders

6 188 1718

Total size

666 MB 32.9 MB 6.9 GB

表三.2：從未 hash 過的檔案所產生 root hash 所需的時間(單位:秒) 帳戶 A 3.208 帳戶 A 15.744

帳戶 B 8.893 帳戶 B 875.211 帳戶 C 120.003 帳戶 C 978.889

(A) PC (B) Hadoop system

表三.3：直接從檔案的雜湊值產生 root hash 所需的時間(單位:秒) 帳戶 A 0.023 帳戶 A 1.823

帳戶 B 3.874 帳戶 B 198.572 帳戶 C 32.423 帳戶 C 347.568

(A) PC (B) Hadoop system

接下來的實驗我們在兩個平台上面實作：(1) Windows 7 電腦 (2) Hadoop 系統[17]，而檔案都是自動複製以及分散到 Hadoop 系統之中。其中(1) Windows7 電腦規格 CPU 為 3.1GHz Intel Core i5 2400 四核心，6GB 的記憶體，500GB 的硬碟空間。(2) Hadoop cluster 規格為由五台 PC、五個節點組成。每個節點都有

3.0GHz Intel Core 2 Quad processor 的 CPU、2 GB 的記憶體、500 GB 的硬碟空間、Ubuntu 10.04 LTS 的作業系統以及 Java Development Kit 6。

表三.2 為第一次帳號開啟時，所有的檔案都還沒有算過雜湊值，所以必需 要生成所有檔案雜湊值並計算出 root hash 的時間。若是使用者一次上傳許多檔案，服務商更可以先個別計算該檔案的雜湊值，再一起計算 root hash，這樣即可大幅降低計算的時間。Hadoop 系統則因為需要備份檔案到多台電腦，所以時間才會比較慢。

而表三.3 則為之後資料夾裡已經有了各個檔案的雜湊值後，直接從檔案的 雜湊質產生 root hash 的時間，可看到計算 root hash 的時間大幅降低，例如在帳戶 C 這麼多個檔案之中，節省了約四分之一的時間。

接著我們測量產生完整 Merkle tree XML 檔案¹ 所需的時間，一樣是在 PC 以及 Hadoop 系統上面實作，時間如表三.4 所示，因為每個檔案的雜湊值已經 有產生了，所以可以看到在這麼多檔案的資料夾中產生 Merkle tree 的 XML 檔案格式的時間並不長。

接著表三.5 為產生出完整 Merkle tree 的容量大小，皆只有 MB 單位的容量，

以現在每個人的手持裝置來說，這樣的負擔其實並不大，更何況我們提出 pMT 再減輕用戶的負擔。

表三.6 是從 Merkle tree 計算出 root hash 的時間，皆在一秒之內完成，這對 用戶的負擔也是很少。

表三.7 則是根據帳戶 C 隨著隨機更改檔案的數量，所生成的 partial Merkle

tree 的容量大小，由這成長曲線顯示節省的空間在經常更動的檔案不超過 100 個 的話是非常可觀的。最後表三.8 則以表格方式呈現表三.7，也就是說如果更動 10 個檔案，則最多會有 10 個 pMT 所組合而成的 pMT。

Merkle Tree 實作 XML 格式請參考附錄裡的

圖 A.1

表三.4：產生 Merkle tree XML 檔案的時間(單位:秒) 帳戶 A 0.039 帳戶 A 0.798 帳戶 B 2.037 帳戶 B 289.415 帳戶 C 4.414 帳戶 C 312.549

(A) PC (B)Hadoop cluster

表三.5：Merkle tree 產生的容量大小 帳戶 A 3.2 kB

帳戶 B 2.96 MB 帳戶 C 3.4 MB

表三.6：由 Merkle tree 產生 root hash 的時間(單位：秒) 帳戶 A 0.071

帳戶 B 0.841 帳戶 C 0.985

表三.7：以帳戶 C 為例根據經常更改的檔案數量，所生成的 Merkle tree 的容量

表三.8：根據表三.7，以表格方式呈現

隨機選取檔案數量 1 10 100 200 300 400 500 1000

Partial Merkle tree 平均大小

(單位 MB)

0.002 0.05 0.438 0.871 1.398 1.676 2.04 2.98

接下來為”部分 Merkle tree”相關實驗數據，分為四個部分討論，(1)讀取檔案有 hit(2)寫入檔案有 hit (3)沒有 hit 時，稽核伺服器傳過來的 pMT 檔案大小 (4) 根據稽核伺服器傳過來的 pMT，更新本地 pMT，並重新計算出 root hash 的時間。

0 0.5 1 1.5 2 2.5 3 3.5 4

1 10 100 1000

部分的Merkle大小(單位：MB)

部分Merkle tree大小完整的Merkle大小

首先第一部分，在讀取檔案過程中，檔案有在本地 Merkle tree 中，則向服務商提出讀取檔案請求，服務商收到後，將檔案傳回給用戶，用戶只要將傳回來的檔案雜湊後的值，比對儲存的 Merkle tree 裡的該檔案是否為相同，即可知道 此檔案是否為最新。其實驗數據為表三.9 所示，隨機找尋 1000 次以存成 JAVA 物件的 Merkle tree 裡面所記錄的檔案的雜湊值，並分為最差、平均以及最好的時間呈現，可以看到時間都可在一秒之內即可完成。

表三.9：讀取檔案如果 hit，則由本地 pMT 找到該檔案的 hash 時間(單位：秒)

worst average best 0.05 0.04 0.03

(A) 帳戶 A

worst average best 0.61 0.28 0.09

(B) 帳戶 B

worst average best 0.75 0.42 0.15

第二、討論儲存檔案時，如果檔案有在本地 pMT 中，則向服務商提出儲存請求，服務商將檔案寫入後，重新計算 root hash 並傳回給用戶，用戶也將該檔案的雜湊值更新本地 pMT，並重新計算 root hash，如果與服務商傳回一致，則驗 證程序結束。其數據如表三.10 所示，欲寫入的檔案數目為 1 個、10 個、100 個到 1000 個檔案時，分別跑了 100 次數據，最多需花多少時間，最少需花多少時間，並且在這 100 次平均為多少時間。

表三.10：儲存如果 hit，找到檔案位置後更新 Merkle tree，接著重新計算 root hash 的時間(單位:秒)

更改檔案數量

worst average best

1 file 0.058 0.034 0.029 10 files 0.287 0.223 0.187

(A) 帳戶 A

更改檔案數量

worst average best

1 file 0.874 0.584 0.358 10 files 5.784 3.158 1.181 100 files 9.184 5.97 3.539 1000 files 31.598 28.514 26.158

(B) 帳戶 B

更改檔案數量

worst average best

1 file 0.977 0.758 0.498 10 files 7.954 4.811 1.797 100 files 11.399 7.121 4.872 1000 files 33.587 32.897 31.154

第三，討論如果讀取檔案，而此檔案沒有記錄在用戶本地的 pMT 之中，稽核 伺服器傳過來的給用戶更新的部份的 Merkle tree 的大小，表三.11 呈現實作的數 據，為三個帳戶分別以更改的檔案數目 1 個、10 個、100 個到 1000 個檔案時，

分別跑了 100 次數據，最大以及最少會到多少容量，並且在這 100 次平均為多少容量。

表三.11：讀取如果沒有 hit，則從稽核伺服器傳過來更新的 pMT 大小

更改檔案數量 worst average best

1 file 0.64 0.192 0.32 10 file 3.2 1.87 1.1

(A) 用戶 A(單位: KB)

更改檔案數量 worst average best

1 file 1.93 0.161 0.064 10 files 2.01 0.87 0.131 100 files 2.12 1.32 0.99 1000 files 2.96 2.57 2.34

(B) 用戶 B(單位:MB)

更改檔案數量 worst average best

1 file 1.38 0.501 0.299 10 files 2.32 0.987 0.482 100 files 2.67 1.98 1.5 1000 files 3.1 2.98 2.78

第四、在知道傳過來的部分 Merkle tree 大小後，並更新 pMT 後，就要根據

Merkle tree 重新計算 root hash，而表三.12 即根據 pMT 的大小，重新計算 root hash 的成長曲線的數據。

表三.12：寫入如果沒有 hit，更新 pMT 後，重新計算 root hash 所需花的時間

0 0.2 0.4 0.6 0.8 1 1.2

1 KB 10 KB 100KB 1000 KB

時間(單位:sec)

帳戶 A 帳戶 B 帳戶 C

接下來我們設計了一系列完整的實驗以及比較。第一、最一般的檔案傳輸，

也就是並未加入任何稽核的架構，讓用戶隨機存取帳戶 C1000 次檔案以做為比 較。實驗數據結果如表三.13。

表三.13：以帳戶 C 為例，在沒有任何稽核機制下的檔案傳輸時間(單位：秒)

檔案大小讀取寫入

1~100K 0.012 0.016

100K~1MB 0.047 0.049

1MB~5MB 0.133 0.154

5MB~10MB 0.216 0.223

第二、根據我們的即時稽核架構，也就是圖二.1，實作同步伺服器、用戶以及服務商程式，三者之間使用 socket 網路協定溝通，並用 semaphore 鎖住用戶，讓同一時間只會有一個用戶到同步伺服器拿取證據以及 root hash，並隨機讀取以及寫入檔案，根據架構流程更新狀態以及串起證據，驗證檔案是否正確，最後將 root hash 以及證據放回同步伺服器，並解開 semaphore 後，讓下一個用戶可以繼續操作。

我們分成兩個部分，單一用戶以及三個用戶個別隨機存取帳戶 C 1000 次檔

案並分別根據檔案的大小來列出完成整個流程所需的時間，如果是單一用戶，則不需要同步伺服器做驗證，因為用戶手上握有的永遠都是最後的證據以及 root hash，並跟多個用戶的加上同步伺服器的機制下做比較。其實驗數據分別為表 三.14 以及表三.15。我們可以看到在表三.14 單一用戶數據中，在讀取以及

Merkle tree 有 hit 的情況下，在加了即時稽核機制後大約只增加 0.4~0.6 秒的延遲，

即使 miss 後需向稽核伺服器下載部分的 Merkle tree 與用戶持有的 Merkle tree 合併，也只再多花約 0.3~0.4 秒合併。在寫入方面，因為需要更改 Merkle tree 以及重新 root hash 的關係，與無任何稽核機制的寫入時間，大約增加了 0.9~1 秒的時 間。接著在表三.15 三個用戶的實驗與表三.14 不同為加了同步伺服器取得最後 的證據以及 root hash，可以看到與單一用戶的數據也只增加了約 0.3 秒的延遲時間。

表三.14：即時稽核完整流程時間(單一用戶)

操作

Merkle tree hit or miss

檔案大小時間

讀取 Hit

0~100K 0.417 100K~1MB 0.518 1MB~5MB 0.651 5MB~10MB 0.712

miss

0~100K 0.751 100K~1MB 0.922 1MB~5MB 1.098 5MB 以上 1.156

寫入

Hit

0~100K 0.921 100K~1MB 1.024 1MB~5MB 1.239 5MB~10MB 1.367

Miss

0~100K 1.239 100K~1MB 1.359 1MB~5MB 1.601 5MB 以上 1.721

表三.15：即時稽核完整流程時間(三個用戶)

操作

Merkle tree hit or miss

接下來展示用戶儲存 partial Merkle tree 的優勢，根據我們即時稽核的步驟，

如果用戶是儲存完整的 Merkle tree，那麼在一開始時，用戶必須要下載完整的 Merkle tree 才能開始運作，而使用 Partial Merkle tree 的話，只需要下載部分 Merkle tree，以下為實驗比較，其中用戶 D 約 85200 個檔案，5130 個目錄，以及總共 21GB。相關實驗結果為表三.16。我們可以看到在 Partial Merkle tree 的時候，

檔案資料夾越大，因為樹高並不會明顯變高，所以平均時間並不會增加，但是若使用完整的 Merkle tree，隨著檔案數目越大，用戶下載的 Merkle tree 會越來越大，

啟動時間也會越來越長，由這樣的比較可以顯示 Partial Merkle tree 的優勢。

表三.16：用戶開始檔案操作後的啟動時間(單位：秒)

Scheme 最少時間最大時間平均時間帳戶 C Partial Merkle tree 0.034 0.053 0.045

Complete Merkle tree 0.681 0.752 0.701 帳戶 D Partial Merkle tree 0.034 0.055 0.046 Complete Merkle tree 3.428 3.617 3.478

1MB~5MB 2.067 5MB~10MB 2.209

在文檔中以部分雜湊樹達成有效率的雲端儲存系統即時稽核 (頁 26-41)

Number of files

Number of folders

Total size

Merkle Tree 實作 XML 格式請參考附錄裡的

隨機選取檔案數量 1 10 100 200 300 400 500 1000

Partial Merkle tree 平均大小

(單位 MB)

0.002 0.05 0.438 0.871 1.398 1.676 2.04 2.98

0 0.5 1 1.5 2 2.5 3 3.5 4

部分Merkle tree大小 完整的Merkle大小

worst average best

worst average best

worst average best

0 0.2 0.4 0.6 0.8 1 1.2

1 KB 10 KB 100KB 1000 KB

帳戶 A 帳戶 B 帳戶 C

部分Merkle tree大小完整的Merkle大小