今天我调查了一下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尽管知道这个问题，但是一直没有完全解决它。

建议继续学习：

1. Chrome和goagent的配置方法，你懂的    (阅读：15491)
2. 让安卓手机通过代理翻墙的方法    (阅读：7156)
3. 关于 SOCKS 代理的远端 DNS 解析    (阅读：6417)
4. 警惕 Chrome 的查看源代码 (View Page Source) 功能    (阅读：5841)
5. webapp网页调试工具Chrome Devtools    (阅读：5293)
6. 通过使用Chrome的开发者工具来学习JavaScript    (阅读：5043)
7. [译]Google Chrome中的高性能网络    (阅读：5125)
8. chrome扩展应用开发教程之开发chrome应用基础    (阅读：4689)
9. 如何制作chrome扩展程序    (阅读：4598)
10. 代理的加密部分    (阅读：4512)