在傳統的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會變得越來越好。
