(请原谅我为了突出「最快」而结巴了)
Chrome支持http，https和socks三种代理。其中http和socks是传统项目，https则是在2014-2015之间某个时间点上加入的。
如果同一台代理服务器，上面架设了这三种方式的代理，哪一种实际用起来最快呢？
啊我就废话少说了。目前Chrome (v50)实际使用这三种代理的方式是：
http代理：对每一个HTTP请求，都发起一个HTTP (over TCP)连接到代理服务器。如果代理服务器支持HTTP 1.1，应该会在上一个请求完成后自动重用连接。与代理服务器建立连接的上限是32。socks代理：因为socks代理本身支持多路复用的特性，Chrome实际上会在单个socks (over TCP)连接里承载多个HTTP请求。与代理服务器建立连接的上限也是32，但实际最多只会与代理服务器建立并维持两个socks (TCP)连接。https代理：现有的https代理实现，例如node-spdyproxy或nghttp2，本身就实现了基于SPDY/3或HTTP/2的多路复用，因此Chrome实际上也像使用socks代理一样，最多只维持两个SSL (TCP)连接。socks/SPDY/HTTP2的多路复用本质上和HTTP 1.1想要解决的问题是一样的：省掉重复建立TCP连接的开销。只是Google在做SPDY时还额外考虑了资源优先级等等之类的问题。理论上来讲多路复用的数据链路利用效率更高。有不少HTTP vs. SPDY的加载性能对比也是一目了然的。从我个人的体验来讲，确实使用socks或https代理时，有大量小文件的页面的加载速度明显更快。
补充一句，另外在使用普通HTTP代理时，如果远端服务器支持SPDY或HTTP2，Chrome仍然会通过CONNECT建立的隧道复用连接，但这和HTTP代理无关。
但这些复用说穿了还是在同一个TCP连接里。一旦这个连接数据传输发生stall的情况，里面承载的所有数据流都会统统block。另一方面是数据传输的QoS其实没法搞。比如我用socks/https代理下载大文件时，再打开其他的网页就会非常之慢。所以Google后来再接再厉，搞出了基于UDP的QUIC协议。
因为Chrome最多只使用两个TCP连接，这种block的情形就会经常出现。个人认为这多少算是Chrome的bug。如题图/下图所示:
:3187上的是一个Squid3 HTTP代理，:8443是个nghttp2 https代理。虽然Idle的连接数一个是16一个是15，但Chrome实际上只与https代理服务器建立了两个SSL连接。可见对socks/https代理，Chrome在统计连接数时是考虑的在多路复用的前提下建立的逻辑连接数。这使得与同一个代理服务器最大32个连接的限制形同虚设。所以到底哪种更快？你自己决定吧...
更新：从Chrome 51开始，https代理的实际连接数已经和http一样可以开到多达32个。socks代理仍然是两个。