把自己對p2p的一些理解和看法整理下，一來是幫助自己回顧下，二來希望能爲之後用到的同學起到一個指引的作用。
什麼是P2P？
此處要跟大家介紹的P2P不是常聽到的金融P2P，它是Peer-to-Peer的簡寫，即對等網絡技術，但我更願意稱之爲媒體數據分發技術，通過p2p可以傳輸音視頻數據、文件、圖片等對象 。p2p的最大特點就是去中心化，每個p2p節點既是客戶端同時又扮演服務器的角色，資源的所有權和控制權被分散到p2p網絡的每一個節點上。
P2P與傳統CDN的區別？
CDN即內容分發網絡，它是一種樹狀多層級網絡結構，這種方式的優勢是內容的傳輸更快捷、穩定，但客戶端與服務器之間採用CS模式進行數據的交互，併發處理能力受限於CDN邊緣節點規模及帶寬上限。而p2p是基於網狀拓撲結構的對等網絡，不再單一從某一個服務器獲取數據，p2p網內各節點均可爲其他節點供流，充分挖掘了Internet上的空閒資源 ,這樣可極大減輕服務器壓力。
P2P的應用場景
其實p2p技術早就出現在我們經常使用的軟件產品中了，比如早些年流行的下載軟件比特精靈、電驢以及現在仍然如日中天的迅雷等，還要提供在線視頻服務的pplive、PPStream和快播等，這些產品給人的一個共同感受就是在線人數越多下載速度或者緩衝速度就越快，下載或者播放就越流暢，這就是因爲p2p網內節點多了可供獲取數據的源頭就多了，這樣我需要的數據就能很快的得到。現在直播領域也用上了P2P來節省服務器帶寬成本。
P2P的技術原理
不同P2P技術方案商他們的實現原理大致上是一樣的，基本都包含了內容處理系統、資源調度及管理系統、節點管理系統以及數據處理系統(終端)，不同的是具體的策略和算法。
P2P節點請求播放url後，服務器會根據該節點信息(地域、運營商等)爲其分配最合適(就近、同一運營商原則)的超級節點，連上超級節點後直接拉取視頻數據開始播放，同時超級節點會根據一定的策略將其加入到已有的分組中並通知該節點，該節點獲取到分組信息後嘗試與組內其他節點建立連接(穿透)，連接成功了開始將其已經下載到的視頻數據分享給其他節點同時也會收到來自其他節點的數據包，這樣其本身從超級節點拉取的數據就會減少，節點間以及節點與服務器之間仍會週期性發送心跳包以保持長連接；當組內有節點退出時，服務器在指定時段內未接受心跳包會將該節點踢出分組，同時廣播方式更新分組信息到該組其他成員，在此期間其他成員會接收不到本應由該節點分享的數據，在等待超時後他們會直接從超級節點請求那部分數據，新的分組信息更新到全員後，需分享的視頻數據重新由當前組內成員承擔。當節點拿到分片數據後會按照數據自帶索引將它們拼裝、還原成原始視頻流交由播放器解碼、上屏出畫面。
每個節點負責從超級節點獲取不同的碼片，然後分享給組內其他節點，這樣避免不同節點分享重複的數據，一旦其中某個節點掉隊了導致其他節點無法及時得到由他負責的那部分數據，那麼數據分發策略會保證其他節點馬上改變路由轉向去找超級節點要數據(每個超級節點擁有一份完整的數據)。
先通過下圖對比CDN的數據流走向來看下P2P的數據分發模式：
CDN數據流走向圖： 
P2P數據分發模式： 
P2P的這種數據分發模式可減少客戶端向服務器請求數據的次數，依靠節點間的互相分享最終仍能拿到一份完整的視頻數據，從而保證其播放效果跟從訪問CDN一樣。
P2P數據流走向圖： 
內容處理系統：
- 1.負責接收原始流媒體數據，通過私有協議對其進行切片(P2P網絡中傳輸的最小數據單位)，打上索引號；
- 2.對原始碼流進行轉碼處理(按需求而定，非必選流程)
- 3.推送分片數據到各p2p超級節點，供終端節點在需要時直接訪問。
資源調度及管理系統：
- 1.監聽各p2p服務器(包括超級節點)的負載狀況，如硬件資源佔用、系統負荷、帶寬消耗等；
- 2.動態調整各p2p服務器上任務的執行，保證整個系統內部的負載均衡；
節點管理系統：
- 1.收集節點信息，如地域、網絡運營商、上下行速率、丟包率等；
- 2.管理節點行爲，如節點註冊，節點分組，節點穿透，與節點保持長連接，探測節點心跳成功率，節點上下線等；
- 3.節點間數據分享策略，如節點心跳減弱即可減少需要其分享的分片數據；
數據處理系統(終端)：
- 1.接收和緩存從其他節點(包括超級節點和普通節點)獲取的分片數據，並按照索引值拼裝成連續完整的碼片序列；
- 2.將已獲取到的數據分享給組內其他節點。
- 3.對拼裝後的碼片序列按照私有協議進行還原得到原始視頻數據，本地可選擇是否需要更換視頻封裝格式已提高解碼兼容性；
直播場景特別是遊戲、秀場等互動性強的場景下P2P效果的幾個度量指標
- 1.播放延遲
- 2.播放出畫面速度
- 3.播放流暢度
- 4.分享率
- 5.服務器併發能力
保證P2P效果的幾個關鍵點
- 1.準確評估節點上行能力，動態調整其分享數據大小
- 2.組內節點變化頻繁時的處理策略(容錯機制)；
- 3.對稱型網絡(NAT)的穿透；
展望：CDN+P2P
新一代融合CDN在傳統CDN基礎上加入了P2P，二者之間可以互補，P2P播放受阻或失敗的時候可以自動切換CDN繼續播放保證體驗不受影響 ，CDN的邊緣節點可以擔任P2P超級節點的角色，而P2P的接入又可以減少對CDN的流量消耗。
結尾
如有理解上的誤區懇請各位指正，也歡迎大家一起交流。
附: 移動端p2p測試指導
移動端p2p接入現狀：
- Android：星雲p2p、騰訊雲p2p、網宿p2p
- iOS: 騰訊雲p2p、網宿p2p
拉流接口中p2p標誌字段：
1. 接口：/lapi/live/appGetPlayer/stream/房間id
2. p2p字段：Android(1代表星雲p2p，2代表騰訊雲p2p，3代表網宿p2p，0代表未開啓p2p)， iOS(1代表騰訊雲p2p，2代表網宿p2p，0代表未開啓p2p)
3. 樣例：
判斷p2p播放成功與否：
1. Android：adb shell logcat |grep -iE “p2pconfig|qcloud|setDataSource|venus” 或者用Android Studio來過濾日誌，檢查sdk加載是否成功，傳給播放器的url是否是”http://127.0.0.1:****.flv”的格式，如下圖：
2. iOS：Mac上通過控制檯過濾關鍵字“qcloud”(騰訊雲p2p)或者“DYP2PSDK”(網宿p2p)，同樣通過日誌檢查sdk加載是否成功，如下圖：
網宿p2p:
幾家p2p的區別：
- 星雲p2p：不支持對稱型網絡，故公司內網無法成功走進p2p播放(F4棟樓下三作咖啡wifi支持)，支持局域網內數據分享，不支持移動數據網(2/3/4G)
- 騰訊雲p2p：支持對稱型網絡，支持局域網內數據分享，不支持移動數據網(2/3/4G)
- 網宿p2p：支持對稱型網絡，支持局域網內數據分享，不支持移動數據網(2/3/4G)
遇到過的坑：
1. Android客戶端，騰訊雲p2p播放過程中切換到音頻播放，p2p sdk未停止仍然繼續收發數據
註釋：通過UI層難發現該問題，需結合日誌判斷sdk的加載和釋放是否成功，故p2p測試過程中儘可能讓開發打印詳細過程日誌
2. Android客戶端，觀看開啓星雲P2P直播間時，安卓客戶端出現crash
註釋：播放器心跳數據採集時上層應用請求sdk接口獲取相關數據，由於第三方sdk沒有提供該方法，從而觸發第三方庫崩潰。同時因爲鬥魚辦公室環境網絡nat類型是對稱型的，進入sdk後會回退到cdn，而未觸發P2P，所以當時內網測試未出現crash。
3. iOS客戶端，騰訊雲p2p播放過程存在內存泄漏
註釋：通過xcode的instrument工具(需源碼)分析發現騰訊p2p sdk運行時有內存泄漏風險，功能測試時可通過查看進程內存消耗變化來判斷此類問題
4. 播放p2p直播間時按HOME鍵壓後臺再立即切回，畫面一直顯示加載中，看日誌顯示p2p一直在正常收發數據，但播放無法自動恢復
註釋：正常情況p2p後臺播放恢復到前臺播放時無需重新給播放器設置流地址，此問題非p2p sdk導致，屬於上層應用處理不當導致
5.ipad版本騰訊雲p2p播放過程中切換到硬解碼播放一段時間後畫面凍屏，聲音輸出正常
註釋：由於各家p2p在媒體數據上均做了處理，將從cdn和p2p節點獲取到的碼片在客戶端本地做了拼接及封裝，且最終輸出的格式可以是flv也可能是m3u8，因此對視頻流的解碼兼容性上需覆蓋不同型號的芯片(軟解碼覆蓋不同cpu型號，硬解碼覆蓋不同GPU型號)和不同的系統版本(特別是定製化的系統如華爲EMUI、魅族的Flyme、小米的MIUI)等。