Gossip 、 WebFinger 都是去中心化的网络协议,但是其设计理念却有不小的差别,我想从两者的设计理念和产品对这两者的需求出发,去探讨这两者是否存在想通和可借鉴的地方。
一、分布式系统中的资源发现与同步
WebFinger其实更适合一种联邦式架构(如 Mastodon),每个实例都是一个自治的服务器,负责管理自身用户的数据。这种架构更强调强调按需查询,而非全网持续状态同步。
Mastodon 用户的资料查找通常是用户在发起交互时的即时请求。例如,当你输入 @user@domain
时,客户端只需要查询目标实例的 WebFinger 接口来获取该用户的 ActivityPub 资料。
对于 Mastodon 来说,账户的元数据(例如个人主页、头像、链接等)并不需要在全网中不断地广播同步,而是在查询时从目标实例获取最新数据即可。
Gossip 的设计目的主要是去达成去中心化系统中的状态同步,也就是全网数据最终一致,这就意味着需要在各个节点间不断传播和更新状态,会产生大量持续的网络流量。
使用 Gossip 的去中心化架构中的节点需要通过类似 Gossip 的协议在所有节点间持续传播状态信息,以确保全网数据的一致性和最新状态。这种方式适用于那些没有明显"中心"节点、需要全局信息同步的场景,但会带来额外的网络流量和延迟。
二、协议核心机制
Gossip 协议的基本思想就是,一个节点想要分享一些信息给网络中的其他一些节点,于是周期性的随机选择 k 节点,并把信息传递给节点。这些收到信息的节点接下来会做同样的事情,下一个周期传递消息给非消息来源的相邻 k 个节点传递信息。
Gossip 对网络节点的连通性和稳定性几乎没有任何要求,它一开始就将网络某些节点只能与一部分节点部分连通 而不是以 全连通网络作为前提;能够容忍网络上节点的随意地增加或者减少,随意地宕机或者重启,新增加或者重启的节点的状态最终会与其他节点同步达成一致。
WebFinger 就相对简单了,的旨在通过电子邮件地址(如[email protected]
)查询用户的公开元数据信息。
其原理就是:用户向目标域名发起HTTP GET请求,路径为/.well-known/webfinger?resource=acct:[email protected]
,服务器返回包含元数据的JSON对象。
WebFinger严格遵循RFC 7033标准,仅用于身份解析,不涉及实际内容传输。
用户动态、关注关系等数据通过ActivityPub协议 传输,而ActivityPub的底层通信依赖HTTP协议(如POST发送帖子、GET获取时间线)
WebFinger 相较于普通的 HTTP 请求有什么优势?为什么不直接用HTPP协议,而是采用WebFinger?
WebFinger通过固定路径(/.well-known/webfinger
)和标准参数(如resource=acct:user@domain
)实现用户身份发现,确保不同实例间的协议一致性。
若使用简单HTTP请求,每个实例可能自定义不同端点(如/user_profile
或/find_user
),导致跨平台交互复杂化。
参考资料
RFC 7033 WebFinger:www.rfc-editor.org/rfc/rfc7033...
Mastodon 文档: docs.joinmastodon.org/spec/webfin...