BitTorrent 日前发布了一款多终端同步工具 BitTorrent Sync,这款软件通过 BT 技术允许用户在不同终端之间进行文件同步。
看到这条新闻的第一反应是这会是一款革命性的产品,革的是所有云存储的命。而在试用之后,却发现 BiTorreent 仅仅止步于一个广域网上的网络邻居并不是笔者所预想的那样。
不过,既然从 BitTorrent Sync(以下简称 BitSync)说起,我们自然还是要介绍一下它。
BitSync 的原理很简单,当用户完成设置之后,BitSync 就会自动将用户所划定的同步文件夹进行加密的 BT 共享,并生成一个密钥(由于尚未开源,因此不知道此密钥所含内容)。
当用户在其他终端使用 BitSync 的时候,只要输入密钥,即可远程连接文件源端的 BitSync 服务器进行下载。此时,文件原始存储终端就成了一个服务器。如果用户添加第二个、第三个终端进入整个网络,那么不同终端之间会互相变为彼此的文件服务器。
这个机制基本上是 BT 的 P2P 原理再加上一个简单的加密机制来确保用户的数据安全。用简单一点的话来描述,就是用户的每一个终端都开着 BT 对同一个文件做种,文件一有改动,那么其他终端上的文件自然就会重新下载,并且这个种子是加密的,只有授权用户才能打开。
笔者不知道 BitTorrent 是基于什么样的理由开发的这套系统,但是对于个人用户来说,这套系统真的一点都不实用,理由如下:
我必须保持有一个终端始终在线,或在关闭一个终端之前打开另一个终端,否则文件不会被同步。
终端与终端之间的同步速度严重受到其中单一终端的上传速度限制。
一旦我所有的设备离线,那么我将无法访问到我的文件,这意味着这套系统用在手机上的可能性几乎等于零。
因此,BitSync 现在是和 Dropbox 完全不同的产品。它的适用范围可能是内网的文件部署,而不是给用户在多个终端上做云存储和同步。
那么,BT 技术能不能用在云存储上呢?
答案应该是可以的,既然 BitSync 能对数据安全进行保证,那么 BT 网路就能用于组建云存储平台。
首先,我们要明确一点:BT 的优势在于众人拾柴火焰高,当有越多用户加入到一个 P2P 网络的时候,共享的速度就越快,文件存续时间越长,整体稳定性越高。
现有 BitSync 在组网逻辑上完全忽略了这一点,每个用户的多个终端之间建立起一个小网是不利于发挥 BT 网络的设计的。
在设计基于 BT 的云存储的时候,应该更加贴近现有的 BT 网络设计,原理设计图如下:
假设紫色的 File Source 和粉红色的 Destinastion 为我的需要同步的两个终端。文件从紫色终端发布,经由蓝色 Bit Cloud 服务器路由,分发到绿色的其他用户(我完全不认识他们)终端。当分发结束后,我关闭了紫色终端,此时打开粉红色终端,Bit Cloud 服务器告诉它我的文件都被分散存储在了哪些其他用户的电脑上,然后粉红色终端则可从其他用户处(此时他们是种子)获取文件的碎片,在本地还原成原始文件。
图中的 Bit Cloud 并非是一个中心存储服务器,而是指在 BT 网络里比较常见的 Tracker 服务器(亦或是电驴里的 peer 服务器),它的主要作用是用于记录整个网络上有些什么文件,这些文件被分散在了哪些用户的客户端里,这台服务器不存储任何数据,它只记录数据和用户信息。当然,如果为了保证去中心化的设计,也可以利用 Peer exchange 和 DHT 技术将 Bit Cloud 服务器从组网结构中去掉。
与传统的 BT 下载不同的是,每一个帮助他人存储文件的 Seed 并不需要完整的存储别人的数据,一个 100K 的文件可能被分成了 4 份,100K 文件的每 1/4 又分别存储在了 4 个 Seed 终端以确保单个 Seed 下线时文件可用。
当然,每一个 File Source 和 Destination 在别的用户眼中看起来都是绿色的 Seed。
所有的文件碎片都是经过加密的,虽然每一个 Seed 都有我文件的一部分,但只有拥有密钥的文件持有者才能够将他们组合起来还原成原始文件。
优势:
彻底的云存储,再也不用担心数据被第三方服务商泄露。
像 Dropbox 一样即便是我的每一个终端都离线了,文件也没有从网络上消失,本质是一种备份而非简单的同步。
BT 网络可以自行选择速度较快的其他用户作为 Seed,文件的下载速度不受单个节点的速度限制。
为了保持稳定性,每个文件一定被重复存储了多次,也就是说。网络上每有一个文件加入,整个网络内的总存储量消耗要为文件容量的 N 倍。因此,在这个组网逻辑成立之前还必须引入一种新的算法来衡量用户的可利用空间(类似于 ED2K 网络的积分系统):
当用户接入一个 BT 云网络后,网络会初始的分配给用户一个可用容量(如:5GB),BT 云客户端则会立刻在用户硬盘上划分出 5GB 以上的容量备用。用户往往不可能立刻将此 5GB 空间完全填满,那些 5GB 以内没有被填满的部分被称之为 Seedbox,用于存储来自于网络分配的存储任务。当然,你也可以为了获取积分而主动划分更大的 Seedbox 空间。
当用户持续在线一段时间后,网络会根据用户所能提供的 Seedbox 空间、网络负载能力在线时长等因素来调节用户的积分,而积分则最终影响每一个用户自己的可用容量。
一些其他的细节补充:
当文件在第一次被加入同步网络的时候,中心服务器随机选一些在线的用户作为 Seed。同一文件 Seed 数降到警戒线以下(许多人同时下线),中心服务器(或算法)调度其他 Seed 救场。
保密机制有两个: 任何一个 Seedbox 里不会存储任何一个完整文件,全是来自于其他用户的文件碎片,只有正确的密钥才能获得组成一个正确文件的文件碎片;文件本身先加一次密再拆散发布。
P2P 结构并不一定和传统的自建数据中心的云存储服务商有冲突,云存储服务商可以将自己的存储服务器作为一个 Seed 使用。
到这里,一个比较完整的基于 P2P 的云存储方案就诞生了。那么,会有人来把这个想法付诸实践么?