有时候，我们自己处于一个相对封闭的内部网络之内。内网的防火墙只开放了一个HTTP代理服务器作为访问外界的接口。这时候，在内部网络中的很多应用软件就会受到限制。比如，telnet、email客户端、ssh客户端等。如果能够找到一个通过http代理服务器穿透防火墙的办法，那将会给自己带来极大的方便。socks2http就是这样一个软件，它在本地启动了一个socks 5代理服务器，然后把socks客户端的请求转化为http请求，通过http代理服务器转发到外网。
以前我曾经用过一次socks2http这个软件，但是忘了是什么原因，当时觉得很不好用，此后再也不用了。昨天正好有个场合需要突破防火墙的限制，正郁闷的时候，yboys给我提起这个东西，我才想起来，再研究一下它。其实我关心的问题有三点：
1. socks请求是如何转化成http请求的？
2. http是基于tcp的，而socks 5既支持tcp也支持udp。如果说通过http代理转发tcp包还能理解的话，那么udp又如何解释？
3. 为什么socks2http的使用不太稳定？有时候可以用，有时候不能用？
首先从http协议入手进行分析。对于http代理服务器而言，客户端取回一个页面的时候，使用的是GET方法。但是，一般来说，GET命令是不支持SSL的。因此，RFC2616中对http/1.0协议进行了扩展，增加了connect方法，专门用于实现针对SSL数据的http隧道。它的协议过程如下：
CLIENT -> PROXY PROXY -> CLIENT
——————————– ———————————–
CONNECT example.com:443 HTTP/1.0
User-agent: Mozilla/4.0
<<< empty line >>>
HTTP/1.0 200 Connection established
Proxy-agent: Noname-Proxy/1.1
<<< empty line >>>
<<< data tunneling to both directions begins >>>
实际上，client和proxy之间通过connect方法握手之后，proxy就纯粹是做client与目标服务器之间的TCP数据转发而已。注意，转发的数据只是tcp层的数据，proxy并不会解开或者修改ssl加密的数据。直到client或者目标服务器任意一方断开tcp连接的时候，proxy才会停止数据转发，并断开另外一方的tcp连接。
本来connect方法的提出只是为了解决ssl连接的问题，但是因为ssl数据是完全加密的数据，proxy并不能区分传输的到底是不是ssl的数据。于是，这个特点被人利用，实现任意的tcp连接。比如：通过“Connect smtp.foo.com:25 http/1.0”这个指令，就可以在proxy与smtp服务器之间创建一个tcp连接。从而实现了client和smtp server之间的tcp通信。
因为支持https的proxy容易被人用上述方法利用，所以网络管理员们希望找到一些办法来避免滥用。既然从内容上无法区分ssl数据，那么是不是可以从其它特征上区分呢？https服务一般绑定在443端口，所以，一些proxy软件被设置为只能connect 443端口。这样在很大程度上防止了这种滥用。对于作了443端口限制的proxy服务器，我们是无法直接利用它来实现我们的目的的。除非我们有办法修改目标服务器的端口号，比如把smtp服务器的端口号改为443。而这么做，往往是不现实的。
为了解决udp数据传输的问题，socks2http的公司专门设立了一个gateway，并且这个gateway绑定在443端口上，用于转发udp数据。当客户端要发送udp数据时，先通过proxy连接到gateway，并且把udp数据发送给gateway。Gateway是一个专门的程序，它负责把udp数据转发出去。此外，对于限制了443端口的tcp数据，同样也必须通过gateway来转发。
Socks2http这么好用，大家都用，socks2http的gateway就要不堪重负了。因此gateway是收费的，只提供给注册用户使用，非注册用户只能免费试用15天。socks2http的新版本（0.987）过了试用期以后，就不能使用了。0.92有破解版，但是只是破解了客户端，而不能破解gateway，因此只有找到不限端口的http proxy的时候才有意义。
综上所述，如果愿意花钱购买，或者在试用期内，socks2http不失为突破防火墙的很好手段。但是如果用破解版的话，socks2http的使用也是有很大局限性的，表现在两方面：1.不支持udp；2.必须找到一个不限端口的http proxy。