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)。