chrome对代理服务器的支持情况

今天我调查了一下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 文件中。

对于URL格式的代理设置,如 --proxy-server=https://www.google.com:443

  • http:// 开头的就是普通的http
  • https:// 开头的就尝试走https,然后根据握手时得到的扩展信息,来考虑是否用SPDY。
  • socks:// 或socks5:// 开头的就是socks5
  • socks4://开头的就是socks4。
  • quic:// 开头的是quic。

(见GetSchemeFromURIInternal函数)

socks4和socks4a的主要区别在于socks4不支持远程域名解析(remote resolver)。这是一个非常重要的功能,比如在中国,DNS应答是会被干扰和伪造的。但是chrome并没有明确的表明支持socks4a协议,并且,chrome对于所有的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尽管知道这个问题,但是一直没有完全解决它。

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥