IPFS0.5改进内容路由处理不可连接节点

在之前的分享中，我们提到在IPFS0.5版本中，DHT有了较大的改进，并简要介绍了DHT在IPFS中的作用以及其在IPFS中的实现方式：Kademlia。

今天我们介绍Kademlia如何处理无法连接的对等节点。

在之前的文章中我们介绍到Kademlia的主要特性是所有的对等节点都可以由小到大被内联集成起来，这个特性非常重要。

举例来说，当对等节点0在寻找对等节点55的一路寻址过程中，它一边找会一边知道自己离目标越来越近。要做到这一点，系统中的每个节点都要能互相通信，告知对方自己的身份。

如果在这个过程中节点0找到节点33，并要节点33告知下一个节点时，节点33却告知节点0一个已经无法连接通信的节点，那节点0再走下去就是个死胡同了，这不仅会导致网速变慢，还会导致全网数据的碎片化（有些节点可以连接而另一些节点无法连接）。

在系统中，节点间无法连接通信听起来有些奇怪，但通常有两个因素会导致这个情况发生：一个是网络地址的翻译（NetworkAddressTranslation，简称NAT），另一个是防火墙。

比如在几个非对称网络中有节点X、Y、Z，他们相互之间能互通并与A也相联结，但A却无法联通X、Y、Z。同样，如果节点A和B有网络地址翻译方面的问题，它们也无法相互连接通信。

当IPFS网络在2019年增长了30倍后，我们碰到了一个很大的问题：突然间IPFS DHT表中的很多节点都出现了网络地址翻译的问题，这导致很多节点无法连接，从而使得整个系统的质量极大降低。

为了处理这个问题，我们现在采用的办法是如果有节点被怀疑无法连接，就直接忽略这个节点，并且也鼓励一些节点自己退出系统，如果它们自己怀疑自己可能无法被其它节点连接了。

为了做到这点，我们使用了libp2p的AutoNAT功能，它类似一个分布式STUN层，让节点告知系统中其它节点自己的网络地址以及自己是否可以被连接。

只有一个节点可以被连接它才从客户模式（clientmode，在客户模式中节点可以向DHT表格发送查询请求，但无法对查询请求作出回应）切换为服务器模式（servermode，在服务器模式中节点既可以向DHT表格发送查询请求，也可以对查询请求作出回应）。

同理，如果一个服务器发现自己无法被其它节点连接了，它就会从服务器模式切换回客户模式。

AutoNAT功能以前只在某些节点中被激活。但AutoNAT的功能使用得越来越多，它帮助了我们清理系统中无法连接的节点，这使得AutoNAT的使用越来越呈现分布式状况。

因此，我们现在在所有的IPFS节点中都提供了AutoNAT功能，不过这个AutoNAT功能有一定的限制。

注意：节点在客户模式和服务器模式之间的自动切换是默认的配置选项。但用户也可以将节点固定设置为客户模式。

不过如果不将该选项设置为"dht"（自动切换模式）或"dhtclient"（固定设置为客户模式）则可能极大降低系统的性能。因此对此选项的设置一定要小心。

基于AutoNAT的模式切换非常有用，我们希望尽量用它把系统中无法再连接的节点清除掉。

为了谨慎起见，一个节点必须要验证它是否可公开被连接，如果它被验证既支持客户模式也支持服务器模式则它就可以被加入到DHT表中作为节点。

参考链接：https://blog.ipfs.io/2020-07-20-dht-deep-dive/

热点：ipfs