这一切都要从一只蝙蝠说起……

疫情还很严重，关在家里胡乱写点东西。IPFS，直译星际文件系统(InterPlanetary File System)，诞生于 2014 年前后，根据白皮书的描述，罗列了互联网传输协议 HTTP 的众多缺点后，提出以去中心化的组织形式来替代中心化的 HTTP 协议。总体来看，IPFS 结合了众多成熟的技术，基于 S/Kademlia 分布式哈希表算法（bitTorrent 采用了类似的算法），引入 git 版本控制的思想，以实现细粒度的去重，同时减少数据更新带来的同步问题。激励层 FileCoin 吸收了 BitCoin 的思想，通过提供存储服务来获取数字货币，以吸引更多人共享自己的存储资源。开源协作、共享资源、众多大牛背书，一切看起来都是那么美好。

IPFS 存在的问题

事物的两面性决定了不可能存在解决所有需求的完美。固然 HTTP 是不完美的，IPFS 白皮书中也提到了存在的一些问题，例如中心化的服务器集群容易受到攻击；中心化存在天然的管理风险等。此外还指出了不那么像问题的问题，例如数据存储成本太高、数据传输瓶颈和维护难等。中心化下受攻击和管理风险是不可避免的，这也正是 HTTP 的问题之一，但是否如白皮书中所说的数据存储成本高、维护难，恐怕还需要打个问号。

尽管 HTTP 存在这样那样的问题，也并不意味着 IPFS 能够取代它。计算机史上被精心设计的东西不计其数，最后活下来并被广泛应用的技术一定是结合实际下最合适的技术，既要能解决存在的问题，同时也要控制成本。

访问时延

在硬件趋于白菜价的如今，用户体验显然比多加几台设备重要的多，其中响应延迟又是最重要的之一项，各大互联网公司都争相地部署 CDN 节点，尽量从更加贴近用户物理位置的节点向用户发送数据。如果将数据部署到 IPFS 中，在访问时不仅需要经过一个 IPFS 网关，还需要经过节点数量未知的多跳请求，才能得到一个元数据，如果数据被切成了多个片，还需要反复进行多跳请求，此外 IPFS 网络中的节点通信质量也是参差不齐。在访问时延这一项上，IPFS 就已经无法满足绝大多数互联网应用了。

存储冗余

IPFS 通过引入版本控制和细粒度块管理来实现数据去重，但是其本身又为每个块做了数份副本（白皮书例子 N=20）。假设按照 20 份的块副本来计算，除非原始数据的冗余率达到80%-90%的程度，比如实际存储的去重块数据量是上传的总数据量的十分之一，在这样的存储冗余场景下才有资格提存储成本。而实际的 HTTP 应用中，网页静态资源诸如 js、css 等都只占有极少数资源，绝大多数的资源都是视频和图片，IPFS 的去重在这些应用面前形同虚设。且不说文件分块后增加的元数据量，20 份的副本并不能提供更快的访问速度、更低的访问时延和更高的数据存储安全，在租约机制下的数据续期要求数据提交者每隔一定时间向每个块的冗余节点发起该块的续期请求，一旦超过时限未收到续期请求，该数据块就可能被删除，因此 IPFS 并不是官方所宣称的那样能够保证数据永久存储。

数据更新

IPFS 采用版本控制来尽可能避免同步，随之带来的是数据的传输开销。在实际应用中，对数据的处理无非就是 CRUD 的增删查改，从访问频率角度可以分为冷数据、温数据和热数据。前面论证了在访问时延角度 IPFS 没有半点理由能够取代 HTTP，如果数据的更新频率再高点，IPFS 产生的大量无效数据块和元数据块将会是一场灾难。另一方面，中心化的管理降低了数据聚合处理的瓶颈，数据的存储和使用效率是 IPFS 绝对无法比拟的。

综上，尽管 HTTP 存在诸多问题，并且 IPFS 可能能够解决其中的一些问题，但其引入了更多无法忽视的问题，在现阶段以及之后可预见的一段时间里要颠覆 HTTP 就是痴人说梦，况且 FileCoin 主网至今还在鸽，快醒醒，数字货币的风口都已经吹过了！

IPFS 何去何从

IPFS 实在过于理想主义，即便让其诞生于上个世纪，也难以大规模推广。移动互联网时代壁垒已经形成，以淘宝为代表的垂直细分领域屏蔽搜索引擎网络爬虫，争夺流量入口，数据就是互联网企业的生命，谁能够更高效地利用和挖掘数据，就更可能在激烈的商业战争中生存下来。即便没有 HTTP，对数据的利用效率需求也会倒逼行业开发出 HTTQ、HTTR……需求总是客观存在的，HTTP 之所以能够应用得如此之广，不过是它更适合当下的互联网罢了。

虽然吐槽了 IPFS 的各种毛病，但是并不是说 IPFS 一无是处。例如相对于 bitTorrent，IPFS 采取了固定大小的分块，在一定程度上可以加快数据的并行传输。也许替代各种点对点应用，整合数字货币会是一个发展方向，交给时间来检验罢。