今天我调查了一下chrome浏览器对proxy的支持情况。
目前总体来说它支持两大类协议：socks和http。
其中socks下面又分为socks4、socks4a、socks5。
而http下面又分为http、https、spdy。我想将来应该还会有quic和http/2.0。
解析代理服务器协议配置的函数在 http://src.chromium.org/svn/trunk/src/net/proxy/proxy_server.cc 文件中。
http:// 开头的就是普通的http
https:// 开头的就尝试走https，然后根据握手时得到的扩展信息，来考虑是否用SPDY。
socks://开头的就是socks5
socks4://开头的就是socks4。
socks4和socks4a的主要区别在于socks4不支持远程域名解析(remote resolver)。这是一个非常重要的功能，比如在中国，DNS应答是会被干扰、伪造的。但是chrome并没有明确的表明支持socks4a协议，并且，对于所有的socks协议，都不支持任何形式的身份验证。
当使用socks4时，chrome只有在本地DNS解析失败的情况下才会切换至socks4a。这个见socks_client_socket.cc:DoResolveHostComplete()。
关于握手开销：http>socks4>socks5。socks4建立新连接的时候，需要1个round trip的握手工作。相比而下，socks5建立新连接的时候，需要2个round trip的握手工作。http需要一个round trip，因为chrome不会主动记住哪个http proxy server需要身份验证。它会首先发一个普通的http proxy请求过去，不带auth信息，等server返回407之后，再发送带Proxy-Authorization header的请求过去。但是如果http代理服务器支持”Proxy-Connection:keep-alive”则chrome可以重用现有的连接，握手开销被平摊而降的很低。现在比较新的chrome版本中，似乎是每开启一次chrome浏览器，只会收到一次407。后续新建的连接会记住发Proxy-Authorization header。但是chrome底层的很多请求(比如app、updater)依然不懂得发Proxy-Authorization header，导致用不了带身份验证的http proxy。SPDY proxy的连接一般来说是一直保持的。
很多人在请求google给chrome加上socks5的身份验证功能。但是现在没人理
https://code.google.com/p/chromium/issues/detail?id=256785
chrome还有一个比较气愤的事情是：它有一个DNS prefetcher。默认会开启。如果你配置了proxy server，它依然会贱贱的总是尝试走本地DNS解析域名，从而导致隐私泄露问题。貌似因为涉及的部件比较多，google尽管知道这个问题，但是一直没有完全解决它。