我是誰？我是已經解散了的迅雷極速版項目組的一員，目前我已經離職。
對于迅雷這個公司，我有很多話說，對于極速版這個項目，我有很多感情
對于迅雷，我
但是今天，我只想告訴你真實的迅雷
迅雷是國內唯一支持內網p2p技術的軟件，唯一針對移動 電信等寬帶的大內網做了優化的下載軟件
只要開啟路由器的upnp功能，就不會對速度有限制
但迅雷也只是一個軟件而已，不可能逃過運營商的封鎖，
對于國內來說，這些都不是透明的，但是在香港地區的運營商會直接寫明屏蔽了p2p協議
運營商屏蔽迅雷p2p有4種手段
屏蔽磁力服務器解析，導致磁力鏈解析失敗
屏蔽p2p網絡，導致只能從原始地址下載，速度緩慢甚至速度為0
全局QOS策略導致迅雷資源充足甚至開會員也不能滿速下載
定時QOS策略，在網絡高峰期限制，其他時間解除
其中全局QOS策略在電信網絡中最常見
電信已經瘋了，在一個省出口才1000多G的情況下大量開發百M甚至千M用戶，導致出口堵塞；然后用QOS強制降低出口負載，導致整體網絡運行緩慢
電信真的瘋了。
很多人都說迅雷限速
其實我們真的冤枉，我們不計成本的打造了國內最大的p2p網絡，成為寬帶運營商的眼中釘。
由于p2p網絡的共享性，資源并不在迅雷的服務器中，迅雷根本就沒必要也不需要限速
我們從一開始就是要做最快的下載軟件，而不是最慢的
非常多的人反映過，開會員也不能滿速。
這個鍋，我們不背。
由于全局QOS限速策略，現在的寬帶根本就不達標
而之所以測速達標；呵呵，你覺得除了運營商誰能提供高達千兆的測速服務器？懂了嗎
迅雷會員只是從p2p網絡之外再加上迅雷服務器的速度，但是迅雷并不能改變你的寬帶質量，更不能解除運行商的限制
傷硬盤是一個怪異的說法，迅雷下載也不過是寫入數據，跟其他任何下載軟件都一樣
并且迅雷一直提供緩存的設置，系統也會對數據進行緩存，傷硬盤從何談起
有時候我們會遇到下載失敗的情況，但是瀏覽器卻可以下載。
這是因為，迅雷是一個多線程下載軟件，并且原始地址數默認是5，這樣可以提高下載速度
但是有些服務器會限制只允許單線程下載
這也就導致迅雷多線程探測服務器而被服務器屏蔽
手動改為1即可解決下載失敗問題
35.366是迅雷項目最后一個版本，并且沒有正式發布
358版本可以在迅雷官網下載
360版本可以在迅雷陽臺下載
而366作為最后一個版本，我們把名字從迅雷極速改為了極速迅雷；因為他再也不會更新了。
下載其實也很簡單
只要把360那個鏈接手動改為35.366即可
迅雷9發布了，感慨萬千
因為迅雷放棄了對極速版純粹下載的的追求
確實，對于迅雷現在的公司規模和盈利模式，不得不需要一些改變
期待迅雷下一次的蛻變吧
（順便把欠我的工資發完啊啊啊啊 ）
我們周圍一切幾乎都依賴于把事情抽象成低等級，并在某一點把它具體化，在一些設計概念中，接口層十分清晰并且目標很集中，應用程序不用考慮操作系統如何工作，操作系統也不用考慮硬件如何工作，OSI模型的第4層不需要考慮第三層如何工作。所以我們只需要集中精力在某一層，就當下面的層正常工作，但這樣能行嗎？如果你寫一個應用，你最好知道OS是怎么樣工作的，并且要考慮數據庫如何存儲字符的，同樣，一個好的操作系統必需要了解硬件是如何工作的。如果你認為TCP不需要考慮IP的實現那就搞錯了。 所以，這里即使我們假設web應用和服務都運行在OSI第7層，現在我們住下面走走，到第4層（或更低層），看看那里在干什么。我們會討論TCP和UDP的區別，什么是組播（multicast），它如何工作與如何不工作。相信我，這些東西很有用。
先說一下HTTP，我們現在正在用的直接與這個協議相關，HTTP和一些其它網絡應用（SQL*NET， WCI搜索）一起工作在網絡第7層，應用層，在第4層的TCP之上，那什么是TCP呢？ TCP（傳輸控制協議）和UDP是internet的主要低層網絡協議。它們都建立在另一層IP（Internet協議）之上，IP比它們差一層，在第3層。所以要理解TCP，要先看下IP，然后再回頭看看TCP在上面干什么。
IP：(Internet協議）
IP擁有把一個數據包從一個地方發送到另一個地方的能力，通過提供一種”地方“或“設備”一個特定的地址（IP地址），并指定怎樣通過地址在設備之間移動數據包來實現這個協議。現在，IP和下一層的協議之間的區別在于，在第2層的設備總是確切知道如何給其它網絡設備發送信息，（第2層為鏈路層，通常表示為以太網或WiFi）在第2層，設備不但知道怎樣發送數據到目的地（通常由MAC地址表示地址），同時也知道是否數據能不能到達目的地。（舉個例子，以太網和WiFi簡單地把整個數據包廣播到整個網絡，目的設備假設都在監聽這個MAC地址，然后提取數據包，如果目的地不存在或者不在監聽，以太網數據就無法到達。順便提下，網絡“嗅探器”正是利用這個廣播機制來工作。用于調制解調器撥號連接的PPP協議可以發送任何東西到單個目標：你撥號的號碼。
IP提供了發送數據到其它網絡的途徑，一個設備不需要知道具體路徑就可以把一個東西到另一個到另一個網絡，這就是“inter-net ”的由來：“在網絡之間”。它通過指定一個路由規則，定義一個帶有目標地址的數據包。這是基本的規則：如果目標在本地就直接發送（你知道目標在哪，因為它們在同一個網絡），否則在一堆路由列表中找一個地址來發送。一個路由只遵守一個協議，除非地址同時屬于兩個或多個不同的網絡，這種情況下會有不同的本地目的地址，也會產生一個更長的路由列表指向更多的未知地址。 目前為止，IP除了可以發送單個數據包到單個地址外不能干其它任何事情，當然它可以接收從任何一個網絡發過來的包（不像其它低級的協議），但僅此而已。明顯缺點如下：
IP不提供發送、接收、出錯等通知。
IP不提供“端口號”之類的標記來隔離發到目標IP地址的數據包。
IP不提供雙向通訊。
IP不會用任何方式對多個包排序或分組。
最簡單的比喻是IP好比郵政服務，你住郵箱里扔一張帶地址的明信片，然后它就照著你寫的地址寄過去了，寄到，或者沒寄到，你并不知道。當明信片寄到時家時，你并不知道別的室友是不是讀過它了。如果你想到一個回復，你的收件人不能在同一個卡片上寫東西然后還給郵遞員，他們要在自己的卡片上寫字，貼上郵票，寫上地址，最后自己寄出。
TCP：傳輸控制協議
雖然IP協議不提供這些功能，但TCP可以。如果你先看一下IP不提供的那些特性，再看看郵遞然后可以說：“嗯？當然可以做雙向通信！人們寫信來來回回就像一直在對話一樣”。或者，“你可以直接要求收信人或者郵局給你回一封信”。或者說：“算了笨蛋，你可以把明信片標上數字記號然后告訴收信人按順序閱讀，如果有丟失就告訴你”。好吧，你是對的，這就是TCP做的事情。它使用基本的IP（或郵政服務）并指定通過何種方式添加一些附加信息，以便實現這些特性。 所以，TCP真正解決的是如何實現在多個IP設備間進行可靠的多次通信。神馬意思？這意味著你可以發送一系列消息（包），基于一個選定的會話（端口或連接），這個包會以同樣的順序接收，發送時不會丟包，同樣也不會有重復。 它是這樣做的：給所有的包都寫一個端口號，用來把其它連接和會話區別開，同時給每個包一個序列號，接收方就能知道傳輸中是否有丟失。之后，TCP指定接收方響應每個接收的數據（并不強制每個包都響應，可以簡單的回復：“我收到第13456個字節之前的全部數據，或者“我收到845到13433之間的數據”），這樣發送方就知道是否要重新發送。最后，通信是雙向的，不僅僅有應答，還可以讓接收方不用指定地址就可以直接住回發信息，有點像給每個包附加一個寫好自己地址的回復信封。 可以看到，如果丟包或順序不對，TCP實際上需要做很多工作。如果我們繼續郵局理論，TCP就像一個私人助理，他幫你收集、分類郵件，排好序，獲取并閱讀，再回復回去。如果郵政服務超級可靠，TCP的任務就很簡單，只需要做一個中間人把文件分發出去就好，如果郵政服務損失了許多員工，或者有很多郵件要處理，TCP就要做很多工作，把丟失的包發回去，跟蹤并存儲許多信息。
UDP：用戶數據協議
UDP就比TCP簡單多了， 它和IP做的一樣，并加上端口的概念，這樣你就把消息發給另一個有IP地址的接收者。它沒有順序或連接，或雙向連接，也沒有應答。 你應該會認為UDP不靠譜，因為你知道TCP是一個可靠的連接方案，但是實際上在同一個網段，或者在信號很好的局域網，UDP實際上是非常可靠的。如沒有丟包并包的按順序依次到達（這個幾乎是短局域網的常態），并不需要重新傳輸包，所以TCP的所有應答和等待只會浪費時間，增加網絡延時。對于可以包容丟包的應用（實時音頻和視頻）來說，即使網絡不給力，UDP也通常是一個好方案。它也經常用于小消息和通知。比如DHCP和DNS都使用UDP。值得一提的是，Unix網絡文件系統（NFS）在局域網使用的是UDP。可能你覺得一個文件系統應該需要一個可靠的TCP連接，但是NFS的實現者覺得用UDP可以得到更好的性能，并建立一個專門的機制來保證可靠性。 順便提一下，它被稱作“用戶數據報協議”是有原因的，因為它是由一幫系統管理員設計的。“數據報”是“包”的另一個名字，“用戶”沒有什么實際意思，就和“你”一樣。就是說這個計算機程序和操作系統沒什么關系。原因是低級的IP是寫OS的人寫，但是UDP提供了許多和數據報相同的功能，為“用戶”程序（非OS）服務。
多播（Multicasting）
這里可以簡化下TCP/IP/UDP的相關討論，默認我們知道IP（UDP和TCP一樣)可以把數據包在一個網絡中發到另一個設備。更準確點就是IP把數據包從一個IP地址發到另一個IP地址。多播的決竅就是在同一時間把一個數據包發送到多個設備，可以把一個特定的IP地址指定為多播地址，并同時發送到多個設備。
IP多播首先要知道的是只有UDP有多播，沒有TCP多播這樣的東西，為什么呢？多播的重點是高效的把同一個包盡可能多的發送到不同的，甚至可能是未知的設備。但是TCP連接可能要求丟包重發或者延時或重組順序，這些操作可能非常消耗資源，不適于許多使用多播的應用場景。（同時多播不知道發出的包是不是已經到達，這個也導致不能使用TCP）。
參考前面的知道，常用的非多播的UDP（TCP）消息叫做單播（unicast）。
下面我們需要知道多播經常沒法通過路由發到另一個網絡。下面是部分原因：
多數多播包的TTL比較低: 所有的IP包都有一個“生存時間”（time-to-live）,或者叫TTL。和DNS記錄不一樣，TTL指定一個包到達目的地之前跳過網絡的最大次數。單播包通常被允許穿越30個網絡（比如，被路由或”跳“過29個路由），穿過網絡通常小于15次”跳越“，所以30的限制經常用于當網絡配置的很爛時把數據包殺掉。但是許多程序發多播時把TTL設為一個很低的值，通常為0（這樣消息不會離開自身的設備）。
設置為1表示只能發到本地網絡的計算機，設置為2 表示只能穿過一個路由。很少有應用想把多播發給整個校園網絡的未知設備，更不會發給整個網絡。
諸多路由都設置了很高的TTL閾值：很多網絡路由器，特別是WAN路由和internet網關路由都有很高的TTL閾值，這樣它們就不會發送這些低TTL（如15）的多播包。這樣可以防止多播從本地網絡泄漏。
路由器一般配置成完全不發送多播，或只發一些特定的地址，或配置成阻塞多播包。
UDP多播可能有點過于邪惡，但是它使用的次數可能遠遠超出你的預計。它不會用于網絡視頻網站比如YouTube，因為它需要當用戶點播時再發送視頻，而不是同時發給所有的用戶，同樣也不用于VoIP語音。它用于很多發現和自動配置，如Skype, iTunes 和 uPnP，也偶爾用于WCI入口。
大家如果對編程感興趣，想了解更多的編程知識，解決編程問題，我們這里有java高手，C++/C高手，windows/Linux高手，android/ios高手，請大家關注我的微信公眾號：程序員互動聯盟或者coder_online