之前自己实现了一个代理服务，当时考虑的是只要支持SOCKS5就好了，因为我经常用CHROME，配合着SwitchySharp，体验还是很棒的。但是我现在有点讨厌CHROME，它现在太庞大了，占用资源太多了。而且我有锁定网页的习惯，一打开CHROME，就十几个甚至二十几个进程起来，让我很不爽。但是不得不说CHROME的安全设计还是非常棒的。然后我就试了下FireFox，额，我觉着它和IE差不多.然后就放弃了，然后看看了手头上的IE已经到11了，平时用起来感觉还是很不错的，所以我想支持IE的代理。
IE的代理机制比较囧，比如说它只支持SOCKS4，不支持SOCKS5，然后又分为HTTP代理，HTTPS代理，还有FTP代理。也没有像CHROME提供强大的代理插件机制。虽然IE提供了PAC机制，但是不得不说，这个机制也很鸡肋，没有像SwitchySharp那样可以做到实时的增减规则。针对以上原因，我就在原有的代码基础上增加了上面的几种代理，不过没支持FTP代理。
SOCKS4代理
SOCKS4协议比较简单，可以参考的文档是WIKI的这篇，还有OpenSSH的这篇。后面还有个SOCKS4A协议，不过这个SOCKS4A基本上没见到人用过。SOCKS4协议的CONNECT命令格式很简单，就一个请求包和回应包。请求包的第一个字段是版本号，占用1个字节，就是0x04，第二个字段是命令类型，占用1个字节，0x01表示CONNECT命令，即请求链接哪个IP : PORT，0x02是BIND，一般用于FTP场景，我没有实现。第三个字段是对端端口，占用2个字节，字节序是网络字节顺序；第四个字段是对端IP，占用4个字节，字节序是网络字节顺序；第五个字段是USERID，可变长度，以0x00结尾。这里要注意的是，在IE11下，USERID为当前用户名，不会为空。所以要读取完整的USERID和最后的0x00。
回应包第一个字段占用一个字节，数据为0；第二个字段占用一个字节，表示状态，0X5A表示成功，0X5B表示拒绝或者失败等等；第三个字节和第四个字段一共6个字节，会被忽略，直接填0即可。
整个协议简单很多，比SOCKS5简单多，但是没有SOCKS5强大。因为SOCKS4只支持IP : PORT方式，也就意味着IEFQ的时候，会自己先走本地DNS，然后拿到地址后才去走SOCKS代理。这里带来的问题是，如果DNS被污染了，就意味着FQ失败了。所以还得用后面的HTTP代理和HTTP隧道。
HTTP Tunnel (HTTP隧道)
HTTP隧道比较简单。就是客户端通过HTTP协议链接到服务端，请求服务端去链接某个域名或者IP的某个端口。协议非常简单，即客户端发送CONNECT Domain : Port HTTP/1.0\r\n\r\n。服务端收到该请求后会去链接指定的域名和端口，链接成功后，会回复客户端HTTP/1.0 200 Connection established\r\n\r\n 客户端收到该回复后，就开始把数据通过代理转发过去。这个时候的代理是盲转，和SOCKS协议一样。
用GO实现的时候也相对来说比较简单，通过net/http包即可完成。自己实现一个ServeHTTP方法，然后发现是CONNECT方法的请求就把连接Hijacked掉。具体代码如下：
hj, ok := response.(http.Hijacker)
if !ok {
http.Error(response, "Hijacker failed", http.StatusInternalServerError)
return
}
conn, _, err := hj.Hijack()
if err != nil {
http.Error(response, err.Error(), http.StatusInternalServerError)
return
}
defer conn.Close()
要注意的一点是Hijack后，如果要回复HTTP协议格式的数据，就要自己去操作了，没有办法再使用net/http.ResponseWriter提供的方法了。好在GO的fmt包提供了Fprint/Fprintf函数，所以操作起来也还算简单。
另外一点是，这个HTTP隧道允许在CONNECT发起时，在BODY里携带额外数据以达到优化的目的。所以还要在建立远端链接后，检查是否还有BODY数据，如果有的话，就把数据发出去。
HTTP Proxy
我原先认为的是既然有了HTTP隧道方式的代理机制了，那就都用这套呗，结果IE不这样，HTTP隧道只用在了HTTPS类型的URL，而普通的HTTP URL则走的是普通的HTTP代理机制。HTTP普通的请求类似于下面这样：GET /xxx/yyyy/zzzz.html HTTP/1.0，而HTTP代理则是GET http://www.qqqq.com/xxx/yyy/zzz.html HTTP/1.0，然后还会增加一个额外的HTTP首部Proxy-Connection。这个首部用来干嘛的自行GOOGLE。处理客户端发来的HTTP代理请求时，我的做法是把URL替换为正常的相对URI，然后检查是否存在Proxy-Connection，如果存在，则获取对应的值，并删除该首部，并添加Connection首部，其值为原Proxy-Connection对应的值。然后转发到对端服务器。 GO提供了一个包net/http/httputil，其中封装了一个反向代理的实现。只需要提供建立链接的函数以及对http.Request处理的函数即可。代码具体如下：
func NewHTTPProxy(remoteSocks, cryptoMethod string, password []byte) *HTTPProxy {
return &HTTPProxy{
ReverseProxy: &httputil.ReverseProxy{
Director: director,
Transport: &http.Transport{
Dial: func(network, addr string) (net.Conn, error) {
return dial(network, addr, remoteSocks, cryptoMethod, password)
},
},
},
}
}
func dial(network, addr, remoteSocks, cryptoMethod string, password []byte) (net.Conn, error) {
tcpAddr, err := net.ResolveTCPAddr(network, addr)
if err != nil {
return nil, err
}
remoteSvr, err := NewRemoteSocks(remoteSocks, cryptoMethod, password)
if err != nil {
return nil, err
}
// version(1) + cmd(1) + reserved(1) + addrType(1) + domainLength(1) + maxDomainLength(256) + port(2)
req := []byte{0x05, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
copy(req[4:8], []byte(tcpAddr.IP.To4()))
binary.BigEndian.PutUint16(req[8:10], uint16(tcpAddr.Port))
err = remoteSvr.Handshake(req)
if err != nil {
remoteSvr.Close()
return nil, err
}
conn := &HTTPProxyConn{
RemoteSocks: remoteSvr,
}
return conn, nil
}
func director(request *http.Request) {
u, err := url.Parse(request.RequestURI)
if err != nil {
return
}
request.RequestURI = u.RequestURI()
v := request.Header.Get("Proxy-Connection")
if v != "" {
request.Header.Del("Proxy-Connection")
request.Header.Del("Connection")
request.Header.Add("Connection", v)
}
}
总结：
本质上HTTP代理和HTTP隧道可以通过同一个端口实现的，但是我没有这样去做，因为我觉着代码分开更方便测试和修改。可以省去很多的麻烦。不过通过简单的组合也一样可以复用同一个端口，我后面会试着去修改。HTTP PROXY和TUNNEL现在在同一个端口实现，通过简单的组合就实现了对应的功能。而SOCKS4和SOCKS5按理来说也是可以用同一个端口的，但是考虑到代码中要判断版本之类的问题，我觉着这样还不如直接分开实现来的简单。
后面还可以考虑的是把SwitchySharp的代理策略移植到该代理服务上，然后再写个IE插件用来实现类似SwitchySharp的功能，这样的话，会方便很多。顺便说下，其实现在IE做的很不错。