现象描述使用成都电信ADSL网络，浏览器使用Firefox3.0.3，安装了GoogleToolbar工具。在GoogleToolbar工具栏中输入任何搜索词，始终发现浏览器状态栏快速的闪动了一个非google的地址，然后又访问google网站返回搜索内容。仔细观察状态栏该地址，发现地址为”search.cninspirit.com”。把GoogleToolbar各项设置重置已经升级到ToolbarBeta均发现每次如此。

　　为什么？开始我感到很：google和一个cninspirit的网站肯定不会有什么合作，搜索这个关键词也没发现任何有用的信息；浏览器为网站下载，也没有安装任何可疑的插件及扩展。从客户端已经找不到任何合理的解释。只有打开wireshark抓包对HTTP会话和网络流量进行仔细的查看。

　　这个会话看上去非常的简单，一段单次的HTTP会话；如果这些包本身还不能说明问题的话，我们可以看看这次会话传输的内容—选取其中一个包，在Wireshark中，单击右键，选择”FollowTCPStream“，我们能看到第二幅图：

　　第一眼就发现，来自(G)的第一段回应不是一个的HTTPResponse!-开头就是HTTPBODY的内容而没有任何的HTTPHeader。各位，你相信Google的Web服务器会不遵循HTTPRFC吗？很遗憾，Firefox相信了并且了这一点，也不能怪firefox，RFC对协议实现的要求中一条很有名的原则就是“严于律己，宽于待人”，即尽量对自己发送的数据要符合RFC规范，对自己接受的数据做规范内的最大。第二眼就会发现，来自(G)的一段回应内容也很诡异：非常简单的一个表单，然后再加载一个来自使用IP地址(的javascript脚本。通过whois查询发现该IP地址NETNAME是CHINANET-SC，属于中国电信四川省。

　　http192.168.1.100到这里也许您会想，这说不定是google的策略呢，把搜索业务和当地ISP合作，提供更好的服务，请继续往下看。

　　通过以上分析，基本可以断定以下事实：

　　从C到G（Google网站）的TCP会话正常建立后(103-105)，C发出的HTTP搜索请求(106)被一个离客户C很近的设备给劫持了，伪造了来自G网站的数据包，并且很快的(~68ms)返回了HTTP回复(107)，而且该回复并不符合HTTPRFC规范！该回复内容是让浏览器下载一个来自IP地址(的javascript脚本，该脚本内容是提交搜索到search.cninspirit.com，这是为什么能在浏览器状态栏中看到访问该地址的原因。来自伪造G网站的数据包继续完成了与C客户的TCP会话过程(108，111，112，117)；而在这时，真正来自G网站的数据包才到达C客户机，然而该TCP会话已经被来自伪造G网站的数据包正常终止，因此C客户机向G网站发送了连接已经不可用(RST)的信息(122).

　　中国电信，一坨狗屎！