Chrome supports HTTP, HTTPS, and SOCKS proxies. Where HTTP and SOCKS are traditional projects, HTTPS was added at some point between 2014 and 2015.
If the same proxy server, set up on the three proxy, which is actually the fastest use?
Oh, I’ll cut the crap. The way Chrome (V50) actually uses these three proxies is as follows:
HTTP proxy: Initiates an HTTP (over TCP) connection to the proxy server for each HTTP request. If the proxy server supports HTTP 1.1, the connection should be automatically reused after the last request completes. The upper limit for establishing a connection to a proxy server is 32.
Socks proxy: Because the SOCKS proxy itself supports multiplexing, Chrome actually hosts multiple HTTP requests in a single SOCKS (over TCP) connection. The maximum number of socks (TCP) connections to the proxy server is 32. However, only two SOCKS (TCP) connections can be established and maintained with the proxy server.
HTTPS proxy: Existing HTTPS proxy implementations, such as Node-spdyProxy or NGHTTP2, already implement multiplexing based on SPDY/3 or HTTP/2, so Chrome actually maintains a maximum of two SSL (TCP) connections as well as using socks proxies.
The multiplexing of SOCKS /SPDY/HTTP2 is essentially the same problem HTTP 1.1 is trying to solve: eliminating the overhead of establishing TCP connections repeatedly. It’s just that Google makes SPDY with extra consideration for resource priorities and so on. Theoretically, multiplexing of data links is more efficient. A number of HTTP vs. SPDY load performance comparisons are also obvious. From my own experience, pages with lots of small files load significantly faster when using socks or HTTPS proxies.
As a side note, Chrome will still reuse the connection over CONNECT if the remote server supports SPDY or HTTP2 when using a normal HTTP proxy, but this is independent of the HTTP proxy.
But these multiplexes are still in the same TCP connection. Once the connection is stalled, all data flows are blocked. On the other hand, QoS for data transmission is actually unworkable. For example, when I use socks/ HTTPS proxy to download large files, it is very slow to open other web pages. So Google followed up with a UDP-based QUIC protocol.
Because Chrome only uses a maximum of two TCP connections, this block situation occurs frequently. Personally, I think this is more or less a Chrome bug. As is shown in the picture/below:
:3187 is a Squid3 HTTP proxy, and :8443 is an NGHTTP2 HTTPS proxy. Although Idle has 16 and 15 connections, Chrome actually has only two SSL connections with HTTPS proxies. For socks/ HTTPS proxies, Chrome takes into account the number of logical connections established under the premise of multiplexing. This makes the limit of 32 connections to the same proxy server meaningless.