P2P对等网络技术原理整合
P2P（Peer to Peer）對等網絡
P2P技術屬于覆蓋層網絡(Overlay Network)的范疇，是相對于客戶機/服務器(C/S)模式來說的一種網絡信息交換方式。在C/S模式中，數據的分發采用專門的服務器，多個客戶端都從此服務器獲取數據。
優點是：數據的一致性容易控制，系統也容易管理。
缺點是：因為服務器的個數只有一個(即便有多個也非常有限)，系統容易出現單一失效點；單一服務器面對眾多的客戶端，由于CPU能力、內存大小、網絡帶寬的限制，可同時服務的客戶端非常有限，可擴展性差。
P2P技術正是為了解決這些問題而提出來的一種對等網絡結構。在P2P網絡中，每個節點既可以從其他節點得到服務，也可以向其他節點提供服務。這樣，龐大的終端資源被利用起來，一舉解決了C/S模式中的兩個弊端。
P2P應用軟件主要包括文件分發軟件、語音服務軟件、流媒體軟件。目前P2P應用種類多、形式多樣，沒有統一的網絡協議標準，其體系結構和組織形式也在不斷發展。
對等網絡的基本結構
集中式對等網絡基于中央目錄服務器，為網絡中各節目提供目錄查詢服務，傳輸內容無需再經過中央服務器。這種網絡，結構比較簡單，中央服務器的負擔大大降低。但由于仍存在中央節點，容易形成傳輸瓶頸，擴展性也比較差，不適合大型網絡。但由于目錄集中管理，對于小型網絡的管理和控制上倒是一種可選擇方案。
（2）無結構分布式網絡（Gnutella）無結構分布式網絡與集中式的最顯著區別在于，它沒有中央服務器，所有結點通過與相鄰節點間的通信，接入整個網絡。在無結構的網絡中，節點采用一種查詢包的機制來搜索需要的資源。具體的方式為，某節點將包含查詢內容的查詢包發送到與之相鄰的節點，該查詢包以擴散的方式在網絡中蔓延，由于這樣的方式如果不加節制，會造成消息泛濫，因此一般會設置一個適當的生存時間（TTL），在查詢的過程中遞減，當TTL值為0時，將不再繼續發送。
?? 這種無結構的方式，組織方式比較松散，節點的加入與離開比較自由，當查詢熱門內容時，很容易就能找到，但如果需求的內容比較冷門，較小的TTL不容易找到，而較大的TTL值又容易引起較大的查詢流量，尤其當網絡范圍擴展到一定規模時，即使限制的TTL值較小，仍然會引起流量的劇增。但當網絡中存在一些擁有豐富資源的所謂的類服務器節點時，可顯著提高查詢的效率。
（3）結構化分布式網絡（第三代P2P?Pastry、Tapestry、Chord、CAN）??? 結構化分布式網絡，是近幾年基于分布式哈希表（Distributed Hash Table）技術的研究成果。它的基本思想是將網絡中所有的資源整理成一張巨大的表，表內包含資源的關鍵字和所存放結點的地址，然后將這張表分割后分別存儲到網絡中的每一結點中去。當用戶在網絡中搜索相應的資源時，它將能發現存儲與關鍵詞對應的哈希表內容所存放的結點，在該結點中存儲了包含所需資源的結點地址，然后發起搜索的結點根據這些地址信息，與對應結點連接并傳輸資源。這是一種技術上比較先進的對等網絡，它具有高度結構化，高可擴展性，結點的加入與離開比較自由。這種方式適合比較大型的網絡。
(1)DHT結構
??? 分布式哈希表(DHT)[1]是一種功能強大的工具，它的提出引起了學術界一股研究DHT的熱潮。雖然DHT具有各種各樣的實現方式，但是具有共同的特征，即都是一個環行拓撲結構，在這個結構里每個節點具有一個唯一的節點標識(ID)，節點ID是一個128位的哈希值。每個節點都在路由表里保存了其他前驅、后繼節點的ID。如圖1(a)所示。通過這些路由信息，可以方便地找到其他節點。這種結構多用于文件共享和作為底層結構用于流媒體傳輸[2]。
(2)樹形結構 P2P網絡樹形結構如圖1(b)所示。在這種結構中，所有的節點都被組織在一棵樹中，樹根只有子節點，樹葉只有父節點，其他節點既有子節點也有父節點。信息的流向沿著樹枝流動。最初的樹形結構多用于P2P流媒體直播[3-4]。 (3)網狀結構??? 網狀結構如圖1(c)所示，又叫無結構。顧名思義，這種結構中，所有的節點無規則地連在一起，沒有穩定的關系，沒有父子關系。網狀結構[5]為P2P提供了最大的容忍性、動態適應性，在流媒體直播和點播應用中取得了極大的成功。當網絡變得很大時，常常會引入超級節點的概念，超級節點可以和任何一種以上結構結合起來組成新的結構，如KaZaA[6]。
P2P技術應用
(1)分布式科學計算
P2P技術可以使得眾多終端的CPU資源聯合起來，服務于一個共同的計算。這種計算一般是計算量巨大、數據極多、耗時很長的科學計算。在每次計算過程中，任務(包括邏輯與數據等)被劃分成多個片，被分配到參與科學計算的P2P節點機器上。在不影響原有計算機使用的前提下，人們利用分散的CPU資源完成計算任務，并將結果返回給一個或多個服務器，將眾多結果進行整合，以得到最終結果。
(2)文件共享
BitTorrent是一種無結構的網絡協議。除了BitTorrent之外，還有不少著名的無結構化的P2P文件共享協議，典型的有Gnutella[8]和KaZaA[6]。
(3)流媒體直播
(4)流媒體點播
(5)IP層語音通信
Skype采取類似KaZaA的拓撲結構，在網絡中選取一些超級節點。在通信雙方直連效果不好時，一些合適的超級節點則擔當起其中轉節點的角色，為通信雙方創建中轉連接，并轉發相應的語音通信包。
典型P2P應用的機制分析
??????分析典型的P2P應用機制可以深入了解P2P的原理。本節將對文件分發、流媒體應用、語音服務3個領域中具有代表性的軟件機制進行詳細的分析。對于這些軟件的分析有助于理解P2P技術的原理和把握P2P技術未來發展的趨勢。
BitTorrent
??????BitTorrent軟件用戶首先從Web服務器上獲得下載文件的種子文件，種子文件中包含下載文件名及數據部分的哈希值，還包含一個或者多個的索引(Tracker)服務器地址。它的工作過程如下：客戶端向索引服務器發一個超文本傳輸協議(HTTP)的GET請求，并把它自己的私有信息和下載文件的哈希值放在GET的參數中；索引服務器根據請求的哈希值查找內部的數據字典，隨機地返回正在下載該文件的一組節點，客戶端連接這些節點，下載需要的文件片段。因此可以將索引服務器的文件下載過程簡單地分成兩個部分：與索引服務器通信的HTTP，與其他客戶端通信并傳輸數據的協議，我們稱為BitTorrent對等協議。BitTorrent軟件的工作原理如圖4所示。BitTorrent協議也處在不斷變化中，可以通過數據報協議(UDP)和DHT的方法獲得可用的傳輸節點信息，而不是僅僅通過原有的HTTP，這種方法使得BitTorrent應用更加靈活，提高BitTorrent用戶的下載體驗。
eMule
??????eMule軟件基于eDonkey協議改進后的協議，同時兼容eDonkey協議。每個eMule客戶端都預先設置好了一個服務器列表和一個本地共享文件列表，客戶端通過TCP連接到eMule服務器進行登錄，得到想要的文件的信息以及可用的客戶端的信息。一個客戶端可以從多個其他的EMule客戶端下載同一個文件，并從不同的客戶端取得不同的數據片段。eMule同時擴展了eDonkey的能力，允許客戶端之間互相交換關于服務器、其他客戶端和文件的信息。eMule服務器不保存任何文件，它只是文件位置信息的中心索引。eMule客戶端一啟動就會自動使用傳輸控制協議(TCP)連接到eMule服務器上。服務器給客戶端提供一個客戶端標識(ID)，它僅在客戶端服務器連接的生命周期內有效。連接建立后，客戶端把其共享的文件列表發送給服務器。服務器將這個列表保存在內部數據庫內。eMule客戶端也會發送請求下載列表。連接建立以后，eMule服務器給客戶端返回一個列表，包括哪些客戶端可以提供請求文件的下載。然后，客戶端再和它們主動建立連接下載文件。圖5所示為eMule的工作原理。
??????eMule基本原理與BitTorrent類似，客戶端通過索引服務器獲得文件下載信息。eMule同時允許客戶端之間傳遞服務器信息，BitTorrent只能通過索引服務器或者DHT獲得。eMule共享的是整個文件目錄，而BitTorrent只共享下載任務，這使得BitTorrent更適合分發熱門文件，eMule傾向于一般熱門文件的下載。
迅雷
??????迅雷是一款新型的基于多資源多線程技術的下載軟件，迅雷擁有比目前用戶常用的下載軟件快7～10倍的下載速度。迅雷的技術主要分成兩個部分，一部分是對現有Internet下載資源的搜索和整合，將現有Internet上的下載資源進行校驗，將相同校驗值的統一資源定位(URL)信息進行聚合。當用戶點擊某個下載連接時，迅雷服務器按照一定的策略返回該URL信息所在聚合的子集，并將該用戶的信息返回給迅雷服務器。另一部分是迅雷客戶端通過多資源多線程下載所需要的文件，提高下載速率。迅雷高速穩定下載的根本原因在于同時整合多個穩定服務器的資源實現多資源多線程的數據傳輸。多資源多線程技術使得迅雷在不降低用戶體驗的前提下，對服務器資源進行均衡，有效降低了服務器負載。
??????每個用戶在網上下載的文件都會在迅雷的服務器中進行數據記錄，如有其他用戶再下載同樣的文件，迅雷的服務器會在它的數據庫中搜索曾經下載過這些文件的用戶，服務器再連接這些用戶，通過用戶已下載文件中的記錄進行判斷，如用戶下載文件中仍存在此文件(文件如改名或改變保存位置則無效)，用戶將在不知不覺中扮演下載中間服務角色，上傳文件。
PPLive
??????PPLive軟件的工作機制和BitTorrent十分類似，PPLive將視頻文件分成大小相等的片段，第三方提供播放的視頻源，用戶啟礬PPLive以后，從PPLive服務器獲得頻道的列表，用戶點擊感興趣的頻道，然后從其他節點獲得數據文件，使用流媒體實時傳輸協議(RTP)和實時傳輸控制協議(RTCP)進行數據的傳輸和控制。將數據下載到本地主機后，開放本地端口作為視頻服務器，PPLive的客戶端播放器連接此端口，任何同一個局域網內的用戶都可以通過連接這個地址收看到點播的節目。圖6所示為PPLive的工作原理示意圖。
Skype
??????Skype是網絡語音溝通工具。它可以提供免費高清晰的語音對話，也可以用來撥打國內國際長途，還具備即時通訊所需的其他功能，比如文件傳輸、文字聊天等。Skype是在KaZaA的基礎上開發的，就像KaZaA一樣，Skype本身也是基于覆蓋層的P2P網絡，在它里面有兩種類型的節點：普通節點和超級節點。普通節點是能傳輸語音和消息的一個功能實體；超級節點則類似于普通節點的網絡網關，所有的普通節點必須與超級節點連接，并向Skype的登陸服務器注冊它自己來加入Skype網絡。Skype的登陸服務器上存有用戶名和密碼，并且授權特定的用戶加入Skype網絡，圖7所示為Skype的體系結構[18]。
??????Skype的另一個突出特點就是能夠穿越地址轉換設備和防火墻。Skype能夠在最小傳輸帶寬32 kb/s的網絡上提供高質量的語音。Skype是使用P2P語音服務的代表。由于其具有超清晰語音質量、極強的穿透防火墻能力、免費多方通話以及高保密性等優點，成為互聯網上使用最多的P2P應用之一。
P2P實現的原理
首先先介紹一些基本概念： ??? NAT(Network Address Translators)，網絡地址轉換：網絡地址轉換是在IP地址日益缺乏的情況下產生的，它的主要目的就是為了能夠地址重用。NAT從歷史發展上分為兩大類，基本的NAT和NAPT(Network Address/Port Translator)。 ??? 最先提出的是基本的NAT(peakflys注：剛開始其實只是路由器上的一個功能模塊)，它的產生基于如下事實：一個私有網絡（域）中的節點中只有很少的節點需要與外網連接（這是在上世紀90年代中期提出的）。那么這個子網中其實只有少數的節點需要全球唯一的IP地址，其他的節點的IP地址應該是可以重用的。 因此，基本的NAT實現的功能很簡單，在子網內使用一個保留的IP子網段，這些IP對外是不可見的。子網內只有少數一些IP地址可以對應到真正全球唯一的IP地址。如果這些節點需要訪問外部網絡，那么基本NAT就負責將這個節點的子網內IP轉化為一個全球唯一的IP然后發送出去。(基本的NAT會改變IP包中的原IP地址，但是不會改變IP包中的端口) 關于基本的NAT可以參看RFC 1631 另外一種NAT叫做NAPT，從名稱上我們也可以看得出，NAPT不但會改變經過這個NAT設備的IP數據報的IP地址，還會改變IP數據報的TCP/UDP端口。基本NAT的設備可能我們見的不多（基本已經淘汰了），NAPT才是我們真正需要關注的。看下圖：
有一個私有網絡10.*.*.*，Client A是其中的一臺計算機，這個網絡的網關（一個NAT設備）的外網IP是155.99.25.11(應該還有一個內網的IP地址，比如10.0.0.10)。如果Client A中的某個進程（這個進程創建了一個UDP Socket,這個Socket綁定1234端口）想訪問外網主機18.181.0.31的1235端口，那么當數據包通過NAT時會發生什么事情呢？ 首先NAT會改變這個數據包的原IP地址，改為155.99.25.11。接著NAT會為這個傳輸創建一個Session（Session是一個抽象的概念，如果是TCP，也許Session是由一個SYN包開始，以一個FIN包結束。而UDP呢，以這個IP的這個端口的第一個UDP開始，結束呢，呵呵，也許是幾分鐘，也許是幾小時，這要看具體的實現了）并且給這個Session分配一個端口，比如62000，然后改變這個數據包的源端口為62000。所以本來是 （10.0.0.1:1234->18.181.0.31:1235）的數據包到了互聯網上變為了（155.99.25.11:62000->18.181.0.31:1235）。 一旦NAT創建了一個Session后，NAT會記住62000端口對應的是10.0.0.1的1234端口，以后從18.181.0.31發送到62000端口的數據會被NAT自動的轉發到10.0.0.1上。（注意：這里是說18.181.0.31發送到62000端口的數據會被轉發，其他的IP發送到這個端口的數據將被NAT拋棄）這樣Client A就與Server S1建立以了一個連接。 上面的是一些基礎知識，下面的才是關鍵的部分了。 看看下面的情況：
接上面的例子，如果Client A的原來那個Socket(綁定了1234端口的那個UDP Socket)又接著向另外一個Server S2發送了一個UDP包，那么這個UDP包在通過NAT時會怎么樣呢？ 這時可能會有兩種情況發生，一種是NAT再次創建一個Session，并且再次為這個Session分配一個端口號（比如：62001）。另外一種是NAT再次創建一個Session，但是不會新分配一個端口號，而是用原來分配的端口號62000。前一種NAT叫做Symmetric NAT，后一種叫做Cone NAT。如果你的NAT剛好是第一種，那么很可能會有很多P2P軟件失靈。（可以慶幸的是，現在絕大多數的NAT屬于后者，即Cone NAT） peakflys注：Cone NAT具體又分為3種： (1)全圓錐( Full Cone) : NAT把所有來自相同內部IP地址和端口的請求映射到相同的外部IP地址和端口。任何一個外部主機均可通過該映射發送IP包到該內部主機。 (2)限制性圓錐(Restricted Cone) : NAT把所有來自相同內部IP地址和端口的請求映射到相同的外部IP地址和端口。但是,只有當內部主機先給IP地址為X的外部主機發送IP包,該外部主機才能向該內部主機發送IP包。 (3)端口限制性圓錐( Port Restricted Cone) :端口限制性圓錐與限制性圓錐類似,只是多了端口號的限制,即只有內部主機先向IP地址為X,端口號為P的外部主機發送1個IP包,該外部主機才能夠把源端口號為P的IP包發送給該內部主機。 好了，我們看到，通過NAT,子網內的計算機向外連結是很容易的（NAT相當于透明的，子網內的和外網的計算機不用知道NAT的情況）。 但是如果外部的計算機想訪問子網內的計算機就比較困難了（而這正是P2P所需要的）。 那么我們如果想從外部發送一個數據報給內網的計算機有什么辦法呢？首先，我們必須在內網的NAT上打上一個“洞”（也就是前面我們說的在NAT上建立一個Session），這個洞不能由外部來打，只能由內網內的主機來打。而且這個洞是有方向的，比如從內部某臺主機（比如：192.168.0.10）向外部的某個IP(比如：219.237.60.1)發送一個UDP包，那么就在這個內網的NAT設備上打了一個方向為219.237.60.1的“洞”，（這就是稱為UDP Hole Punching的技術）以后219.237.60.1就可以通過這個洞與內網的192.168.0.10聯系了。（但是其他的IP不能利用這個洞）。
P2P的常用實現
一、普通的直連式P2P實現 通過上面的理論，實現兩個內網的主機通訊就差最后一步了：那就是雞生蛋還是蛋生雞的問題了，兩邊都無法主動發出連接請求，誰也不知道誰的公網地址，那我們如何來打這個洞呢？我們需要一個中間人來聯系這兩個內網主機。 現在我們來看看一個P2P軟件的流程，以下圖為例： 首先，Client A登錄服務器，NAT A為這次的Session分配了一個端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，這就是Client A的外網地址了。同樣，Client B登錄Server S，NAT B給此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。 此時，Client A與Client B都可以與Server S通信了。如果Client A此時想直接發送信息給Client B，那么他可以從Server S那兒獲得B的公網地址187.34.1.56:40000，是不是Client A向這個地址發送信息Client B就能收到了呢？答案是不行，因為如果這樣發送信息，NAT B會將這個信息丟棄（因為這樣的信息是不請自來的，為了安全，大多數NAT都會執行丟棄動作）。現在我們需要的是在NAT B上打一個方向為202.187.45.3（即Client A的外網地址）的洞，那么Client A發送到187.34.1.56:40000的信息,Client B就能收到了。這個打洞命令由誰來發呢？自然是Server S。 總結一下這個過程：如果Client A想向Client B發送信息，那么Client A發送命令給Server S，請求Server S命令Client B向Client A方向打洞。然后Client A就可以通過Client B的外網 地址與Client B通信了。 注意：以上過程只適合于Cone NAT的情況，如果是Symmetric NAT，那么當Client B向Client A打洞的端口已經重新分配了，Client B將無法知道這個端口（如果Symmetric NAT的端口是順序分配的，那么我們或許可以猜測這個端口號，可是由于可能導致失敗的因素太多，這種情況下一般放棄P2P ?---peakflys）。
二、STUN方式的P2P實現 STUN是RFC3489規定的一種NAT穿透方式，它采用輔助的方法探測NAT的IP和端口。毫無疑問的，它對穿越早期的NAT起了巨大的作用，并且還將繼續在NAT穿透中占有一席之地。 STUN的探測過程需要有一個公網IP的STUN server，在NAT后面的UAC必須和此server配合，互相之間發送若干個UDP數據包。UDP包中包含有UAC需要了解的信息，比如NAT外網IP，PORT等等。UAC通過是否得到這個UDP包和包中的數據判斷自己的NAT類型。 假設有如下UAC（B），NAT（A），SERVER（C），UAC的IP為IPB，NAT的IP為 IPA ，SERVER的 IP為IPC1 、IPC2。請注意，服務器C有兩個IP，后面你會理解為什么需要兩個IP。 (1)NAT的探測過程 STEP1：B向C的IPC1的port1端口發送一個UDP包。C收到這個包后，會把它收到包的源IP和port寫到UDP包中，然后把此包通過IP1C和port1發還給B。這個IP和port也就是NAT的外網IP和port，也就是說你在STEP1中就得到了NAT的外網IP。 熟悉NAT工作原理的應該都知道，C返回給B的這個UDP包B一定收到。如果在你的應用中，向一個STUN服務器發送數據包后，你沒有收到STUN的任何回應包，那只有兩種可能：1、STUN服務器不存在，或者你弄錯了port。2、你的NAT設備拒絕一切UDP包從外部向內部通過，如果排除防火墻限制規則，那么這樣的NAT設備如果存在，那肯定是壞了?? 當B收到此UDP后，把此UDP中的IP和自己的IP做比較，如果是一樣的，就說明自己是在公網，下步NAT將去探測防火墻類型，就不多說了(下面有圖)。如果不一樣，說明有NAT的存在，系統進行STEP2的操作。 STEP2：B向C的IPC1發送一個UDP包，請求C通過另外一個IPC2和PORT（不同與SETP1的IP1）向B返回一個UDP數據包（現在知道為什么C要有兩個IP了吧，為了檢測cone NAT的類型）。 我們來分析一下，如果B收到了這個數據包，那說明什么？說明NAT來著不拒，不對數據包進行任何過濾，這也就是STUN標準中的full cone NAT。遺憾的是，full cone nat太少了，這也意味著你能收到這個數據包的可能性不大。如果沒收到，那么系統進行STEP3的操作。 STEP3：B向C的IPC2的port2發送一個數據包，C收到數據包后，把它收到包的源IP和port寫到UDP包中，然后通過自己的IPC2和port2把此包發還給B。 和step1一樣，B肯定能收到這個回應UDP包。此包中的port是我們最關心的數據，下面我們來分析： 如果這個port和step1中的port一樣，那么可以肯定這個NAT是個CONE NAT，否則是對稱NAT。道理很簡單：根據對稱NAT的規則，當目的地址的IP和port有任何一個改變，那么NAT都會重新分配一個port使用，而在step3中，和step1對應，我們改變了IP和port。因此，如果是對稱NAT,那這兩個port肯定是不同的。 如果在你的應用中，到此步的時候PORT是不同的，那就只能放棄P2P了，原因同上面實現中的一樣。如果不同，那么只剩下了restrict cone 和port restrict cone。系統用step4探測是是那一種。 STEP4：B向C的IP2的一個端口PD發送一個數據請求包，要求C用IP2和不同于PD的port返回一個數據包給B。 我們來分析結果：如果B收到了，那也就意味著只要IP相同，即使port不同，NAT也允許UDP包通過。顯然這是restrict cone NAT。如果沒收到，沒別的好說，port restrict NAT. 協議實現的算法運行圖如下：
一旦路經到達紅色節點時，UDP的溝通是沒有可能性的(peakflys注：準備來說除了包被防火墻blocked之外，其他情況也是有可能建立P2P的，只是代價太大，一般放棄)。一旦通過黃色或是綠色的節點，就有連接的可能。 最終通過STUN服務器得到自己的NAT類型和公網IP、Port，以后建立P2P時就非常容易了。
參考文章：
P2P技術原理：http://www.360doc.com/content/14/0305/17/8285430_357987074.shtml
P2P技術現狀及發展未來：http://www.zte.com.cn/cndata/magazine/zte_communications/2007/6/magazine/200712
P2P原理及其常用的實現方式：http://www.cppblog.com/peakflys/archive/2013/01/25/197562.html
總結
以上是生活随笔為你收集整理的P2P对等网络技术原理整合的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kubernetes--k8s--进阶-
- 下一篇： T48566 【zzy】yyy点餐