使Flickr badge（html版本）正常显示的方法并借本文宣布flickr被封确实和gfw有关

方法就是把这段html放到你的页面的底部。其实这个不仅仅对badge有效，对任何的flickr图片引用都有效。

<script type="text/javascript" src="http://www.surfchen.org/scripts/flickr_gfw.js"></script>

当然，你也可以：
* 把上面的js拷贝到你的站点下，然后在页面html的底部用script引用。
* 或者把上面的js的内容以script标签形式写在你的页面html的底部。

原理就很简单，就是用js把img的src的域做个替换。我刚才发现其他域也开始有被封的迹象了，所以替换地址使用xdanger的安全链接。我推荐直接引用我上面的这段js，我这边只要更新，就所有人都可以更新了。

另外，我承认flickr被封和gfw有关。前两天，flickr的图片地址无法访问，很多人都在怀疑是gfw，我也很怀疑。但是我trace被封的相关域名之后，发现trace到了美国那边的路由，并没有在中国这边被截断，于是我认为和gfw无关。

不过我又去了解了一些技术上的信息，发现这个确实和gfw有关。

在大多数对gfw的工作流程的技术描述里，都会把封锁手段分为三个。分别是url过滤，内容过滤，ip过滤。我不知道在路由端是否可以对本次的tcp请求的数据包进行截获，组合，分析是否为http。我下面的说法假设路由是可以这么做的（应该是可以的，只是我对其中的技术细节还是没有做深入了解）。

url过滤，是在我们发出http请求之后，gfw检测http头信息中请求行和host信息，如果匹配，则中断该请求。
内容过滤，是对方服务器返回http请求之后，gfw对http里的实际数据部分进行关键词匹配，如果匹配到了，则截断剩下的数据传输。
ip过滤，是在我们发出请求之后（包括tcp,udp,icmp），gfw对目标ip进行匹配，如果匹配到，则中断请求。

也就是说，url和内容过滤，是和http这层有关的。也有人说应该和tcp相关，但是要知道，在一个http请求里，http的头信息和数据部分都属于tcp的数据部分。而在url过滤这个手段里，显然只对http的头信息进行了匹配，因为在flickr网页里大量存在着farm1.stat…这样的文本（也就是在http的数据部分里），但是flikcr的网页并没有被封锁。这也就可以解释了为什么我在trace flickr的图片域名的时候并没有被截断。因为trace是通过发送udp或者icmp包来实现的，这些包并没有包含任何和域名有关的信息。在trace之前，已经通过dns解析为ip了。

而trace wikipedia的话，就会看到在中途被截断，因为wikipedia是被封锁了ip了的。gfw根本不需要看你所发送的是什么，只要目标ip匹配到就截断请求。

为此，我输了五块钱，并宣布捍卫gfw失败！