.CO域名快被这帮搞IT的玩坏了……

鉴于近来国内访问Google的服务受阻，greatfire.org于前天推出了其基于亚马逊AWS的Google搜索镜像网站，地址是sinaapp.co。该网站随后因多家海外媒体的报道和众多微博大V的转发而一炮走红。我们不用想都知道，其结果必然是接受入侵检测装置的认证。不过比较狗血的是，新浪SAE旗下的sinaapp.com域名因为域名中也含有“sinaapp.co”字样，所以随同singaapp.co一同受到了“特殊照顾”——当从海外访问sinaapp.com域下的应用时，都会提示“连接被重置”。

虽然“认证”随着新浪方面的积极奔走而被取消，但这种使用知名网站类似域名的方法显然被玩坏了——greatfire.org的所有者随后注册了baidustatic.co（百度）、alicdn.co（阿里）、gtimg.co（腾讯）等国内知名网站的相似域名并指向其镜像网站。在V2EX上，有网友建议再注册几个诸如inhuanet.co、anqiu.com之类的域名；甚至有人YY，要是注册个chinamil.co域名然后被BLOCK掉，PLA会是什么反应。在我写这篇文章时，我发现chinamil.co确实已经指向过去了，不知后面会如何……

.CO域名之所以被众挨踢男玩坏了，完全是因为入侵检测装置在对用户访问的URL进行分析时，并不是仅仅提取出其中的HOST部分，而是对整个请求URL进行匹配。我们甚至可以发现，即使这些字符只是出现在请求参数部分，连接也一样会被阻断。

我一直在考虑一个问题（纯技术角度），为什么是对整个URL、而不仅仅是HOST部分进行匹配呢？从HTTP协议来讲，HOST部分和请求参数是分开的，单独对HOST部分进行匹配效率应该更高才对啊，为什么还要匹配请求参数呢？从我的个人经验来看，我觉得主要是两个原因吧：

第一、干掉那些把访问地址“明目张胆”地放到URL参数中的Web代理服务器。早期的Web代理服务器经常是直接把请求地址加入到URL参数中，比如经由Web代理访问http://www.a.com/index.html时，早期的Web代理请求的URL就是http://webproxy/www.a.com/index.html。显然，通过检测请求参数（”/www.a.com/index.html”）便能发现Web代理的真实意图，从而在请求连接阶段就把连接干掉。

第二、一些URL参数中是含有具体内容的，如果发现这些内容中含有敏感信息，便可以趁早采取下一步的措施，比如立即将”RESET标志位“置1重置连接。将连接在发起阶段干掉，便可以避免对连接建立后返回的数据再次进行深度检测，从而降低了负载。

PS：其实这种玩法我几年前就已经想到了，只不过没打算打”擦边球“，所以只是想想罢了。