基于Html5缓存的页面P2P技术可行性探讨

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

P2P技术，在分享大文件（你懂的）是现在必不可缺的技术，现在的人，已经很难想象在没有这玩意的互联网早期，人们是怎样的艰难求生。想当年，不要说电影，下一个稍大点的文件，都是很吃力的事情。

后来牛人科恩，发明了P2P技术，见这里【科技英雄传】BitTorrent技术之父：科恩

P2P技术发明后，其互联网带宽占到了7成以上，可见此技术的威力，网络有多快，分享就有多快，速度不在受到终端或服务器限制，而是受到网络，也就是道路的限制。真正回归到网络的本质。

作为程序员，我们经常为一个问题苦恼，就是性能，怎么让服务器支撑更多的人，更多的访问流量？这是一个大问题。

我们看看传统的解决方案，不断的提高服务器的并发，使用服务器缓存，使用大数据，使用分布式数据库，使用CDN，加CPU，加内存，加带宽，限制用户数，等等等等。这些手段，都是治标不治本，中心或分中心模式，不管怎么做，最终都有问题，这也不是网络模式。这就和买票一样，都跑一个地方买，再快的抢票软件也一样没用。

那么，有没有可能，象P2P一样，把网页也给P2P了呢？从原理来看，其实是可行的。

原理是这样的，比如我访问这个页面，那么数据已经在我浏览器里了，但是，我浏览器里的内容可以分享啊，通过P2P技术，其它用户相互间分享同一时间的同一页面内容，和P2P原理一样，同一页面访问的人越多，那么速度反而越快。

如果有人能搞出页面P2P技术，那么世界将再次被改变，任何页面，都可以支撑全球所有的访问量。从此网站再也不怕大用户，用户越多，网站越快，刚好和现在的模式相反，我们再也不需要优化网站了。

但是这种一篮子的解决方案，可不可行呢？有没有人能搞出来呢？从原理来看是可行的，但实际上很困难。原因是很多页面不仅仅只是静态内容，而且页面很复杂，文本，数据，图片，甚至视频。

但是部分的解决方案还是有的，比如云服务，把图片，视频等放在第三方，CDN服务，把一些公用代码放第三方，还有网页加速服务，比如什么数字的风行计划，给网站缓存加速。

当然了，上述这些解决方案，都是很费事又费钱的东西，最好就是浏览器支持本身支持网页P2P，但这个技术看上去，这几年都不用指望了，作为创业者或中小企业网站，有没有成本更低廉的办法，解决性能问题？

这就可以使用一些Html5的先进技术了，Html支持本地存储，和本地缓存，但对于动态加载的页面可能还需要自已进一步编码，如果我们把样式表，代码，通用数据，图片，在第一次加载后，再用脚本方式存在本地数据库，当然这得需要一个版本管理技术。

这样的话，除了第一次慢点，以后因为有大量内容被缓存到了本地，那么Web应用就有点类似传统的C/S应用了。服务器端的压力被大大减轻。

但是，用户多了服务器还是一样有性能问题，能不能在A客户缓存了本地数据以后，B客户访问网站时，直接把A客户，导向B客户，让A客户取得B客户的缓存数据呢？

答案是可以的，但不是现在，W3C正在开发P2P浏览器标准，让你的浏览器和他的浏览器实时通信，不需要经过服务器，可见此技术，在将来是可行的，但现在没有足够的支撑。

由此可见，现在如果利用Html5技术，解决如下几个问题：

一是本地存储的版本问题，这样服务器更新后，就从服务器上取新数据，如果没有更新就读取本地缓存。

二是本地存储的读取写入，以及路径问题，这需要有一种机制，让应用不需要管数据的来源是本地还是服务器，把资源路由交给一个统一机制，由它去判断

版本问题有比较现成的解决思路，比如时间过期，或者是版本号，加个二维码什么的。资源路由就不太清楚，这需要进一步的摸索。但是，优先考虑Html5的本地存储及缓存技术，应该是一个低成本解决性能问题的方案。而这种方案，还可以为将来到来的浏览器P2P做准备。