p2p型blog的优缺点及其原理讨论

一、什么是p2p型的blog？有什么优缺点？
再强调一次，我所理解的“p2p”是"person to person"的意思，也即是抛弃中心点、个人面对个人直接地直接交流的意思。p2p技术几乎可以让网络上现有的一切服务的质量都有质的飞跃。例如传统的http或ftp文件下载服务，完全可以用bt的思路改造，从而达到对服务器的依赖最小、下载性能极大优化的目的。
blog作为web2.0时代的一个标志性服务，它是有“去中心化”的意愿的。很多bloger都自己架起了blog服务器。可是毕竟架设blog服务器需要一定的资金和一定的时间，并不适合与普通网民使用。但是我们如果采用p2p技术，让任何一个网民都可以在本机（甚至是局域网内！）直接写blog，那么该多好啊。
这样的blog系统的优点有：
    1、个人架设blog的成本为零。只要拥有一台可以上网的电脑即可，唯一麻烦的地方是最好24小时开机。甚至不必有公网IP，P2P系统可以设计为跨局域网的，详见后面实现。
    2、blog的容量是无限大的。你在你的本地blog上放一万张图片、一千部电影都没问题，只要你的硬盘足够大。
    3、发表blog变得非常容易。没有上传的问题了，你就是直接在本机上写blog，保存到本机。
    4、速度飞快。因为它使用了类似于BT的分布式下载技术，有“浏览的人越多，速度越快”的特点。详见后面的原理部分。
    5、blog的程序自己可以完全控制。p2p型的blog程序可以在本地机器上有完全的运行权限，不管什么程序都可以跑。这一点对普通的bloger的吸引力不够大，但其实它非常重要。它意味着这个blog的开放性，任何程序员都可以轻而易举地在这个平台上开发blog服务程序。
说了这么p2p型blog的优点，该说说它的缺点了。下面两个简直是p2p系统的致命弱点：
    1、p2p型blog服务与普通浏览器不兼容。访问者只有用专门的软件才能访问。
    2、p2p型blog服务程序难以直接使用现有的blog服务程序。什么.text系统，什么wordexpress系统，统统不能直接使用。rss和atom也要开发专门的插件后才能使用。
这两个难题的解决方法已经超出了技术的范畴，这里就不再讨论了。

二、p2p型blog的思路要点
前几天的一篇文字中已经说过，p2p系统的一个特点就是每个peer的性能都很糟糕，所以p2p系统一定要使用分布式下载的方法，以便提高下载速度。分布式下载还有利于进行NAT穿透：即使双方不能直接收发消息，系统也能从其它人那里取得所需的数据。
那么我们应当怎么应用分布式下载的方法呢？
先考虑传统的方式是怎样的。每个浏览者都是直接从消息发布者那里查询信息和下载文件，这样的系统是很容易实现的。浏览器与blog发布者联系，取得blog目录。用户点击哪个标题就向发布者取哪个网页回来显示。当用户准备发表评论时，直接将评论发送过去。这一切都非常简单。

那好，我们下面来考虑如何将上面的流程改为分布式下载的。

第一步，将blog目录信息打包成一个文件。这个文件可以共享出去，让用户以分布式方法下载。
这个文件的更新是比较频繁的。blog的一切变化都反映在这个文件里了。当用户有新blog发布，或者有新的评论到来，或者blog中涉及的文件作了更改之后，系统都应当自动生成一个blog目录文件，并且将其共享出去。blog目录中包含有每篇blog的hash。这个文件的下载是很频繁的，所以应当尽量设计得紧凑一些。
浏览者想看发布者的blog，他就与发布者联系，取得blog目录的hash及文件大小。然后他就可以用分布式的方法来下载这个文件，一般来说，下载速度会很快。下载到本地之后，解释显示此文件，即可得到该用户的blog目录。

第二步。blog目录中包含有每篇blog的hash。发布者在发布blog的时候，每个blog必须生成一个文件，并且计算出了hash、向p2p网络提交了共享。所以浏览者根据blog目录中所包含的blog hash，也能用分布式的方法下载每篇blog。

第三步。下载blog中引用的图片、音乐等附件。注意，blog文件中引用其它文件（如图片等），不能直接根据URL引用，而是必须提供文件的hash，而且该文件必须是已经在网络中有共享的。

为了充分利用分布式下载的优势，文件划分的越小越好。越小的文件，变化的可能性就越小，能分布式下载的可能性就越大。一张图片可能被很多篇 blog引用。如果图片被集成到了blog文件中，那么浏览者每下载一篇blog就要下载一次那张图片。但如果图片是独立的，那么用户无论浏览多少篇blog，只要下载一次那个图片就足够了。而且，浏览同一篇blog的人不会太多，但是浏览引用了该图片的blog的人却会多很多。
“文件重用”原则与面向对象的“代码重用”的原则是类似的。文件划分得越小越好。面向对象设计中，也提倡将对象尽可能的设计得小一些，一个小功能就一个小对象。小，才好重用。
举个反例。如果我们把整个blog所有的内容都打包成一个文件，那么用户除了要下载很多他不想看的资料之外，他还很难找到同样拥有这个文件的用户。因为信息发布者的blog有只要有一个小小的修改，整个文件的hash就是完全不同了。

第四步。
我们还要考虑blog评论的问题。一般来说，blog的正文是很少变化的。用户写完一篇blog之后就很少会修改它的内容。
但blog发布之后，浏览者会对它进行评论。
要利用分布式下载的优势，我们必须区分出系统中的哪些部分是经常变化的，哪些部分是稳定的。经常变化的部分和稳定的部分不要打包在一起，否则会导致稳定部分也不能分布式下载。这个原理与面向对象设计的原理也是很像的，即：不要把易变的部分和稳定的部分糅合在一起，应当用不同的对象（文件）将它们区分开，以便缩小变化所产生的影响。
所以，blog正文和它的评论不能打包在一起。

结论：
所以，一个p2p的blog系统应当是这样的：
每个用户的blog目录作为一个文件共享出去；
每篇blog的正文打包成一个文件；
blog中引用的其它文件也单独共享；
每篇blog的评论也打包成一个单独的文件共享。

这样的设计之后，用户的信息就组成了一棵树。通过树的根（blog目录的hash)，可以找到所有的blog，进而找到blog所引用的图片．
这里有一个规律：任何一个节点的变化，都会导致它的父节点的变化，并且这个变化一直向上传递下去，直到根节点为止．所以这样的一个blog实现，如何维护这样一棵树，是一个重要的问题．否则，很容易形成一大堆的死链接．

这样的设计之后，浏览者必须从信息发布者那里获取的，只有一个hash码（blog目录文件hash）。其余的所有信息，都是利用了分布式下载的机制下载的，保证了下载者的下载速度，也节省了发布者的带宽。
在这种情况下，系统还可以考虑提供一个中转服务器，将对等点之间的连接率提高到100%，那么就不会产生因NAT打孔失败而导致无法连接的情况了。这个中转服务器不会太忙，因为对等点之间必须直接通讯的信息不多。
这种系统还很容易实现权限控制。blog目录hash必须从信息发布者那里获得，所以发布者可以准备多几个目录文件，针对不同的访问者返回不同的目录文件hash。这样就达到了浏览者权限控制的目的。