在這個章節中我們實作了一系列的實驗來證明本論文提出架構的可行性以 及詳細的執行時間，包含建立 merkle tree、不同距離、不同數量的伺服器的各種 步驟所需要花費的時間。首先先介紹我們實驗所使用的三個不同的帳戶，如表格
1 所示分別是(1) 帳戶 A，屬於檔案數目小以及容量小的範例，(2) 帳戶 B 為檔 案數目很多，但是每一個檔案的容量都不大，(3) 帳戶 C 為實際使用了 20 年的 一個資料夾，因此具有參考價值。
總容量 檔案數量 資料夾數量
帳戶 A 777 MB 48 6
帳戶 B 145 MB 54198 188
帳戶 C 5.95 GB 45089 1459
表格 1 : 實驗使用的三個範例帳戶
接下來的實驗我們在兩個平台上面實作：(1) Linux Mint 17.3 系統，作為客 戶端的設備，(2) CentOS 6.6 系統，作為服務提供者端的伺服器。其中(1) Linux
Mint 17.3 系統規格 CPU 為 2.13GHz Intel Core i3-330M 雙核心，8GB 的記憶體，
120GB 的固態硬碟空間。(2) CentOS 6.6 系統規格 CPU 為 3.30GHz Intel Xeon
帳戶 A B C
時間 9.40653 55.14738 339.18192
表格 2 : 建立 merkle tree 所需的時間 (單位:秒)
表格 2 為第一次建立帳號時，所有的檔案都還沒有算過雜湊值，所以必須要 計算所有檔案的雜湊值並彙整出 root hash 的時間。
帳戶 A B C
時間 0.00333 2.70313 0.3342
表格 3 : 從已有檔案的雜湊值的資料建立 merkle tree 所需的時間 (單位:秒)
但在實際使用的環境中，服務提供者不需要等到所有的檔案上傳後才計算
merkle tree，服務提供者可以在收到檔案的同時計算出檔案的雜湊值，因此較符 合真實使用環境的建立 merkle tree 的時間應該是已經有檔案的雜湊值之後再計 算，如表格 3 所示，服務提供者在收到使用者所有檔案之後，可以在幾秒鐘的時 間就準備好 merkle tree，因此初始的時間不會影響系統的效能。檔案的大小不會 影響執行時間，因為帳戶 B 的檔案數量最多，因此這次帳戶 B 需要的時間最久。
A B C
merkle tree 占用容量 5.4 KB 5.08 MB 4.37 MB
表格 4 : merkle tree 占用的容量大小
接著表格 4 為產生完整 merkle tree 的容量大小，merkle tree 的容量大小由 檔案數量所決定，因此帳戶 B 仍然是最大的。而他只需要 5.08 MB 的 merkle tree 容量，這樣的容量並不會對客戶端的設備造成太大的負擔，而且在我們提出的方 法中客戶端的設備不需要一直保留 merkle tree ，只有在稽核計算時才會使用到，
其他的情況下不會占用客戶端設備的容量。
接下來我們的實驗分別有在同一個網路區段以及不同的網路區段兩個環境 下的實驗，不同的網路區段為使用者和服務提供者之間相距 16 個 Hop 距離的環 境 (由 Traceroute 程式計算)。我們列出讀取及寫入檔案的相關實驗數據，首先我 們先列出沒有加上任何 POV 技術、單純讀取及寫入檔案的執行時間，有了這個 基底的時間我們才能夠比較之後的兩種方法的優劣。
同一個網路區段 不同的網路區段
測試檔案大小 上傳時間 下載時間 上傳時間 下載時間
小於 10 KB
0.010608 0.007845 0.069273 0.056629
小於 100 KB
0.014393 0.013691 0.121093 0.087351
小於 1 MB
0.090440 0.088570 0.343584 0.225566
小於 10 MB
0.367989 0.354916 1.375616 0.699524
圖 4 : 在同一個網路區段中，沒有使用 POV 技術的執行時間 (單位:秒)
圖 5 : 在不同的網路區段中，沒有使用 POV 技術的執行時間 (單位:秒)
從 表格 5 和 圖 4 可以看到在同一個網路區段內，沒有使用 POV 技術上 傳下載檔案，在我們的實驗環境中所需要花費的時間，檔案越大當然執行的時間 越長。而上傳時間和下載時間非常接近。
而從 表格 5 和 圖 5 則可以看到在不同的網路區段中，沒有使用 POV 技 術上傳下載檔案所需要花費的時間。上傳的時間會比下載的時間稍微久一點，這 是由我們實驗環境的網路速度所決定，接下來的實驗都是在同一個環境，可以以 這個基準比較。
接下來我們先列出使用者和服務提供者在同一個網路區段中，這篇論文所提 出的方法以及 2014 Cloud Com [14] 提出的方法的執行時間。
這篇論文所提出的方法之執行結果如下 : 表格 6 和 圖 6 列出服務提供者 使用不同數量的伺服器，上傳一個檔案所需要使用的時間，而 表格 7 和 圖 7 則是下載一個檔案所需要使用的時間。這些數據都是使用者和服務提供者在同一 個網路區段內的執行時間，因此演算法的好壞影響最後的結果較大，檔案傳輸的
時間在這裡就不是主要的變數。
測試檔案大小 3 個伺服器 5 個伺服器 7 個伺服器 9 個伺服器
小於 10 KB 0.046139 0.067923 0.101676 0.108696
小於 100 KB 0.070739 0.083563 0.112895 0.145049 小於 1 MB 0.153822 0.166289 0.200053 0.203870
小於 10 MB 0.430937 0.513879 0.684666 0.694259
表格 6 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器
執行一次上傳的動作所花費的時間 (單位:秒)
圖 6 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器執
行一次上傳的動作所花費的時間 (單位:秒)
測試檔案大小 3 個伺服器 5 個伺服器 7 個伺服器 9 個伺服器
小於 10 KB 0.042295 0.054263 0.064370 0.078872
小於 100 KB 0.053583 0.055442 0.083961 0.097507 小於 1 MB 0.146021 0.159869 0.195817 0.202213
小於 10 MB 0.392072 0.476251 0.622665 0.625499
表格 7 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器
執行一次下載的動作所花費的時間 (單位:秒)
圖 7 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器執
行一次下載的動作所花費的時間 (單位:秒)
2014 Cloud Com 的方法之執行結果 : 表格 8 和 圖 8 列出使用者在執行
圖 8 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同數量的需要同步
長度，執行一次上傳的動作所花費的時間 (單位:秒)
測試檔案大小
同步長度
2
同步長度
10
同步長度
50
同步長度
100
同步長度
500 小於 10 KB 0.121268 0.249803 0.331339 0.515956 1.675274
小於 100 KB 0.134563 0.258717 0.338794 0.564519 1.796222 小於 1 MB 0.279563 0.302230 0.440841 0.588905 1.994046
小於 10 MB 0.462677 0.539638 0.595140 1.171150 2.241951
表格 9 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同數量的需要同
步長度，執行一次下載的動作所花費的時間 (單位:秒)
圖 9 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同數量的需要同步
長度，執行一次下載的動作所花費的時間 (單位:秒)
最後整理使用者和服務提供者在同一個網路區段中，將沒有使用 POV 的方 法、本篇論文提出的方法以及 2014 Cloud Com 的方法整理成圖 10 和圖 11 的比 較圖表。
圖 10 : 使用者和服務提供者在同一個網路區段中，比較以上三種方法，執行一次上傳的動作所
花費的時間 (單位:秒)
圖 11 : 使用者和服務提供者在同一個網路區段中，比較以上三種方法，執行一次下載的動作所
花費的時間 (單位:秒)
接下來我們先列出使用者和服務提供者在不同的網路區段中，這篇論文所提 出的方法以及 2014 Cloud Com [14] 提出的方法的執行時間。
這篇論文所提出的方法之執行結果如下 : 表格 10 和 圖 12 列出服務提供 者使用不同數量的伺服器，上傳一個檔案所需要使用的時間，而 表格 11 和 圖
13 則是下載一個檔案所需要使用的時間。這些數據都是使用者和服務提供者在 不同的網路區段內的執行時間，主要的時間都是在檔案傳輸的部分。
測試檔案大小 3 個伺服器 5 個伺服器 7 個伺服器 9 個伺服器
小於 10 KB 0.217563 0.331341 0.466655 0.570460
小於 100 KB 0.245769 0.410174 0.479227 0.660178 小於 1 MB 0.433338 0.594532 0.640597 0.786688
小於 10 MB 1.636473 1.972134 2.011500 2.163858
表格 10 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服
器執行一次上傳的動作所花費的時間 (單位:秒)
圖 12 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服器
執行一次上傳的動作所花費的時間 (單位:秒)
測試檔案大小 3 個伺服器 5 個伺服器 7 個伺服器 9 個伺服器
小於 10 KB 0.263332 0.358435 0.490343 0.556110
小於 100 KB 0.270404 0.396497 0.567059 0.597088 小於 1 MB 0.382264 0.590987 0.694622 0.846141
小於 10 MB 0.823476 1.086515 1.208293 1.278169
表格 11 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服
器執行一次下載的動作所花費的時間 (單位:秒)
圖 13 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服器
執行一次下載的動作所花費的時間 (單位:秒)
2014 Cloud Com 的方法之執行結果 : 表格 12 和 圖 14 列出使用者在執 行一次上傳動作，執行前同步不同長度的 Chain Hash 所需要花費的時間。表格
13 和 圖 15 則列出下載動作的時間。這些數據也是使用者和服務提供者在不同 的網路區段內的執行時間。
測試檔案大小
同步長度
2
同步長度
10
同步長度
50
同步長度
100
同步長度
500 小於 10 KB 0.362766 0.411929 0.486570 0.500776 1.227709
小於 100 KB 0.377788 0.416367 0.508769 0.563544 1.375298 小於 1 MB 0.556890 0.619318 0.698361 0.812837 1.630702
小於 10 MB 1.525459 1.882746 1.929606 1.962343 2.753549
表格 12 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要
同步長度，執行一次上傳的動作所花費的時間 (單位:秒)
圖 14 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要同
步長度，執行一次上傳的動作所花費的時間 (單位:秒)
測試檔案大小
同步長度
2
同步長度
10
同步長度
50
同步長度
100
同步長度
500 小於 10 KB 0.388520 0.374224 0.524074 0.646150 2.269309
小於 100 KB 0.427226 0.440348 0.584122 0.735439 2.302957 小於 1 MB 0.574539 0.687956 0.772134 0.914938 2.519163
小於 10 MB 0.933868 1.024385 1.145598 1.414567 2.884841
表格 13 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要
同步長度，執行一次下載的動作所花費的時間 (單位:秒)
圖 15 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要同
步長度，執行一次下載的動作所花費的時間 (單位:秒)
整理使用者和服務提供者在不同的網路區段中，將沒有使用 POV 的方法、
本篇論文提出的方法以及 2014 Cloud Com 的方法整理成圖 10 和圖 11 的比較 圖表。
圖 16 : 使用者和服務提供者在不同的網路區段中，比較以上三種方法，執行一次上傳的動作所
花費的時間 (單位:秒)
圖 17 : 使用者和服務提供者在不同的網路區段中，比較以上三種方法，執行一次下載的動作所
花費的時間 (單位:秒)
最後我們分析所有的數據，將本篇論文提出的方法以及 2014 Cloud Com 的 方法的結果除以沒有使用 POV 的時間計算方法之間的差距倍數，分別是 表格 14 和 表格 15，從數據中可以看到本篇論文提出方法，平均上傳差 3.97 倍、下載差
7.91 倍，最差的情況上傳差 6.99 倍、下載差 21.24 倍；而 2014 Cloud Com 方法 的平均上傳差 1.42 倍、下載差 1.88 倍，最差的情況上傳差 2.15 倍、下載差 4.08
倍。從平均來看本論文提出的方法比 2014 Cloud Com 的方法快 8 倍，最差的情 況時我們能夠比 2014 Cloud Com 的方法快超過 20 倍，大大的改善了之前的方
倍。從平均來看本論文提出的方法比 2014 Cloud Com 的方法快 8 倍，最差的情 況時我們能夠比 2014 Cloud Com 的方法快超過 20 倍，大大的改善了之前的方