虽然现在我的Ubuntu下已经有了一堆翻墙用的代理软件（没边、门、eTunnel……），但经常速度不甚理想，而且学校校园网的电信出口经常被挤爆，而教育网出口是空的，所以使用Sogou提供的免费教育网代理是个不错的解决办法。

把Sogou弄到Ubuntu下的Wine环境没有任何难度，把Sogou的安装文件夹全部复制到~/.wine/drive_c/sogou下，运行的很正常：

pentie@pentie-desktop:~$ wine "C:\sogou\SogouExplorer.exe" -proxy
fixme:win:EnumDisplayDevicesW ((null),0,0x32f3c4,0x00000000), stub!
fixme:wtsapi:WTSRegisterSessionNotification Stub 0x1002a 0x00000000
fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080
fixme:mountmgr:harddisk_ioctl unsupported ioctl 2d1400
fixme:mountmgr:harddisk_ioctl unsupported ioctl 2d0c10
PID:8
PORT:8081
CPORT:8082
PAC:http://127.0.0.1:8082/proxy.pac?t=626
RET:SUCCESS

在配置Firefox的FoxyProxy，可以像平常那样添加127.0.0.1:8081作为代理，但既然提供了PAC，不妨试试：在Automatic proxy configuration URL内添入“http://127.0.0.1:8082/”，按Test，说找到PAC，解析成功！确定后右下角也出现FoxyProxy的提示。此时在Firefox中打开的网页都是通过Sogou的免费代理了！不过发觉现在的代理速度没此前那么快了。

Ubuntu中有一个工具可以配置全局代理，gnome-network-preferences，运行它可以轻松的让apt-get、telnet之类的程序通过代理来连接外网。

再一次提醒的是，Sogou浏览器代理是“透明代理”，它会转发你的真实IP，没有任何匿名功能，因为他们的服务器也在国内（北京），因此也不会有翻墙功能。

参考了别人的网志：http://dan.febird.net/2008/12/firefox.html

已知缺陷：在流量和连接数比较大时（比如刷开Google Reader），wine出来的SogouExplorer进程占用大量CPU资源，可能是某链接库匹配问题，以致这个方法的实用性不是很高。

搜狗浏览器的教育网加速功能，对n多在学校使用校园网的用户来说可是福音，更别提其附带的翻墙功能。自从搜狗浏览器发布那天起，我就对其所用的代理服务器虎视眈眈：要是能在其他浏览器使用，多好啊……

早前，用Wireshark嗅探搜狗连接加速代理的数据包，找到如219.234.81.(64/65/)66、219.234.81.（35/36/37)等几个服务器，看其发送的数据包，好像和HTTP代理差不多！试着将其加入Firefox的代理……果然吃的是闭门羹：Try Sogou Explorer now!

也看到搜狗发出的HTTP GET带有一些私有头部X-Sogou-XXXX的，估计有一些校验机制，就暂时放下了。

这几天校园网特别不稳定，又打起搜狗的主意。

感谢Python能够用这么简单的语句给我提供实验的环境，现在已经肯定下面的代码能够通过搜狗的代理访问到google的主页！程序输出的确实是Google的HTML代码！

#!/usr/bin/python
 
import socket, sys
 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 
s.connect( ("219.234.81.66", 80) )
 
data = "GET http://www.google.com/ HTTP/1.1\r\nHost: www.google.com\
\r\nX-Sogou-Auth: 438892784B65C0ADAB8B42F1BF6E7984/91/1ac66c2d240157be\
\r\nX-Sogou-Tag: 82cfc55e\r\nX-Sogou-Timestamp: 49a7fa22\r\n\r\n"
 
s.sendall(data)
 
while 1:
    buf = s.recv(4096)
    if not len(buf):
        break
    sys.stdout.write(buf)

然而，现在高兴还为时过早，这个程序我发送的HTTP头信息如下：

GET http://www.google.com/ HTTP/1.1
Host: www.google.com
X-Sogou-Auth: 438892784B65C0ADAB8B42F1BF6E7984/91/1ac66c2d240157be
X-Sogou-Tag: 82cfc55e
X-Sogou-Timestamp: 49a7fa22

已经确定这三个X-Sogou是必须的头验证，缺一不可，改掉其中任意一个的值，也不行。

其中X-Sogou-Auth的值一直不变，估计和系统、硬件有关。

X-Sogou-Tag一直在变，摸不清头绪。

X-Sogou-Timestamp似乎如其名字，和时间有关，每次发出都大概和秒表一样加一。

……  ……  ……  ……  ……  …… 接下来做了以下的猜测：

X-Sogou-Timestamp似乎是一个数值，按16进制输入计算器，将其转换成10进制数字，得到1235745314……恩，想起之前外国很多IT媒体都在兴奋的报道，情人节那天，Sat Feb 14 07:31:30 CST 2009——的时候的Unix时间值是1234567890，难道这个就是当前的Unix时间值？马上验证：

>>> time.ctime(1235745314)
'Fri Feb 27 22:35:14 2009'

强大！果然是刚才的时间！貌似看到希望的曙光了！

…… …… …… …… …… …… ……

然而，过了n久，运行刚才的python脚本，依然可以正常输出！看来代理服务器并没有校验Timestamp的值是否合理……那么唯一的解释，就是用Timestamp来做验证的密码了……

观察X-Sogou-Tag，刷新一个网页往往会发出很多个连接，包括图片、css文件什么的，发现同一秒中发出的连接，Timestamp值相同，Tag的值也相同！Tag由Timestamp决定！

…… …… …… …… …… …… ……

继续观察，发现Timestamp相同，但是域名不同的网站，Tag也不同，X-Sogou-Domain也不定时出现……

…… …… …… …… …… …… ……

哎，可恶的Tag，貌似Out of my reach了……看来自己还是当不成黑客，密码学领域知识很空白……对数字也没那个敏感……

收获就是对HTTP头的结构了解……上网查过，居然没有一点资料详细说！害我在wireshark里面对着那些16进制一个个字节的看！