📜 [專欄新文章] libp2p — 模組化的點對點網路協議
✍️ Ken Lin
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
libp2p — 模組化的點對點網路協議
可重用的輪子
『不要重複造輪子』，是在軟體開發時，經常被引用的一句話。
這句話隱含的意義是，盡可能的去重用（reuse）其他人分享的開發成果，因為很多的經驗及知識，就是在這樣的重用過程中，逐漸的被累積及驗證。而許多被廣泛重用的輪子，往往就這樣成為某個特殊領域中共用的基石，進而加速了其他專案開發時的迭代過程。
本次CrossLink Taipei 2019的研討會中，也出現了一個這樣的輪子，那就是libp2p專案。
分佈式應用的共業
傳統的中心化網路架構當中，每一個參與的節點，其Server與Client的角色是確立的，因此封包在路由傳遞時也相對單純，對於開發者而言，大家也都非常熟稔這樣的架構。
而在分佈式的網路架構當中，每一個節點都同時肩負了Server與Client的角色(或者換一個說法，不再有Server-Client的區別)，再加上各種異質的網路環境與網路通訊協議，開發者往往要耗費許多資源來解決這些網路底層的通訊問題，例如NAT穿透、加密傳輸等等。
如果這些難題，一再的困擾著不同的開發者，那麼有沒有一種可能，可以把這些難題所需要的解決方案集合在一起，方便大家去重複使用並改進？libp2p的出現，便是這個問題的答案。藉由高度模組化的設計，開發者可以方便的取用自己所需要的部分模組，並在現有的模組上疊加自己額外的應用邏輯，以適應各種不同的應用場景。
由於其高度模組化的特性，使得libp2p受到許多知名專案的青睞，紛紛使用了libp2p作為其底層網路框架，例如Ethereum 2.0、Palkadot、Filecoin、0X等等。
libp2p原先是IPFS專案中的網路框架，後來抽出變成一個獨立的專案。
libp2p的特色
以下所提到的各種libp2p特色，很多都以模組的形式被實作，開發者可選擇適合的模組，進而開發出符合其應用場景的服務。
具有兼容性的定址方式
libp2p使用了類似檔案路徑的概念(PLAN9 Ubiquitous Filesystem)，為每一個行程(process)定義了專屬的位址。這種定址方式，可以增加行程定址的兼容性，假設某個行程改用了新的網路傳輸協議(例如從ipv4改為bluetooth)，可以很方便的以相同的定址結構去表達新的位址。
以目前常見的ipv4位址為例，假設某個節點是以ip 1.2.3.4以及port 80提供了服務，在libp2p中其位址可表示為/ip4/1.2.3.4/tcp/80。
支援多種傳輸協議
針對目前常見的傳輸協議，libp2p也實作了相對應的模組，例如：TCP、QUIC、WebSockets、WebRTC。在未來，libp2p預計還會支援Bluetooth、uTP、UDP，或者目前尚未發明的新協議(歸功其兼容性的定址方式)。
可升級的傳輸協議
在libp2p的設計當中，一個行程與另一個行程建立連線時，首先會以某個底層協議作為原始連線(raw connection，例如TCP協議)。一旦原始連線建立完畢，兩個行程可以進一步依據他們的需求進行協調，決定是否將原始協議升級(upgrade)為另一個協議連線(capable connection)，例如將單純的TCP協議升級為具有加密性質的連線。
多路複用
有時候在兩個節點之間建立一個連線，需要不少的成本(像是需要穿透NAT、經過多次的交握確認後才能建立連線)，如果能夠重複使用已經成功建立的連線，兩個節點之間就能以更有效率的方式實現異質的資料傳輸。舉例來說，兩個節點可以在同一個TCP連線上，進一步的產生不同的串流(stream)。
協議協調
由於libp2p支援多種傳輸協議，並且能夠多路複用，兩個節點在互相傳輸資料之前，便需要有一套機制去互相溝通，確定兩者要以哪種協議進行資料的傳輸，這便是協議協調。
目前的協議協調機制是multiselect 1.0，libp2p接下來會將協議協調機制升級為更有效率的multiselect 2.0。
節點發現與訊息傳播
在建立分佈式應用的時候，如何有效率的尋找節點(節點發現)是建立一切服務的起點，能夠找到節點，才能進一步和節點建立連線，接著才能建構其上的應用。libp2p提供了數種節點發現的實作(DHT、Randezvous、mDNS等等)。
除了節點發現，如何進行訊息傳播也是建立一個分佈式應用必須考慮的事情。在這邊要特別提起PubSub這個訊息傳播模式。這是一種類似MQTT的發布-訂閱(Publish-Subscribe)模式，允許訊息以M-to-N的方式在網路中傳遞，這種傳播模式是非同步(asynchronous)。和MQTT不同的是，libp2p是分散式的，並不需要一個中心化的broker來負責訊息的路由(routing)。
目前PubSub提供數種訊息路由演算法，包括floodsub、gossipsub等等。在Ethereum 2.0也將會採用PubSub作為其訊息傳播模式。
NAT穿透及中繼
現今的網路架構中，NAT無所不在，而這也是點對點連線時最大的困擾。libp2p實作了NAT穿透，而對於那些無法進行NAT穿透的節點，libp2p另外提供了中繼技術(relay)來作為補強方案。
結語及後記
以上所描述的libp2p特色，是在參與CrossLink Taipei 2019研討會時，印象較為深刻的幾點，尚有其他特色沒有節錄於本文之中。除此之外，各項特色的描述多半以重點式的形式紀錄，很多細節仍有待深入挖掘。
在撰寫本文時，筆者參考了許多前人的貢獻，其中有不少是來自於CrossLink Taipei 2019 的線上共筆，謝謝這些參與共筆的志工。除此之外，也要特別感謝Taipei Ethereum Meetup的朋友Kevin，提供了不少寶貴的建議以及實作經驗。
參考資料
https://segmentfault.com/a/1190000015410582
https://zhuanlan.zhihu.com/p/33535984
https://ethfans.org/posts/why-libp2p
https://medium.com/r/?url=https%3A%2F%2Fgithub.com%2Fmultiformats%2Fmultiaddr
libp2p — 模組化的點對點網路協議 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
mqtt client 在 fusesource/mqtt-client: A Java MQTT Client - GitHub 的推薦與評價
mqtt -client provides an ASL 2.0 licensed API to MQTT. It takes care of automatically reconnecting to your MQTT server and restoring your client session if ... ... <看更多>