快取]迅雷(XUNLEI)的工作原理揭密

迅雷(XUNLEI)如何搜尋一個資源的多伺服器版本？

摘要：

當你用迅雷下載東西時，無論你是從迅雷資源頁點下載，還是從其它普通頁面點下載，你會發現它並不只用你的原始連結下載，它還搜尋了一些其它伺服器的相同資源，比起網路螞蟻/網際快車之類的下載工具（這些都是純客戶端工具，而迅雷則有著伺服器支援），大大增加成功下載的可能性和下載的速度，對比起P2P之類的下載軟體，又更乾淨利落一些，那它是如何做到的呢？其實同baidu,google的基本原理是一樣的，只不過各自的技術又有側重而已，本文就個人經驗分析其實現渠道及基本原理，暫稱這個系統為福雷（FULEI），同本人名字有點諧音，呵呵，寫下此文，也不枉昨晚失眠的幾十分鐘。

搜尋,視訊, 迅雷,p2p,下載,google,baidu,search,

下載電影，音樂之類的大檔案（相對於網頁）相信是每一個年輕人最愛乾的一件事之一了，在這個P2P下載軟體橫行的時代，為什麼像迅雷這樣的客戶/伺服器模式還能有那麼大市場呢？我曾試過好幾款P2P下載軟體（如電騾，天網MAZE等），但沒用多久就被我解除安裝了，我不喜歡被人家不斷讀硬碟的感覺，因為它們曾毀了我一塊硬碟，而且佔了我太多的上行頻寬，個人認為，如果要用這類軟體，別裝在你的工作用機/學習用機上，而應專門用一臺破機器去執行它。使用迅雷還是一兩個月以前的事，因為在此之前，我主要還是用網際快車之類的軟體下載東西，這類軟體是純客戶端軟體，更多的無非是下載管理

迅雷的這個點子，的確是個好點子！其實仔細想想，這其實只是箇中庸的點子而已，介於P2P和純客戶端下載軟體（如NETANTS，FLASHGET之類）之間的一箇中庸點子，由此又驗證了一句話：中庸在很多時候可能是最好的選擇。

我們的福雷要做同迅雷差不多的事，讀下文時可以暫將福字替換成迅。

談了這麼多，還沒有談到一點技術性的內容，真唐僧！

福雷做法的關鍵在哪裡？在於當用戶要下載一個資源時，如何去找在其它伺服器上的完全相同的資源！

回顧一下普通搜尋引擎的做法：用Crawler沒日沒夜的下載網頁，然後儲存，索引（倒排表是很常用的做法），使用者搜尋時，它會根據索引找到符合的頁面，排序後，在本地伺服器擷取結果片段返回到客戶端。PDF/WORD等文件的搜尋也差不多，它們有個共同的特點是檔案不太大，而且基本不太涉及版權問題，因而所有內容在自己伺服器上都有快照。

但對於視訊/音訊等較大的檔案（動則幾十兆上百兆到G級），如果按上述方式處理則會有一些問題，首先要爬完一個資源所消耗的代價太大，其次，即使下來了，也沒有太大的用處，你不能直接供使用者下載，這可能會遭遇訴訟，看看百度音樂搜尋，以前搜出來的結果直接指向資源位置，現在還非得出一個對話方塊，將位置明示，生怕被人抓住把柄，個人認為完全沒有必要，也許是為了應付部分什麼也不懂的官員，卻讓使用者感到不便。

既然是搜尋，終歸需要先找到資源，這一點大家都一樣，基本的做法還是用Crawler，只不過，Crawler需要識別不同型別的資源區別對待，我們以視訊檔案為例說明。

假如Crawler在工作的過程中標識出了所有視訊檔案的連結並交於特殊的處理程式處理，接下來的問題如何儲存和索引這些資訊，剛才已經說了，要下載整個視訊檔案並不現實，而有一些內容是很容易得到的：資源連結，檔名/檔案型別（副檔名），大小，儲存這些資訊是簡單且必要的，

現在的關鍵問題是如何判斷檔案的同價性？也就是說，如何知道這幾個檔案是一樣的？儲存這個資訊對我信至關重要，通過檔名？顯然不行，通過修改時間？作者？大小？等，都不太準確，最常用的方法還是計算檔案摘要，而計算檔案摘要最常用的方法又是MD5（雖說MD5可以破解，但對於大眾化應用，這種破解沒什麼意義，而在非人為狀況下，MD5可以認為是可靠的），但這又出現一個新的難題，計算摘要需要所在檔案內容，我們有以下選擇：

1、 能不能在伺服器上計算？（可惜視訊不像些開源軟體，下載連結中常有MD5摘要檔案，這樣可以一併下來），而想在伺服器上計算，是否有些異想天開？

2、 下載所有內容計算摘要，上面已經說過這個問題

3、 下載部分內容計劃摘要，聽起來真不錯，又是一箇中庸的想法，我現在越來越喜歡中庸了，沒錯，就是它，但下載哪部分內容呢？我們可以根據檔案大小利用一些簡單的雜湊演算法生成雜湊值，根據這些值在檔案的不同部分讀取一定量的資料，總資料量控制在K級別（同網頁差不多大小），然後將這些資料拼裝成整體儲存並生成其摘要。這種方法是可行的。首先，它的下載量不大，其次，根據該方法判檔案的等價性同基準方法（根據所有資料算摘要）比準確率幾乎相同（證明過程我就不說了，實踐才是最好的標誰）

利用摘要判斷檔案等價性的方法有一個好處是可以忽略一些次要資訊，比如檔名，建立時間，修改時間等，但檔案型別，長度和摘要則是需要考慮的成份。也就是說，如果這三者一樣，則我們認為檔案是一樣的。

儲存完上述資訊，至於如何索引，考慮的因素可能會多一些，最簡單的就以摘要索引就行，這樣等價資源會被聚類到一起，但作為一個資源聚集點，資源的描述資訊也是要考慮進去的，等下我們會專門談到這個問題。

上面已經講完了主要內容，我們看看當我們利用福雷下載時它做了一些什麼事情。

1、 先看看普通的連結（非福雷連結）

b)福雷客戶端將該連線發到福雷伺服器，同時，客戶端也不閒著，它會去該連結獲取檔案的基本資訊（大小等），並按上面所述的演算法下載部分內容並計算摘要。

c)服務端根據連結找自己伺服器，看是否已被系統Crawler處理過，如果已被處理過，很簡單，通過其摘要找到所有含有該資源的伺服器連結發到客戶端。

d)客戶端為了保險起見，會對比一下服務端的摘要和自己算出的摘要（避免檔案在近期發生變動），如果一至，OK，可以從服務端發過來的多伺服器下載了。

e)如果不一樣的話，客戶端需將該資訊發到服務端，告訴它檔案有變，服務端會去更新該檔案的相關資訊（包括等價檔案連結），這個過程可以短也可能長，由此同時，客戶端會通過原始連結開始下載，服務端更新後，會陸續將確認後的連結發到客戶端，客戶端從而可又可從新增的連結下載。

f)接c)，如果服務端未找到原始連結呢？是不是意味著服務端就沒有其它連結呢？並不一定，此時，客戶端將資訊及摘要發到服務端，服務端可根據摘要資料去搜索，如果搜尋到結果，則將這些結果連結發到客戶端，並將該原始連結加入到伺服器索引中，從而同樣實現多伺服器下載，如果沒搜尋到，則只能從原始連結下載資源了。

g)在上一步中，如果伺服器沒找到原始連結也沒找到等價檔案，服務端會儲存該並索引該連結資訊。

h)在上述過程中，對於福雷伺服器沒有的原始連結，使用者可以在門戶去釋出該資源，此時，使用者就可以填入一些該資源的描述資訊（這一步要都由公司人員去做，幾乎是不可能的），成千上萬的網民這樣做，門戶內容就豐富了（不僅有視訊，還有視訊的描述資訊等其它一些元資料，前面提到索引方式，如果加上這部分內容的索引，又進一步實現在基於關鍵字的搜尋）這本身又有點WEB2.0的概念，由網友自發來聚集和編輯視訊資訊。

2、 再看看專用連結，比如，你通過雷區找到的資源，有一些連結類似如下形式：

thunder://QUFmdHA6BDCsdi/ry+L1Byaxfdif=

對於這類連結，其實相當於一個對映而已，比如，在上一節的h)步驟中，使用者釋出了一些資源，這個資源在福雷伺服器中找到了一系列等價資源，這個搜尋等價資源的過程是需要消耗伺服器資源的（這個資源是指CPU/記憶體等機器資源），這樣，可以專為該資源生成一個URL，該URL就對應上述連結資訊的索引以及使用者輸入的視訊元資料資訊，這樣，使用者可以很容易通過關鍵字搜到該視訊，同時使用這類URL下載時，沒有一個搜尋等價資源的過程，直接就可以返回一系列伺服器連結到客戶端，直接實現多伺服器下載。

說了這麼多，本來應該畫個框架圖流程圖什麼的，但願說清楚了，有什麼好的想法可以多交流。

來自：