继续推荐一下Project Seattle


继续推荐一下Project Seattle

Published on Wed 03 Feb 2010 07:02 ( 1 month, 1 week ago)
GFW(Great Fire Wall) Cloud computing 软件 Idea sharing

上次简单介绍了Project Seattle这个P2P的云计算平台,以及对使用这种平台来防止网络封锁的思路。该项目的作者Justin Cappos在我这里留言表示他们会对此支持:

We'd love to support any use of Seattle for the reasons you mention. If you (or your readers) need any support or extra resources, just let us know! Thanks,

今天去Project Seattle简单看了下入门的sample,觉得从原理上来说,以此为基础来实现一个动态的proxy(不一定需要是http proxy)可能是可行的。我设想的基本思路是这样的:

1. 一个本地运行的客户端,如果成熟实现可以包含firefox的插件,就如同tor一样;

2. 该客户端从P2P网络上发现一个可用的节点,然后部署代理程序;

3. 客户端可以动态地改变提供代理服务的地址,动态改变代理的数据加密方法(有可能不必要,因为墙还没有这么聪明)

4. 客户端关闭的时候释放这个节点

如果在有大量可用节点的时候,并采用无中心化tracker来获取节点的方式的时候,这个方法比过去基于tor和GAE 的方法要难以封锁得多。 首先,由于代理程序是运行时动态部署的,节点也是动态获得的,因此针对特定IP地址的封锁和内容的过滤基本没法实现; 其次由于这些节点提供的功能是变动的,墙基本不能发现固定的目标,所谓以无招对有招, 不像任何普通的web代理一旦你共享出去就会成为被封杀的目标。Tor的节点也是动态的,但是因为tor的协议和算法是一致的,墙可以研究清楚后进行渗透打击,而这种方式,为特定客户提供服务的节点上跑得程序和协议都可能是动态的。

除非Seattle这种系统的协议本身能被发现和封锁,进而导致这个平台在墙后完全无法使用,否则这种思路貌似是很难打击的。另外节点的数量多少也是一个关键,如果没有足够多的参与节点,就不可能形成scalable的应用。

这就比如你认识很多墙外的朋友,每次你上网就随机找一个人帮你设个临时的代理,而且你们之间的数据加密也是临时协商的,这种情况封锁是极其困难的。利用这种p2p云计算平台,就是相当于把这个过程自动化,从而实现任何都可用的。

抛砖引玉的思路,有兴趣关心云计算和p2p的同学应该去看看Seattle。


Related posts:


Search related in web:

Custom Search

RSS Feed

One click subscribe this blog in your google reader!

Be social!


Want to say something here? please sign in



Blog posts link to this page
What are friends tweeting?
Tags cloud
Monthly Archives