Tor Metrics

實際上我們並不是去逐使用者計數加總,而是依據客戶端程式週期性去對目錄主機發送中繼節點清單的更新請求統計資料為基礎,再以間接的方式去推估而得。

不會,但是我們可以看到哪些目錄主機會回報,然後再進而推估網路中的總使用者數量。

我們是先假定每個客戶端程式每天平均會發送10次這樣的請求。 因為 Tor 客戶端程式若以24/7全天候處於上線狀態時,平均每天會發送15次這種請求,但是並非所有客戶端程式都會24/7全天候上線,因此我們選定10作為平均值。 然後就只要把目錄主機的請求數量統計除以10,即視為是使用者人數。 從另一方面來看,我們是假定每個這樣的請求都代表一個客戶端程式上線了十分之一天的時間,也就是2個小時又24分鐘。

是從過去一天內所收集到的資料裡估測出來的平均同時線上人數,我們無法得知這裡面有多少不同的使用者。

沒有,中繼節點都是每24個小時才把請求連線記錄以國家別分類並聚合統計後,才會回報給我們。 若要針對每小時的使用者人數進行統計的話,我們需要收集的資料會太過精細,這樣有可能讓使用者暴露於風險之中。

那我們就把那幾個使用者都算成一個,因為我們實際上是在計算客戶端程式數量,但是對於大部分人來說,將它說程式使用者會比較直觀易懂,這也是為什麼我們這裡會以使用者來取代客戶端程式的說法。

目錄主機會解析出IP位址的國碼,並將資料聚合後回報,這也是為什麼洋蔥路由軟體會預載GeoIP資料庫的原因。

目前很少橋接中繼站會回報傳輸以及IP版本的相關資訊,我們也考慮要預設使用OR協定以及IPv4。 等到有較多的橋接中繼站回報這些資料時,這項統計數據的精確度就會提高。

中繼節點或橋機中繼站通常是每24個小時才會回報一次資料,該回報時間點可能在一天之中的任何時刻。
但有時候中繼節點或橋接中繼站會在該時間區間結束後18個小時,才將資料回報。
我們將最近兩天內的數據資料從圖表中切除的原因,是想要避免讓最近的變化趨勢受到演算法的計算偏差影響。

通常只有當我們確信該使用者人數資料已經不會再有大幅度變動時,才會將它發佈出來。 但是仍有可能某個目錄主機在我們發佈後才回報資料,因此造成圖表資料會有微幅度的變動。

我們確實是擁有在該時間點以前的描述子相關歷史資料庫存,但是那些描述子並沒有包含估測使用者數量所需要的資料。 請下載這個tarball檔以取得更多資訊:

Tarball

針對直接連上線的使用者,我們把所有之前未被涵蓋的目錄主機都囊括進來了。 而且我們現在也使用了那些只用於回覆目錄請求的位元組資料歷史記錄,這會比只單純使用位元組歷史資料做通盤計算還要來的精確。

喔,這個就說來話長了,我們有寫了一篇長達13頁的技術報告書來說明我們決定拋棄舊有估測方式的原因。
簡而言之:在舊有的估測方法裡,我們統計到了錯誤的指標,現在的新方法所估算的數值才是正確的。

我們目前使用以異常事件為基礎的審查過濾偵測系統,目的在於觀測過往幾天的使用者數量估測值,並預估未來幾天的使用者數量。 當實際的數值偏高或偏低時,表示可能有網路審查過濾活動發生。 請參閱我們的技術報告書以了解更多細節。