回顧XP2P的發展曆程，由為近幾年興起的直播業務節省帶寬成本為出發點，經過日益發展完善，XP2P已經在底層借助STUN、端口預測、生日攻擊、UPnP建構了完善的互聯直連基礎，并且在直連的UDP連接配接的基礎上擁有了高效、可靠傳輸協定XNTP，借此再高屋建瓴，在之上實作了廣泛應用的HTTP協定，至此萬物互聯的服務架構已經基本搭建完成，具備網絡負載小、傳輸性能高、穩定的特點。本文來自于騰訊雲進階工程師張鵬在LiveVideoStackCon2019北京站上的精彩分享。
文 / 張鵬
整理 / LiveVideoStack
大家好，我是騰訊雲張鵬，從2014年開始一直深耕P2P技術，攻克P2P技術難題。在過去幾年中，騰訊雲XP2P技術已在多個産品線落地并經受了大流量閱兵直播、賽事直播等考驗，今天我将為大家着重講解騰訊雲P2P技術在網絡穿透、網絡傳輸以及網絡拓撲組建等方面内容。
1. 什麼是XP2P？
P2P架構展現了網際網路架構的核心技術，簡而言之就是“你有、我有、大家都有的東西，大家互相聯接共享之”，是以這種概念被描述在RFC 1裡面，可謂由來已久，是最早網際網路建設者心中最夢寐以求的架構。那為什麼到現在一直仍是中心化的服務模式呢？主要還是它的一些曆史原因和技術原因沒有解決。但是我們依舊能在近30年網際網路技術飛速發展中看到P2P的産物，比如netsper、PPlive、bt，此外06-08年是國内P2P學術圈的黃金時期，國内高校有着非常高的産出，如清華大學的GridMedia、香港科技大學的CoolStreaming、華中科技大學的AnySee等等，代表着當時流式P2P的最高境界了。2008年之後，由于P2P流量給網絡帶來了很大的負載，經曆了營運商的打壓陷入一段低潮期，直到2014年直播興起，騰訊雲XP2P也再次重新進入雲服務市場。
2. XP2P産品功能
2.1 穿透篇
2.1.1 P2P的NAT穿透
說到P2P就肯定要講到它的起點——如何建立起互聯的關系。我們知道IPv4位址已經日益衰竭，現在家庭帶寬中“貓”的路由器的出網IP已經不是公網IP了，而NAT（網絡位址轉換）可以解決這個問題，當然NAT也是一把雙刃劍。比如當我們在發送請求的時候，我們用内網位址加一個端口辨別這個請求，當請求資料來到網際網路，則被NAT映射成一個公網位址和端口。但這時就會帶來一個問題，雖然我們知道對方的位址，但卻無法連接配接，這是因為我們在發送資料時，由于對方NAT并不認識我而被阻止，是以我們需要首先把Peer之間建立起連接配接的過程打通。下圖描述了通過中間轉發伺服器把兩個Peer打通的過程。
2.1.2 NAT類型
最新的STUN協定對NAT類型分為7種：Open Internet、UDP Blocked、Symmetric Firewall、Full Cone、Restricted Cone、Port Restricted Cone、Symmetric。關于它們的介紹，在此請看下PPT，不做過多介紹了，隻簡單說一下，對稱型是最難辦的，對稱型在連接配接不同外部Peer時會擁有随機的不同映射位址，是以它也有了端口限制型的特點，難以穿透。
2.1.3 STUN協定
STUN協定就是探測前面提到的7種NAT類型的協定，它的包格式如下圖左側顯示，右側為其流程圖，這張圖中有幾點需要特别注意：首先是Test II，它是請求原來的STUN伺服器位址，然而是換一個IP給我回包看是否可以收到。第二點是Test III，它是請求原來的STUN伺服器位址，然而是換一個端口給我響應看是否可以收到。這兩點尤其需要特别關注。
目前大多數P2P應用都是基于STUN協定做穿透建立直連通道，但STUN協定并未完全解決問題，它無法建立起對稱型和端口限制型、對稱型的連接配接。下圖是一個對稱型連接配接端口限制型的案例：對稱型和端口限制型都會連接配接一個外網的打洞伺服器，它們彼此知曉位址，當對稱型向端口限制型發包時，由于目标位址變了，是以也換了一個新的映射位址，建立的一個新的“洞”；然而通過打洞伺服器中轉給端口限制型的資訊裡面，仍然是對稱型之前與打洞伺服器建立的舊“洞”，導緻此時端口限制型可以回包，但是傳回的是給舊“洞”，與對稱型計劃與該限制型通信的新“洞”不同，是以通信被拒絕，打洞失敗。更加雪上加霜的是，伴随安全等級的提升，對稱型和端口限制型越來越多，而STUN對此卻無能為力，非常遺憾。
2.1.4 攻破對稱型NAT穿透：端口預測
如何攻破對稱型NAT的穿透成為了P2P技術的關鍵之一。此前一篇論文提出一個方式，通過端口預測的方式來解決對稱型NAT的穿透：首先Client到外網探測自身端口變化規律，相當于端口預測；Sever也同樣探索自身端口變化規律；最後通過穿透伺服器中轉知曉彼此資訊并預測對方下一次端口，朝其發包，進而實作成功打洞。這個放在當年是可行的，因為當年95%的裝置都是端口遞增的；然而如今NAT端口變化大部分卻是随機的，是以也很遺憾。那我們到此就束手無策了嗎？依然還剩下大部分随機端口對稱型連端口限制型、對稱型的case懸而未決！
2.1.5 攻破随機端口對稱型NAT的穿透：生日攻擊
我們知道端口限制型的位址是不會變的，而随機端口對稱型的映射位址是随着目标位址變化而随機變化的，那他們兩個怎麼打洞建立起直連通道呢？受端口預測方式的啟發，其實還是能夠以較小代價打通的。這裡采用的方案是生日攻擊法，也即是随機碰撞的原理來實作穿透。生日攻擊來自于生日悖論，講的是一個會議室坐着23個人，一年有365天，他們中任何一個人的生日可能在任何一天，然而他們中至少有一對是同一天生日的機率為50%。更直白點，是利用了遠小于樣本集（生日共有365種可能）的嘗試次數（23個人），便能很大機率收獲到一對相同采樣碰撞（同一天生日）的結果。那麼，假如樣本集是65535個端口，要想兩方随機打洞多少個端口，才能讓兩方剛好碰撞成功一次的機率達到80%呢？
它具體是這樣做的：
1. 随機型NAT通過建立socket，朝端口限制型的外網位址發包，這些包在出NAT時，會被随機映射成不同的“洞”
2. 端口限制型，随機地向對方不同端口位址發包。然後看，是否有一個目标端口恰好發送給第1步裡面随機型NAT映射的外網端口“洞”上，如果碰對，即可成功建立起連接配接
雙方通過向對方各自發400個包，即可讓穿透成功率達到80%以上，而400個包的代價，每個包隻包含IP頭部、UDP頭部、連接配接ID，再加上一個以太網幀頭部，頂多50位元組，400個包總共也就20KB，以此換取優質節點的連接配接成功，還是完全可以接受的。
生日攻擊的手法，大大提高了兩方成功建立起連接配接的可能性。但是僅僅如此還是不夠，生日攻擊隻能應付對稱型與端口限制型的穿透，然而随機端口對稱型與對稱型的連接配接依舊無法建立！
2.1.6 UPnP：變Symmetric NAT為Full Cone
UPnP協定（通用即插即拔服務）是一個旨在讓家庭裝置與網際網路其他裝置無縫建立起連接配接，并簡化網絡過程的協定。它其實更像是一個物聯網協定，包羅萬象。我們發現其中包含兩個服務WANIPConnection和WANPPPConnection，它們可以從内網主動添加到外網的Full Cone型端口映射，是以對于對稱型難以穿透的情況，我們就可以使用這種協定将它轉變為Full Cone型，進而進一步提升穿透成功率。
到此為止，我們已經幾乎實作了最優的peer to peer的穿透方案，比WebRTC更優，比libp2p更優，并會達到一個很好的連接配接建立成功率，這将是我們P2P的核心基礎。
2.2 傳輸篇
2.2.1 TCP協定的弊端
提到傳輸協定就不得不說TCP，它是網際網路這二、三十年來的基礎，但它同樣存在一些薄弱環節：首先就是啟動慢，TCP有一個慢啟動——每次是以倍增的速度去嘗試直到一個門檻值，它從一個很低的初始速度上升到理想速度，中間需要很多回合的RTT，是以稱之為“慢”啟動。在初始階段，它的增速甚至不如一個固定的較大斜率的直線增速快。第二點是擁塞控制差，TCP每個回合會增加一個包（發送視窗），一旦超過網絡最大限制，就會直接減少一半，進而就使得它的平均發送速率隻能達到網絡的75%。第三點是TCP的抗抖動、抗丢包差，大家可能都聽過一句話“TCP丢包率超過20%，基本就廢了“，這裡給大家舉一個例子：假定我們的丢包率是30%，也就是說一個包連續丢三次的機率就是2.7%，這意味着當加性增發資料到累計發了40個包後，就會發生一次連續3次重複ACK，進而導緻速度降為一半，循環往複TCP的速度也就再也起不來了。最後是重傳歧義，當發生丢包之後，在下一個回合接收到這個包，然而我卻無法确認接收到的是原本的包，還是重新發送的包。
2.2.2 XNTP之Pacing
針對TCP的問題，我們的協定做了很多優化。首先是Pacing發送，Pacing發送我了解就是均勻的發送，在早期的TCP的發送方式，可能一刻間交給網絡去傳輸該RTT内要發送的所有包，然後RTT會越來越大，是以它會有排隊， RTT進而變得更大，這樣會發送更多，最終會導緻路由器排隊撐不過來，就會導緻丢包，網速抖動。更好的傳輸方式是均勻的發，一個RTT是40毫秒，我發40個包，這裡每一毫秒發一個包，然後一毫秒之後再發另外一個包，這樣對路由器非常均勻，就可以不會哪樣頻繁地丢包，把網絡利用上去。
Pacing-Race本身并無稀奇，它僅是我們傳輸協定的基礎，後續的很多優化其實都依賴它。
2.2.3 XNTP之抗抖動
我們對于抗抖動的政策是來源于QUIC的靈感，QUIC每包有兩個序号：包序号和内容序号，我們認為，它才是解決網絡傳輸抗抖動的關鍵，達到了發生擁塞時，滑動視窗不停滞的效果。假設正常發包，滑動視窗是11，接收方在接到第11個包之後發送ACK表示第2個包丢了，TCP會把滑動視窗滑到[2,13]，然後重傳2和11包，效率底下；而QUIC遇到丢包時則會以新的包序号重傳，而該包的内容序号不變，效果則是相較于TCP類似于滑動視窗直接滑到[12, 23]，丢的包以新的序号12、13進行傳輸，滑動視窗不影響。這樣就使得即便在20%丢包率的情況下，依舊可以使用剩餘的80%網絡傳輸資料。
2.2.4 XNTP之“快啟動”
我們首先了解下Google的BBR，它有兩個關鍵因子：探測到的最小RTT和最大帶寬，進而确定最優發送法：本次發送量=最小RTT * 最大帶寬。這個思路同樣可以借鑒到“快啟動”中嗎？我們之前提到過Pacing雖然解決了TCP發送隊列緩存延遲問題，但是在初始速度方面仍存在自身劣勢，那突發就一無是處嗎？突發的意義在于讓發送方的發送速度達到了瞬間無限大，我們的解決思路便是依賴于此！我們認為首包的RTT就是最小RTT，并且在前面少量幾個包采用突發的方式，比如第一回合發送的10個包中前4個包采用突發，突發的方式也意味着發送速率無限大，是以接收方可以通過統計這4個包的接收速度得到一個我們認為近似的最大帶寬，進而1-RTT後拿到ACK的時候，最小RTT、最大帶寬都拿到了，使用BBR的方式，便可以得到一個“最優發送法”，結束慢啟動，進入擁塞控制。
像快啟動這樣的網絡傳輸創新，我們還有很多其他對傳輸協定的系統性的認知，在經過多方驗證資料後，我們也會努力開放給學術界、工業界的朋友，由于時間原因，暫時不先過多介紹了。
2.3 應用篇
有了XNTP提供的這種可靠傳輸，相當于有了“TCP”，我們也順勢在XNTP上建構了HTTP語義，這裡不僅實作了HTTP的基本語義，還實作了HTTP 2的多路複用——在同一個鍊路上複用多個流，除此之外我們也實作了HTTP Client和HTTP Server。也就是在P2P很高的連接配接成功率和XNTP很好傳輸性能的基礎上，在HTTP協定上可以建構HTTP服務。我們知道Unix的簡單哲學之一展現在“一切皆檔案”，而我們這套架構也可以簡單了解為“一切皆服務”，以後也會一直奉行這個簡單的思路，而XP2P/PCDN自然而然也就成為這套架構的第一個應用服務。
2.4 P2P技術怎麼做？
2.4.1 必要條件 — 切片
對于P2P技術實作，首先所有節點都要有全網資料一緻性，也就是你的某一片資料和我的這一片資料一定是相同的，否則就沒意義。
對于點播而言，檔案長度和播放時長都是确定的，是以資料一緻性的實作算法非常簡單，易于實作。但是對于直播來說，直播内容稍縱即逝，并且每個觀衆觀看直播的時間點也不相同，是以無法像點播一樣按照Offset分片。
2.4.2 P2P針對直播的切片
針對直播的切片，傳統方式包括按照dts制定，或者使用中心伺服器将直播流切片為小檔案來約定資料一緻性，比如HLS和DASH。而我們目前采用的方式是直接在原始直播流上做切片，FLV和FMP4在格式中天生帶有明顯邊界資訊——FLV的tag或FMP4的box，是以我們隻需要和其他Peer約定好起始節點和邊界資訊，就可以突破在原始直播流上實作P2P的限制。
2.4.3 P2P的自适應碼率
在直播中流暢的觀看體驗是非常重要的，而HLS和DASH天生是為自适應碼率而生的，它們會在網絡條件較差的時候自動切換到較低的碼率，我們知道HLS和DASH是對直播流做了切片，而FLV和FMP4則不需要，隻要在一個HTTP連結，把新的解碼參數給到用戶端（播放器）就可以實作自适應碼率。那相比于HLS和DASH有什麼優勢呢？大家都知道，HTTP 2相比于HTTP 1.1最大的改善是把多個HTTP請求用一個TCP連接配接傳輸，因為單一TCP連接配接的擁塞控制和順序到達是要比多個TCP連接配接的擁塞競争要好的，然而HLS和DASH卻反而把直播流請求變成多個連接配接的檔案請求，這其實是一個倒退。而我們直接在一道流式直播上實作自适應碼率，我們認為是比HLS、DASH還要領先的技術。
2.4.4 P2P網絡拓撲結構
下面是三種比較常見的網絡拓撲結構：網狀模型、樹狀模型、平均分流模型。各有各的優點和缺點。但你要問我們騰訊雲用了哪種模型，答案是我們那種都沒用！目前騰訊雲使用的是網狀模型和樹狀模型的混合模型，在結合兩者優點的同時，相對減少了樹狀結構的層數，進而平衡樹狀模型所帶來的弊端，這也是騰訊雲P2P和分享率做的很好的原因。
3. XP2P應用場景
提到P2P應用場景，首先會想到流量分發加速，比如直播、點播和檔案下載下傳場景的應用，其實P2P發展到今天，已經不怎麼會引起網絡高負載，而是更友好地提升網絡能力。我們認為P2P其實是實作了某種程度上的多點傳播協定，起到了優化帶寬傳輸，降低網絡負載的功能：比如同一小區有兩個人觀看同一個視訊，其實隻有一個人需要從遠端伺服器拉取資料，另一個人可以通過内部網絡分享擷取，這樣就減少了資料包在網絡上流轉，進而降低網絡負載。特别值得一提的是，我們實作了很高成功率的P2P穿透，實作了可靠的網絡傳輸和HTTP，我認為再結合邊緣計算、霧計算是很有可能打破現在的中心化部署服務的限制，有可能将簡單伺服器部署在真正的分布式網絡中。
4. XP2P的未來與展望
最後，我們對XP2P的未來進行展望。騰訊雲X-P2P某種意義上實作了多點傳播協定，即優化了網絡品質，又降低了網絡的負載；而456（4K、5G、IPv6）的到來，将會使X-P2P進一步發揮能力和得到更廣泛的應用；區塊鍊的底層所使用的P2P技術和騰訊雲X-P2P有異曲同工之妙，然而libp2p除了搞了一堆不必要的概念，還沒有看到怎麼接觸到穿透的核心技術；邊緣計算也将依賴穩健、安全、高效的P2P技術底層；XNTP傳輸協定會繼續優化，未來甚至将可以和quic相提并論；特别值得一提的是，霧計算絕不止流量分享這樣的應用那麼簡單，它還需要一股風真正把它重定義，就像當年AWS重新定義雲計算那樣偉大。而這套萬物互聯的服務架構，将遵循一切皆互聯服務的簡單思路繼續發展，可能就是重新定義霧計算的鑰匙，這才是更令人興奮的！