在传统的Web中，用户数据是存储在中心化服务器上的。中心化的弊端是，第三方可能会在用户不知情或未同意的情况下随意访问其数据，用户隐私没有保障。
在传统的Web中，用户数据是存储在中心化服务器上的。中心化的弊端是，第三方可能会在用户不知情或未同意的情况下随意访问其数据，用户隐私没有保障。
此外，中心化存储可能会导致可用性问题。特别是，如果将数据存储在一个地方，会导致单节点故障。
Web的文件存储
Web使用基于位置的寻址来存储和检索文件。假设我们要从域名abc.com中访问一张猫的图片cat.png。我们将通过网络浏览器访问此位置(i.e abc.com/cat.png)，作为回报，我们将获得猫的照片。
但是，如果由于某种原因该文件现已从abc服务器中删除，我们将无法再访问该图片。现在，互联网上可能会有其他人拥有同一张猫的照片的副本，但是我们无法与他们建立联系并获取该照片的副本。
互联网上的许多文件可能具有相同的名称，但内容可能会有所不同。
IPFS解决方案
IPFS是用于点对点协议的文件存储，具有基于内容的寻址而不是基于位置的寻址。这就意味着，我们要查找文件，不需要知道它在哪里(abc.com/cat.png)，而是要知道它包含什么(QmSNssW5a9S3KVRCYMemjsTByrNNrtXFnxNYLfmDr9Vaan)，它由内容的哈希(hash)表示。
哈希功能为每个文件创建唯一的指纹。因此，如果我们要检索一个文件，我们将询问网络“谁拥有此文件(QmSNssW5a9S3KV...)”，然后来自IPFS网络的拥有该文件的人会将其提供给我们。
我们可以将请求的哈希值与接收到的哈希值进行比较，来验证文件的完整性。如果哈希值匹配，则表明文件未更改。此哈希功能还有助于对网络进行重复数据删除，以使具有相同内容的文件无法提交两次，因为相同的内容会产生相同的哈希。
这样可以优化存储要求，并提高网络性能。
IPFS如何存储
文件存储在IPFS上，会有一个包含以下内容的数据结构：
Data--可以存储多达256KB的Blob(非结构化数据块)。
Links--链接IPFS对象的数组。
如果我们的文件大于256 KB，则将其拆分并存储在多个IPFS对象中，然后将创建一个空对象，该对象链接文件的所有其他对象。如下图所示：
IPFS数据对象
IPFS用作不可变的存储，一旦将某些内容添加到网络后就无法更改，因为要更改文件就得更改哈希。那么我们如何更新文件?
对此，IPFS使用版本控制系统，广泛地使用在开源的社区中，称为“Git”。IPFS具有提交对象，这有助于跟踪文件自创建以来的所有版本。
每次我们在IPFS网络上添加文件时，都会为该文件创建一个提交对象，并且在我们更新该文件时，会创建一个新的提交对象，该对象指向该文件的较早的提交对象，如下图所示。
IPFS提交对象
文件能永存吗
只有重要文件会保留在网络上，不重要的文件则由垃圾收集器删除，其中文件的重要性由“固定”(pinning)确定。通过固定文件，我们将该文件标记为重要文件，以便在不重要的文件仅被临时缓存的同时，保留该文件。
IPFS的挑战
IPFS最大的挑战之一是保持文件可用。IPFS承诺永久性(permanence)，但不承诺持久性(persistence)。举个例子：如果Alice使文件可用，Bob能够访问它;如果Alice脱机，Bob仍可以访问它。当然，前提是垃圾回收器尚未将其删除。
另一方面，如果Bob固定了该文件，即使Alice的节点发生故障，该文件也将保持可访问状态。因此，固定是一个主要问题。现下，已有许多公共固定服务，因此持续性是需要成本的。
另一个限制是文件的实际共享。用户必须通过传统的通信机制与网络上的其他人共享文件链接(内容地址)，比如即时消息、电子邮件、Skype及Slack等。
这意味着文件共享未内置于系统中。为了寻求相关的解决方案，人们已经开发了爬虫程序和搜索引擎网络。相信随着不断的完善，IPFS会变得越来越好。
