在 IPFS 中，系统主要承担以下三个关键职责：
- 表示和寻址数据
- 路由数据
- 传输数据
虽然这三个部分构成了系统的核心，但 IPFS 的功能远不止于此。
表示和寻址数据
与传统依赖位置寻址（如 IP 地址）的方式不同，IPFS 使用内容寻址方式，也就是说，数据根据其内容本身进行标识和检索。
内容标识符（CID）
- 在 IPFS 中，数据会被划分成若干块。
- 每一块数据都会被分配一个唯一的内容标识符（CID）。
- CID 的生成过程是将数据的哈希值与相应的编解码器（codec）结合起来，并通过 Multiformats 机制生成。
- 由于 CID 是直接从数据中计算出来的，因此可以基于内容而非存储位置来获取数据。
- 此外，通过重新计算接收到数据的 CID 并与所请求的 CID 进行对比，可以对数据进行验证。
星际链接数据（IPLD）
- IPLD 为处理 CID 及所有内容寻址数据提供了基础框架。
- 它使用一个有向无环图（DAG），具体来说是 Merkle DAG，来表示数据之间的关系。
- 这种方式让 IPFS 能够表示复杂的结构，比如文件目录（采用 UnixFS 实现），同时也支持任意数据类型。
- IPLD 的设计保证了系统间的互操作性、易于升级以及向后兼容性。
内容可寻址归档（CAR）文件
- IPFS 使用 CAR 文件来存储和传输序列化的 IPLD 内容寻址数据归档。
- CAR 文件类似于传统的 TAR 文件，但专门用于存储内容寻址数据。
路由数据
在数据被表示和寻址之后，IPFS 需要在网络中确定数据具体存放的位置。为此，系统使用了多个子系统共同完成内容路由任务。
Kademlia 分布式哈希表（DHT）
- IPFS 采用 Kademlia —— 一种为去中心化的点对点网络设计的分布式哈希表。
- Kademlia 能够高效地映射哪些节点（IP 地址）存储了对应的 CID 数据。
- 该分布式哈希表分布在众多节点上，并能自我组织以应对节点频繁加入或离开（节点流失）。
- 节点间的连接通过 libp2p 实现。
Bitswap
- Bitswap 是一种基于消息的点对点通信协议，它既用于内容路由，也用于数据传输。
- IPFS 节点可以向其连接的其它节点询问是否存有特定 CID 对应的数据块。
- 各节点还会维护“想要列表”（want lists），这意味着当某个节点稍后获得了请求的数据，它会主动将数据发送给发起请求的节点。
mDNS（多播域名系统）
- 在局域网内，mDNS 协助 IPFS 节点快速发现彼此，而无需依赖专门的域名解析服务器。
- 这在没有互联网连接或者无法访问引导节点的环境下尤为有效。
基于 HTTP 的委托路由
- 对于那些不直接实现完整 DHT 功能的节点，IPFS 支持委托内容路由。
- 这种机制允许节点通过 HTTP API 将路由任务交由专门的服务器处理，从而节省本地计算资源，同时增加了系统灵活性。
传输数据
确定了路由之后，接下来就是如何高效地在节点之间传输数据。IPFS 根据不同场景，采用了多种方式来完成数据传输。
Bitswap（用于数据传输）
- 如前所述，Bitswap 不仅用于内容路由，同时也负责数据块的传输。
- 当节点请求某个 CID 对应的数据块时，连接的节点可以直接将数据传输给请求节点，而无需经过 DHT。
- 同时，借助“想要列表”机制，如果某个节点稍后获得了请求的数据，会自动将数据传送给原先请求的节点。
IPFS HTTP 网关
- HTTP 网关为不支持或者未完全实现 IPFS 协议的应用提供了 HTTP 接口，通过该接口可访问 IPFS 网络的数据。
- 本质上，网关充当着中间层，将 HTTP 请求转换为原生的 IPFS 查询，从而使传统的网络应用也能利用 IPFS 的优势。
Sneakernet
- 在无法建立网络连接的情况下，也可以通过物理介质进行数据传输，这即是所谓的“Sneakernet”。
- 通过 IPFS，可以将 CAR 文件（前文提到的内容寻址数据归档）在没有网络连接的存储设备之间转移。
- 同时，由于基于 IPFS 的内容寻址机制，数据在任何一端验证后均会具有相同的 CID。
其他说明
IPFS 还支持其他新兴协议，例如 Graphsync（用于更高效的数据传输），并提供了多个模块来桥接传统 Web 技术（例如 IPFS 网关和 Pinning API 规范）。
这份概念指南是关于 IPFS 核心理念的三部分介绍中的一部分。第一部分定义了 IPFS 是什么（以及不是什么），第二部分阐述了它如何解决当前互联网（尤其是 HTTP 协议）存在的问题，而本文则主要介绍 IPFS 的内部架构——如何对数据进行表示、寻址、路由及传输。
理解这些原理有助于认识到 IPFS 如何将数据转化为自我验证且可检索的单元，并在去中心化网络内高效地进行路由及传输。
如果您有关于上述任一子系统的具体问题或需要更深入的技术细节，欢迎继续提问！
IPFS Comparisons 对比了 IPFS 与其他多种去中心化方案的设计思想和核心特点。IPFS 本身采用分布式哈希表（DHT）以及内容寻址的方式来路由和传输数据，这使得数据的获取基于数据本身的哈希值，而非依赖于单一的存储位置，从而避免了单点故障问题，并实现了高效的去中心化数据存取。
• 例如 BitTorrent，它是一种点对点（P2P）文件共享协议，依赖于集中式的 Tracker 来管理节点间的文件分发。与 IPFS 不同，BitTorrent 更多关注于高效的文件共享，而不是作为一个通用的、支持内容寻址的文件系统。
• 而像 Storj 和 Sia 这样的去中心化云存储平台，则主要致力于提供云存储服务，它们利用节点网络实现数据存储，并采用诸如纠删码、可验证数据检索证明（proof-of-retrievability）或工作量证明（proof-of-work）等技术来确保数据安全和可靠。这类平台关注的重点在于加密存储和数据冗余，而不像 IPFS 那样力图构建一个通用的分布式文件系统。
• Arweave 则专注于永久存储，它并非采用传统的 Merkle DAG，而是引入了“blockweave”这一全新的数据结构来实现数据的长期、永久存储。它主要面向的是构建一个永久档案的数据存储体系，而不是用于常规文件共享。
• Filecoin 虽然建立在 IPFS 之上，但引入了经济激励机制，形成了一个去中心化存储市场，使用户可以租赁磁盘空间。Filecoin 采用了复制证明（proof-of-replication）来确保数据存储的可靠性，并支持多种加密货币支付。总体来说，IPFS 和 Filecoin 可以看作是互补的技术：IPFS 提供了基于内容寻址的数据传输机制，而 Filecoin 则为存储服务增加了市场化的激励层。
• 此外，还有 Hypercore，它专注于去中心化数据共享与协作，采用 DHT 和 Merkle DAG 等技术，并针对动态数据分发进行了优化。
• Holo 提供了一种去中心化的托管平台，其核心技术基于 Holochain——一种采用分布式哈希表并结合了独特的数据共享机制的架构。Holo 的侧重点在于支持去中心化应用，而不是传统意义上的文件存储。
• Swarm 则建立在以太坊生态系统上，利用智能合约和加密技术来实现安全的、抗审查的去中心化存储解决方案。它采用了例如 custody 证明（proof-of-custody）等机制，针对去中心化数据存储场景进行了优化。
页面中还通过表格对不同方案的存储机制、数据模型、网络协议栈、标识符组成以及具体适用场景进行了详细对比。尽管这些方案都采用了基于内容的寻址方法，但它们在技术细节和目标应用场景上存在明显差异。有的方案在文件共享上优化得更好，有的则侧重于永久存档、云存储及去中心化应用托管。
通过了解这些差异，我们可以根据实际需求选择适合的方案，比如如果主要需求是构建一个去中心化的通用文件系统，可选择 IPFS；而如果需要满足安全、永久存储或经济激励存储的要求，则可以考虑 Filecoin、Sia、Arweave 等其他解决方案。这种对比有助于澄清 IPFS 在整个去中心化技术生态系统中的定位。