發新話題

透視BT ── BT的基本運作原理

透視BT ── BT的基本運作原理

(一)  ──  BT的基本運作原理

談到BT,相信大家都不陌生。沒錯,今天要來談的就是這幾年在網路上非常重要,已經快要變成全民運動的──BT程式。筆者有鑒於BT已經變成非常火紅的應用程式,但是了解這個程式的基本運作原理與影響的人卻寥寥無幾,於是決定撰寫這個主題;本篇會先介紹BT的源起與運作原理,接下來的幾篇則會根據這一兩年學術上對BT的觀察,介紹BT在各種使用情境下對網路行為的影響(當中包含一些相當出人意表的發現)。


BitTorrent,簡稱BT,由Bram Cohen於2002年獨立完成其核心程式碼的撰寫。從Bram Cohen簡陋而陽春的個人網頁上看來,他於1993年進入紐約州立大學就讀,輟學之後陸續做過研究員、網路程式設計師,就履歷上看來並不是非常特出,2002年間他發表的BT一開始也沒有獲得很大的關注。隔年五月他把BT的理論基礎寫成一篇簡短五頁的學術文章發表在「Workshop on Economics of Peer-to-Peer Systems, 2003」上,文章本身沒有知名教授的背書、用字遣辭顯然也不夠精練,然而這篇文章至今卻已累積了474篇的reference數。2004年六月時,據CNN報導,BT已經佔據了網路上所有P2P流量的53%。至今,BT程式檔的下載量已經超過一億三千五百萬人次,而這些數字還不包含網路上經其他使用者修改過的版本,如BitComet、BitSpirit…等等。

Bram Cohen照片,在他blog裡還有各種用電腦變形過後的照片,例如變身成美少女戰士的樣子。

就Mr. Friday自己的觀察,BT程式已經成為眾多網路鄉民平日不可或缺的「資料來源」之一,就算沒有使用過,或多或少也會在生活中聽到相關的用語,比如說torrent檔、種子、斷種等等術語。更有甚者,許多網路應用也開始使用BT的模式,比如說某些Linux的ISO檔、魔獸世界WOW的更新檔就是透過BT方式在網路上散佈,也有一些網路電視程式是從BT處得到靈感來源,例如現在相當火紅的PPStream。


BT最讓人驚奇的地方在於下載的速度極快。使用過的人都曉得,BT下載往往比傳統的FTP、網頁下載來得快很多。這當中的原理可以從下圖解釋:



左圖是FTP與HTTP下載的基本原理,道理很簡單,擁有檔案的人負責將檔案傳送給所有想下載檔案的人。假設今天的同時下載這個檔案的人有三個(A、B、C),則每個人的下載速度就是檔案擁有者上傳速度的1/3。


BT的原理就比較複雜一點。擁有檔案(例如File.txt)的人(稱為種子)會將檔案切很多很多的小塊(例如File1.txt、File2.txt、…、File100.txt),每當有人(假設也叫A)想下載檔案時,種子(或者其他的下載者)就把一部份的小塊檔案寄給這個A,A就拿著這些檔案片段去跟另外一個也在下載的人B、C說:「Hey!我有一部分的小檔案,你也有一部分的小檔案,我們來互相交換彼此沒有的部分吧!」。對於A來說,他就可以同時從種子與B、C處抓取檔案片段,因此下載的速度就會變快,而不僅限於種子頻寬的1/3。如果今天網路上的下載者不只2個,而是成千上萬,那麼理論上A的速度就可以一飛千里。透過這個「下載者互通有無」的想法,讓下載的速度來得比以往的FTP、HTTP還快。


BT對於分享檔案的種子也有好處。以往如果要讓所有的下載者都抓到檔案,種子就不能下線,直到所有人都抓完檔案為止。頻寬的消耗也是單方面的:只消耗種子的上傳頻寬,因此常常造成種子端的網路塞車。BT就不會這樣:只要網路上出現另外一個把整個檔案都下載成功的人,等於就是出現另外一個新種子,原來的種子就可以下線休息去了──甚至不用等到新種子出現!沿用前例,原先的種子把檔案片段1~3給了A,片段4~6給了B,片段7~10給了C,那麼就算種子下線休息去了,ABC之間仍然能夠透過互通有無的機制,把檔案下載成功。BT一方面減輕了單一種子的負擔,另一方面也延長了檔案的壽命-就算原先種子離開了,如果A、B、C當中有人志願留下來等到新下載者D出現,那麼檔案就能繼續流傳下去。


TOP

當然,要讓這套機制成功,還有幾個配套的措施:

(1) Torrent檔與Tracker:

由於BT中的種子、下載成員一直在變動,必須要有方法讓其他新成員找到他們,因此就出現了Torrent檔與Tracker。Tracker是個小程式,紀錄著目前所有下載成員的名單與網路位置。Torrent檔則是紀錄Tracker的位置與檔案片段的全部名稱。因此對於新成員來說,他首先要獲得的就是一個torrent檔,從torrent檔中他知道tracker的位置,然後再經由tracker與其他下載成員取得聯繫。


(2) Rarest First Policy

為了增進檔案分享的速度,每個成員會盡量分享網路上最少見的檔案片段。例如A擁有片段1、2、3,B擁有2、4、5,C擁有1、3、5,則網路上最罕見的是片段4,因此若有人想向B互通有無,B會優先傳給他片段4。


(3) Choking Policy

當一個檔案很流行的時候,一個BT系統可能會同時擁有成千上萬的下載者。A身為一個參與者,必定會收到非常多人希望跟他交換檔案的請求。但是A的頻寬很小,只允許同時上傳給4個人(在BT最初原始程式裡預設是4;其他軟體的設定就不一定了,我知道BitComet之前是10個),那麼A要如何決定拒絕這當中的誰呢?這叫做choking(拒絕)policy。BT的做法是:接受(unchoke)那些現在正上傳檔案給我、而且速度最快的前4個人!BT的Choking Policy至為重要,因為它傳達出一種「施比受更有福」的概念:願意付出更多上傳頻寬的人,將會收到其他人的回報-更快的下載速度。日後有許多關於BT的研究,都是針對這個特性作一番探討。


(4) Optimistic Unchoking

承續前述的理念,想要獲得更快的下載速度,就應該先將檔案分享給別人。Optimistic Unchoking是說,每個人每30秒就挑網路中任意一個人,將檔案上傳給他。這麼作的用意是發掘網路上未知的潛力檔案提供者:假如A與K之前並未有檔案的往來,但其實這兩個人住得很近,網路互傳的速度比其他人快。今天A透過Optimistic Unchoking隨機給K上傳了一些檔案片段,讓K驚覺A的上傳速度很快,進而允許A從K處下載檔案片段。如果A與K之間的連線速度很慢,那麼過30秒之後,A會停止提供檔案給K,而去別處尋找下一個候選人。


透過上述的幾種機制,Bram Cohen成功的開發出一套獨特的下載技術,也讓BT成為近幾年來最流行的話題,網路上更逐漸出現許多以BT為核心,內容卻略有不同的幾套下載軟體,如前述BitComet、BitSpirit等。這些軟體多少在技術上修改了BT,比如說改變檔案傳輸時使用的port、改變同時最多上傳人數等等,但技術的基本概念卻是不變的:透過鼓勵分享,達到更快的下載速度。


接下來的幾篇,會引述幾篇學術上研究BT機制的論文,讓我們看看BT這套機制透過長時間實驗與數學流體模型、機率模型、排隊模型、賽局理論……等等的驗證下,在各方面的效能如何?這些論文又會給我們什麼啟示?敬請大家拭目以待,下回再見。

TOP

透視BT(二)──網路的頻寬分享與BT的隨機過程模型

前一篇文章介紹了BT的基本運作原理,這一篇文章就來看看學術界對這個機制的探討吧。


關於BT機制本身的實驗文章其實不少。2004年一群法國人發表了一篇Dissecting BitTorrent:Five Months in a Torrent’s Life。內容是他們把Red Hat 9的原始檔(約1.77G)放在網路上供人下載,透過Tracker的紀錄機制,觀察BT的下載特性。相較於這群法國人觀察的是單一BT檔的下載過程,紐西蘭Delft大學的研究生則觀察了國外比較有名的BT分享論壇(Supernova.org、Youceff.com等)幾個月來的人潮(大約有六萬人)。從這些鄉野實驗,可以得到幾個基本的結論:

(1) BT檔案往往會有flash crowd情形:分享開始的前幾天會湧入大量人潮,然而高潮退去後人也散得快。

(2) 下載的速度呈現「多數人下載慢,極少數人下載速度超快」的情形;不過即使「多數人下載慢」,下載的平均速度仍然比ftp快上不少。根據實驗,平均下載速度是240K,90%的人速度不會超過520K。有極少數的人下載速度會達到每秒3000K以上。

(3) 檔案的存活天數難以從檔案分享十天後的狀況來預測:紐西蘭學生嘗試著去預測檔案存活天數,不過失敗了。後面我們會看到另外一篇paper是如何成功預測的。


就這樣而已嗎?這兩篇實驗雖然做了一段蠻長的時間,可是得出的結論好像跟沒做差不多;我們這些下載者不用做實驗也知道。不過學術界就是這樣:會有人先去做最基本的實驗,弄出一大堆看似無用的數據,接著就會出現根據這些數據做出的漂亮推論。2004年,著名期刊SIGCOMM石破天驚地刊出了一篇論文:「Modeling and Performance Analysis of BitTorrent-Like Peer-to-Peer Networks」,作者是UIUC的Dongyu Qiu與R. Sirkant。該篇文章用廣泛而嚴謹的數學模型推導BitTorrent在穩定態效能、檔案分享效度、Free Rider(不提供上傳頻寬但享受下載速度的懶蟲)等問題,做了一番精闢的解析,讓所有網路學教授驚覺BT中的價值:不只是因為根據BT的數學隨機模型極有研究價值(經數學驗證,BT擁有「無人數上限」、「下載速度不受人潮影響」的特性),更讓他們驚奇的是,這些教授竟然都沒發現身邊有這麼傑出的軟體,而且還是一個無名小卒寫的XD。從該篇文章之後,有更多的學術資源投入與BT相關的研究,BT技術的影響也深入到其他應用,例如隨選視訊(VOD)、CDN等等。

TOP

既然上一篇討論過了BT的基本特性,我們就直接來看看這篇論文探討了哪些東西吧!接下來的文章可能會牽涉到一些數學,我會盡量用淺顯易懂的字眼跟大家解釋的。


(1)流體模型(Fluid Model)

還記得國中數學上的馬可夫鏈(Markov Chain)嗎?典型的題目是這樣:
某旅行家固定在A、B兩城走動,每天他會決定要前往A城或B城,如果今天他人在A城,則有80%的機率明天他會走到B城去(20%的機率留下來);如果今天他在B城,則明天他有75%的機率跑到A城(25%的機率待在B城)。問經過無數天之後,旅行家待在A城的機率有多少?待在B城的機率有多少??

相信大家對這類的數學問題還有一點點印象。好了,今天我們不討論如何解題,來看看Sirkant他們如何用類似的方式模擬BT:
今天有A、B、C、D四個城,A城象徵沒有加入BT的人,B城象徵成為BT下載者的人,C城象徵成為BT種子的人,D城象徵下載完後離開系統的人。A城每天有λ人會進入B城,C城每天有γ的人會進入D城,而C城到D城(下載者變成種子)的速率則視當下BT中有多少人、每人平均分享頻寬而定,則經過無數天之後,B城的人有多少?C城的人有多少?從B城到C城的平均速度是多少??

相信大家一定都對這樣的數學模型算出來的結果很有興趣(包括我XD),算出來的結果是



代表平均下載人數,代表平均種子數,θ代表中途取消下載的比例,β則是受到下載速度、平均上傳頻寬、檔案分享效率與種子離開率影響的一個變數。從排隊理論可以進一步推導出x變成y(下載者變成種子)的時間大約是:



T是平均下載時間。從這些奇怪的數學蝌蚪文中,作者得到了以下結論:

Ø 平均下載時間與人潮湧進的速率無關。因此下載時間不會因為系統中人很多(或人很少)而變快(或變慢)

Ø 檔案分享的效率越高,下載時間越短。分享的效率與「BT中一個下載者同時最多能向多少人交換檔案片段下落的資訊」成正相關。

Ø 種子離開系統的速率會影響下載時間。每分鐘若有10個種子離開BT,平均下載速率會比每分鐘5個種子離開的BT慢。

Ø 在網路上絕大多數人使用ADSL的情況下,會影響下載速度的是「每個人平均願意分享出來的頻寬」。除非今天每個下載者變成種子之後都捨不得離開BT、讓BT中充滿無限多個種子,否則這個法則不會改變。


(2)賽局理論

還記得「美麗境界」裡面John Nash對於「如何追女孩子」提出的賽局理論解說嗎?沒錯,這篇論文也用上了賽局,用來解釋「如果你上傳頻寬比別人少的話,跟別人搶下載資源會多麼吃力」這件事。事實上根據BT的基本設定,這個結論還頗殘酷的……。還記得上一篇提到,每個人都會上傳給「分享給我檔案且速度最快的前四個人」嗎?假設今天系統中有六個人,這六個人的上傳頻寬都不一樣,則根據這個法則,上傳頻寬最少的使用者將屈居劣勢,因為頻寬前五名的使用者會「玩他們自己的」,互相將檔案傳給對方,而頻寬最後一名的使用者只能等待前五位偶發性的「Optimistic Unchoking」施捨一點檔案給第六名,或者說等前五位都下載完畢成為種子之後,才能得到檔案。



所以BT中達不到皆大歡喜的Nash Equilibrium(納許平衡點),總是會有人得不到檔案嘛?倒也不盡然。這篇paper另外提出一種情境,在這種情境下每個人的下載速度都不會太低:將網路上的下載者依據頻寬分為幾個大族群。上傳頻寬最大的族群會優先獲得檔案,當這個族群的下載速度已經快到不能再快的時候,多出來的上傳頻寬會分享給第二快的族群,然後依此類推…。只要每個族群的人數到達一定的數量,就會達到人人有檔抓、速度都不慢的納許平衡點。



(事實上Mr. Friday對賽局不熟,這段看了我好久啊~如果有錯還請指正)

TOP

(3)Free Riding問題

Free Riding(Free Riding是一種行為,Free Rider是指有這種行為的人)指的是不合作的使用者。在注重分享功能的BT系統中,偏偏有些人上傳開一點點或根本不開,那麼這些人的還是會享有很高的效能嘛?讓我們來想一下,Free Rider們唯一能夠獲得檔案的機會就是其他人透過Optimistic Unchoking隨機上傳檔案給他們的時候。那麼一個Free Rider接受到的機會有多少?假設系統中只有一個Free Rider,則其他人隨機選到他、上傳檔案給他的頻寬就等於

N(總人數)

乘上μ(每人平均上傳頻寬)

乘上1/N-n(選中Free Rider的機率,N為總人數,n為當下有上傳關係的人數)

乘上1/(n+1)(Optimistic Unchoking佔去的頻寬比例)


因為N往往極大(人數常常破千上萬),相較於n很小(預設同時上傳給4人),所以化簡後可得

Free Rider頻寬=μ/(n+1)


如果照BT原先的預設n=4(最多同時上傳給4個人),則一個Free Rider的下載速度大概是網路平均上傳頻寬的五分之一。因為在BT機制中,每個人的下載都來自其他人的上傳,所以每人平均上傳頻寬也就等於每人平均下載速度。因此該式子代表「一個不分享上傳頻寬的傢伙,下載速率大約是其他人的五分之一」。如果是BitComet之類的軟體,將n調到10,則free rider的下載速率大概是別人的十一分之一。

大家應該都不太喜歡網路上有Free Rider的出現,那麼我們直接把n這個數字提高到無限大好不好?但n太高會引起反效果,因為開啟太多的連線數會直接導致網路擁擠,錯誤率提高,整體上傳率反而下跌,進而導致群體下載速度變更慢。n這個參數的設定,反倒變成BitComet、BitSpirit、μTorrent這些軟體的兩難議題了。

從上面精采的推導,給了我們幾個觀察BT的重點。首先是BT在檔案分享效率上已經超乎許多學者原本的預期,下載的速率不會隨著同時下載人數的多寡而變,而能一直維持在「每人平均上傳速率」-這是一個相當重要的特性,因為它打破一般以為「想要禁得起多人同時下載,就得付出龐大的伺服器架設費用」的迷思。模仿BT機制而運作良好的PPStream就是一個很好的例子。以往大家都認為Video On Demand(隨選視訊)至少還要經過個十幾年,等到有人付得起龐大的網路串流伺服器架設費用再說。現在呢?你看PPStream運作得多快!

TOP

第二個重點是BT軟體本身可設定的參數對於整個BT系統下載的影響。如前面所述,網路上有很多以BT為核心、但是經過略加修改的軟體,如BitComet、BitSpirit、μTorrent等等。可別以為這些軟體都差不多,事實上這些軟體所動到的一些參數,如同時可傳輸的人數上限、同時交換檔案片段訊息的人數上限,甚至是預設的上傳頻寬上限等等,會徹底的影響整個BT的運作效能。不過我談論的是整體:如果一群人都用BitComet,與另一群都用BitSpirit下載,兩組群體的整體效能會不相同,但是以現在網路的情形,大概有20%用BitComet、30%用BitSpirit、5%用奇奇怪怪的軟體……。如果你把慣用的BT軟體從BitComet轉換成BitSpirit,你的下載的速度應該不會有特別的影響。只有在整體的情況下─有10000人共同把軟體從BitComet換成BitSpirit─才會有影響。所以別輕易的被「我們這套軟體用了特殊加速的方法」之類的廣告辭迷惑。那或許是真的,不過要非常多人都使用那套軟體才會有效。而且「加快下載」這類的技術往往都不是很光明正大,裡面不知道藏了什麼奇怪的設定(像是死道友也死貧道的foxy)才會讓下載速度變快……。還是乖乖用一般的正派BT軟體就好吧!


最後一個是我個人的感想。看到前面國中曾經學過的馬可夫鏈、電影中看過的賽局理論、高中時算得要死的機率…不知道大家是不是跟Mr. Friday一樣感慨呢?這些學問以前在學的時候總是覺得艱深,而且不知道到底可以用在哪裡。不過這些數學的應用其實就存在你我的身邊,甚至是大家每天開啟的BT程式中。透過這些數學的運算,甚至可以真實的預測出大眾看似不經意而隨機的下載行為模式。誰說國高中時學的數學是沒有用的呢?這裡還真要感謝我國高中的數學老師幫我打下的基礎,不然我還看不太懂這些言簡意賅的精妙數學運算式呢!

這樣就結束了嗎?還沒呢!下一篇將會介紹另一篇研究BT行為的Paper,看他們是如何準確預測BT從發佈到斷種的時間長度,上傳分享比率與下載速度之間的關係,甚至是開同時開數個Torrent檔時的影響!精采可期,可別錯過了喔!

TOP

透視BT(三)­­──數字會說話, BT有什麼問題?

有些讀者看完第二篇之後覺得太深奧了, 還有人說好像在看排隊理論的論文, 不太想看下去, 這這…好吧, 這第三篇我直接下猛藥. 本篇的重點在於

1. 數據顯示, (瞬間平均)下載速度最快是出現在BT檔發佈後的第50小時!!!

2. 數據顯示, 在BT中, 上傳的量越多, 下載速度反而比較慢!!!

3. 數據顯示, 同時開多個BT下載, 下載速度不會變慢!!!


有沒有比較想往下看了呢? XD


回到正題. 前面兩篇已經分別敘述過BT的基本原理和BT隨機過程推導, 那麼這一篇還有什麼好寫的呢? 不曉得大家有沒有發現, 前面在數學論證部分只有純理論的推導. 胡適不是說過:」大膽假設, 小心求證」嗎? 沒有數據驗證, 純理論推導似乎也只是空談. 我們就來看看另外一篇paper, 根據它的數學模型與實際觀測出來的結果. 這篇paper是幾個大陸人聯合觀測與驗證的結果, 篇名叫 Measurements, Analysis, and Modeling of BitTorrent-like Systems. (註:該文圖表眾多, 本篇只取我感興趣的部分)

這篇paper首先觀察了使用者加入BT的狀況, 是一個標準的指數分配:



綠色的線是實際觀測到的新加入者隨著時間遞減的情形, 藍色的直線是一個指數分配的走向, 可以視為預測值. 看起來預測的值相當接近實際值. 另外, 大家不要看那個好像是一直線, 注意一下y軸, 那個刻度可是10000, 1000, 100, 10, 1人喔, 所以遞減的速度是很驚人的.

把這個人數遞減預測值套到先前的公式, 可以預測到種子與下載者的人數變化



黑色虛線是預測值, 紅色是實際觀測到的下載者人數變化,綠色則是觀測到的種子數變化.

從這幾個圖看來, 預測值跟實際觀測值都蠻接近的. 可以證明前一篇的理論大致上是正確的. 好了, 下載速率呢? 你說的數據顯示, (瞬間平均)下載速度最快是出現在BT檔發佈後的第50小時!!!在哪呢? 在這裡!



(在這裡先聲明, 本圖是計算」當下在系統內所有人瞬間下載速率的平均」, 而不是第二篇所計算的」對於指定的BT檔, 不論任何時間開啟下載, 所有人的總下載速率平均「, 兩者略微不同. 後者是不會隨時間而變的)

綠色的是實際觀測值, 藍色是預測值. 根據預測, BT大量湧進下載人潮的時候, 其實並不是瞬間速度最快的時候. 瞬間速率最高是種子比例高於下載者的時候…, 也就是說, 當前幾個小時加入下載的人都變成種子, 且新加入的人潮越來越少, 此時就是瞬間下載速率越來越快的時候. 根據實驗結果, 當最初加入者剛變成種子且還沒離開系統時, 下載速度簡直是爆衝. 大約是在BT檔發佈後第50個小時左右會達到爆衝高潮. 不過爆衝這一段時間, 也正好是一堆人下載完檔後一起離開系統的時間, 所以系統比較不穩定. 在第50小時之後, 就算爆衝消失, 由於系統中純分享的種子比率也比下載者高, 因此瞬間下載速度也比一開始快. (130~150, 160~200小時那段平均下載速率為0的原因是那時候根本沒人下載),

懂了嗎? 雖然BT是搶熱門檔的程式, 但是下載速度反而在」種子發佈後50小時」才會快!

TOP

這篇paper除了」驗算」上一篇的理論外, 還觀測 (配上他們自己的預測) 了許多其他的數據:

BT檔生命週期. 藍色是預測值, 綠色是觀測值



這裡要說明一下他們是怎麼預測的. 之前曾提過有群紐西蘭學生預測失敗對不對? 這篇看起來就預測得很成功啊! 嘖嘖, 這就是功力的差別囉!這群大陸人假設」最後一個種子離開後就會斷種」, 所以當

第n個人花在下載檔案的時間 + 第n個種子在系統中閒晃不離線的時間

小於

第n+1個人到來的時間+第n+1個人花再下載檔案的時間

就會斷種.

上面的圖就是根據這個推斷來的. 我們曾經在第一篇中有提到, 就算種子下線, 只要它曾經把手上的檔案片段都分散給其他下載者, 則該BT就還不會斷種. 所以我們應該會看到綠色的觀測值要比估計值活得久一點(換言之就是y軸的值高一點). 而時間結果也大致吻合.

BT人數預測, 綠色為觀測值, 藍色為預測值, 是根據下載者到達率與上圖生命週期來算的. 大部分的BT檔總人數(y軸)大概只有100人左右而已.



好了, 接下來就是大家所關心的: 2. 數據顯示, 在BT中, 上傳的量越多, 下載速度反而比較慢!!!請看下圖.



左邊的y軸代表分享率. 分享率=上傳總量/下載總量. 由於下載總量不變, 所以這個數字意義就是上傳總量. 綠色的點位置越高, 代表上傳得越多. 右邊的y軸代表平均下載速度. x軸的每一個刻度代表一個下載者, 每個x座標上都會有兩個點: 綠色與藍色. 綠色代表該下載者的上傳總量. 藍色代表平均下載速度. 為了容易瞭解起見, 每個使用者(x軸)是根據下載速率(從高至慢)由左而右排列.(所以藍色的線一路往下).

看懂了沒? 這個圖的意義, 真的就是在BT中, 上傳的量越多, 下載速度反而比較慢!天呀!之前不是有提過, BT的設計理念就是, 越願意分享頻寬的人, 下載速度才會快嗎? 那怎麼數據出來會這樣子呢?

=====================(作用不明的分隔線)======================

在這裡, 要很誠摯的告訴你 : 這兩件事, 都是真的.

聰明的讀者動腦想一想, 相信原因不難推敲. 想不出來? 讓我舉一個常見的例子來說明:

假設今天有A, B兩個人. A的上傳頻寬為100kbps, B的上傳頻寬為50kbps, 今天兩人同時下載一個BT檔案. 兩人上傳速度全開. 由於A的上傳頻寬比較高, 所以下載速度也比較快, 花了20分鐘就下載完了. B的上傳就比較慢, 所以導致他花了1小時左右下載完畢. 兩人都在下載完畢之後立刻關掉BT, 因此A的上傳總量=100kbps * 20分鐘 = 120mb, 而B雖然上傳速度慢, 但上傳總量卻高達50kbps * 1小時 = 50*60*60 kb = 180mb !

這次應該看懂了吧! 「上傳總量」不等於」上傳速度」! 由於在BT中, 上傳速度快的人下載得太快了, 反而導致總上傳量其實比那些上傳速度慢還要少. 這張圖凸顯出BT的一個缺點:下載速度並未反應出上傳速度的差異! 上傳速度只是比A慢1/2的B, 下載時間卻可能是A的3倍以上, 導致某種程度的不均衡. 不過在這裡大家也就不要心理不平衡了, 因為1:這個曲線相當平緩, 代表B就算吃虧, 平均來講虧的也不算太多, 而且 2. 還有另外一種的可能性, 那就是:

就是…

從上面那條作用不明的分隔線之後, 都是虎爛的

TOP

喂喂!先別急著打我, 原文的確是有做出類似的推測, 它說」This indicates that peers with high speed finish downloading quickly and then quit the system soon(本圖暗示:速度快的人, 快速下載完後就速速離開BT了)」. 不過這句話我採保留意見, 因為這個圖表並沒有拿另外的數據(例如上傳速度快的人真的離線得早)來佐證, 雖然這個說法聽起來很合理, 但是沒有數據證實, 還是別輕易就此下定論的好.

好啦我們接著往下看. 接下來的圖表可就是有說服力的了.



這張圖畫法類似上一張圖. 左邊y軸(綠)是下載速度(越高越快), 右邊y軸(藍)是同時開啟的BT檔案數, x軸是每個使用者, 從左至右則依同時開啟的BT數(從高到低). 這張圖代表投藍又投綠的人嗎? 當然不是. 它是說同時開多個BT下載, 下載速度不會變慢. 瞧, 左半邊藍色線較高(開啟的BT數多), 下載速率(綠色點點)也沒有比右邊的人慢啊. 至於為什麼? 文章也不知道.

到這裡就結束了嗎?事實上paper到這裡還沒完. 這篇paper最後其實有個大章節在用數據建立理論模型, 再用模型推導」開啟多重BT檔, 將有助於減少斷種率「. 講實際一點, 就是弄成eMule那種行為模式: 每個人同時開啟好多BT下載, 抓一點點之後可能斷個線, 過個幾小時再回來繼續下載. 根據這篇paper推論, 如果一個BT檔案的下載失敗率是0.1(意即總共10個開啟下載的人中, 會有1個人因為檔案已斷種而下載失敗), 則上述同時開啟多個BT檔案的行為模式, 失敗率會降低到0.000001 . 這差不多也可以解釋為什麼大家都認為eMule上檔案可以留得比較久, 因為eMule上的行為模式就是這樣.

那麼BT可能變成這樣嗎 ? 理論上也許可以吧. 不過BT之所以像BT而不像eMule, 在於兩者的設計理念根本不一樣. BT就是為了大型檔案的快速發佈而生, 而eMule則是為了提供一個什麼都有而且什麼都留得很久的分享環境. 這個設計理念不僅深深影響了兩者的檔案傳輸效能, 也根本的影響了兩者的網路架構與程式介面. 因此BT的使用者有可能會出現eMule使用者那樣的行為嗎? Well, 話不能說死, 不過至少等到BT做出一個內建搜尋頁面出來再說吧!

最後做個總結. 這篇文章用數據驗證了之前提過的數學模型, 也同樣用數據顯示BT各方面的效能, 當中最突顯的是BT在公平性(fairness)上的問題. 最後它提出一個multiple torrents模型, 並推論這樣的行為模式將可大大降低BT的斷種率過高問題.

TOP

字好多~"~
看了一大半而已!感覺內容蠻充實的!
有圖解會更好= =|

TOP

發新話題

本站所有圖文均屬網友發表,僅代表作者的觀點與本站無關,如有侵權請通知版主會盡快刪除。