前阵子，百度网盘提供免费申请100G空间，当时一则出于好奇，二则自己移动硬盘由于使用了BT，悲催的经常出现报错，就想借此机会将文件传到百度上暂存下，腾出空间好好整理下移动硬盘，就也弄了一个帐号。100G，加上原来的5G，一共105GB到手，正好今天有时间，就准备将移动硬盘数据拷贝上去了。打开百度云-网盘之后，出现下面图：
注：此图片来源网上，本地的截图由于已经使用了极速控件，没法操作。
下载安装之后，就是个IE插件，然后我们来体验下吧，体验截图如下：
前三个文件，状态开始是文件比对...，而后，立马上传成功，果然秒传啊，心想要按这个速度，上传所有的文件基本上就是分分钟的事情啊，结果，在第四个文件的时候，它开始慢悠悠的给我上传了，速度稳定在60Kb左右，汗！这速度，要传完所有的文件，那是得猴年马月？这也算极速秒传。石化片刻之后，我终于明白它这极速秒传是怎么个一回事了。在让我下载的插件无非就是个HASH工具，然后将我本地文件和服务器已有文件进行比对，如果有，就直接使用服务器文件 —— 这就是秒传！ 没有的文件，就慢悠悠的给你上传。
好吧，如果按照他这个秒传的概念，我们也非常容易的实现秒传功能，就一个文件HASH嘛。那趁着现在还在上传这档口，来自己设计一个简单的秒传架构吧。
原理篇：
要实现秒传，最核心的就是建立服务端与客户端的文件比对功能，这个比对当下可以用的有MD5这样的算法或者其他HASH算法。其步骤如下：
1. 让用户下载客户端，这个可以是浏览器插件，也可以是客户端软件 —— 百度这里是IE插件；
2. 在文件上传之初，将本地文件进行HASH计算，得出文件指纹；
3. 将文件指纹数据上传到服务器；
4. 服务端将文件指纹和现存的文件指纹进行比对，并返回比对结果给客户端；
5.客户端获取比对结果；
6. 如果是比对成功，则说明服务端已经有同样的文件存在，则直接将文件名和指纹及文件标识符一并上传到服务端，而服务端在接受到之后，只是将文件名存放在客户的名下，文件则是映射到原有文件的路径中，返回秒传成功信息；
7. 如果比对不成功，就变得和普通上传并无二致，老老实实的通过HTTP的方式，将文件1比特，1比特的上传到服务端。
好吧，这就是玄乎的文件秒传了。至于为什么要4GB的限制，这个个人初步认为是因为指纹计算也是需要消耗资源，如果文件过大，在计算指纹的时候，其占用资源也会相对较多，可能会造成一定的影响。真相具体为什么，还有请懂行的指点。
优势：
1. 对于服务端：进行文件的服务端比对，而后进行文件映射的这种方式，对于大型的存储来说，由于在服务端只存在一份文件实体，因此，对于系统的存储消耗将能极大的降低。特别是在文件数量达到海量，并且有很多重复文件时（多用户各自保存文件时），其效果更佳。
2. 对于传输的带宽：对于用户来说，由于服务端的海量文件，自己传输的如果是其中已存在的文件时，能够极大的降低带宽的占用情况。
劣势：
由于要实现秒传，并达到最优的效果，核心是要求服务端保存海量文件，而且及时所有用户将文件删除，服务端为了在下次实现秒传，都必须将文件保存在服务端，而不能进行删除。如果未被映射的文件数量巨大，这势必会增加存储成本。
隐患：
也许秒传给客户带来了便利，让我们感觉良好。但我们从秒传的原理中也不难发现其中的安全隐患。由于文件必须在服务端保留，因此，如果你传输到服务端的文件包含隐私，那么，一旦上传完成，你的隐私就永远的存在于服务端了，这就很难保证你的这些隐私在将来不会泄漏。如果真要使用这么一些个服务的时候，我们需要仔细的分析其中的风险。并且做出必要的决断。 —— 至少，在我看到这个功能之后，我当即就决定，只将自己的一些电影文件和其他不涉及隐私文件上传到服务端，而涉及到隐私的，或稍微敏感些的其他文件，我将用其他办法来处理。
没有软件能够保护隐私安全，为了自身的利益，他们只会在最大的可能范围能截取客户隐私，要保护这些敏感信息，只能靠你自己！