当很多用户使用公开共享的DHT表去发现和广播内容时，它们中有一些是在被分割的网络中运作（比如在本地网络或孤立的VPN）的。

对这些用户而言，如果DHL表中的非公开节点只是客户模式就会很麻烦，因为这些节点无法被连接，用户无法与它们通信。

在这种情况下，我们设计了另一种DHT表，这种DHT表包括了一些不在公开网络（比如VPN、CJDNS、Yggdrasil）中的节点。

我们将这种DHT表称为LAN DHT，而将公开网络的DHT表称为WAN DHT。这两种DHT表使用不同命名的DHT协议（比如WAN DHT为/ipfs/kad/1.0.0，LAN DHT为/ipfs/lan/kad/1.0.0）以防止两种网络混在一起。

但如果用户不恰当地配置了他们的网络，则他们使用的非公开网络有可能混为一团。

WAN DHT和LAN DHT在实现细节上的不同主要表现在DHT表对对等节点接受标准的不同，即什么节点能被纳入路由表中，什么不能。WAN DHT的标准是“节点看上去是在公开网络中”，而LAN DHT的标准是“节点看上去不在公开网络中”。

WAN DHT表中的节点可以根据它们的工作状况从客户模式切换为服务器模式，但LAN DHT中的节点则永远只能是服务器模式（除非“dhtclient”选项被设置）。

路由表：

早前我们分享过：Kademlia网络中的每个对等节点都维系着与网络中其它若干节点的连接。它们的工作方式如下：

1.当我们连接一个对等节点时，要检查这个节点是否符合条件被加入到我们的路由表中。

- 保证对等节点处于服务器模式，并且广播DHT协议的ID符合标准（比如对WANDHT是/ipfs/kad/1.0.0，对LAN DHT是/ipfs/lan/kad/1.0.0）。

- 保证对点节点的IP地址是公共地址（比如公共DHT表中的每个成员至少有一个公共的IP地址而不是只有类似192.168.X.Y这样的地址）。

2.如果一个节点满足条件可以被加进路由表，接下来就要决定该节点在Kademlia地址空间中应该放在哪个“桶”（“bucket”）里（比如节点在2^7和2^8之间，其地址空间为2^256，则节点在路由表中就应该放在定义为256-8的桶里）。

3.将该节点放入路由表

- 如果路由表中节点应该被放置的“桶”没有满（即该“桶”中放入的节点少于20个）则将该节点放入此桶中。

- 如果该桶已经满了则我们要检查这些节点中是否有可被替换出来的。如果有，就将可替换的节点拿出来，把新节点加入。如果没有，就放弃这个桶。

4.如果我们向路由表中的节点发出咨询请求但得不到回应，则把该节点从表中拿走。

- 注意：每次刷新后，我们都要遍历整个路由表并向最近没有通信过的节点发出咨询请求以检查它们是否仍然在线、可被连接。一旦发现某节点掉线不再可被连接，则把它从表中删除。

此外，为了保证路由表的准确，我们会每隔一段时间刷新它。对路由表刷新频率的计算基于一系列参数如“桶”的大小等。

我们可以增加刷新的频率，但它有个下限。对IPFS而言，其下限频率为每10分钟刷新一次。

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