A Primer on Proxies

Re:A Primer on Proxies by ThePhysicist on Monday March 21, 2022 @08:13AM (#30753140)

In my experience HTTP/2 doesn't boost proxy performance significantly, at least for HTTPs workloads. Normally the client sends a single CONNECT [hostname] request to the proxy and after that the proxy just forwards TCP packets on that connection, which is nothing that HTTP/2 can improve. A client can of course use the same HTTP/2 connection for multiple CONNECT requests, but opening several data streams to the proxy in parallel isn't much more costly as those streams tend to be long-lived and will often carry multiplexed HTTP/2 connections themselves, so further multiplexing on the proxy level often has little effect (in my experience at least).

Regarding QUIC/MASQUE it's still difficult to find any clients that support it. I think Chrome supports using QUIC to connect to a regular HTTP CONNECT proxy, but I don't know of any browsers that have even experimental support for MASQUE as of now. Will be pretty great tough I think once it's supported more widely.

[ Parent | on HN ]

Re:A Primer on Proxies by Liuser on Monday March 21, 2022 @03:57PM (#30758933)

> Normally the client sends a single CONNECT [hostname] request to the proxy and after that the proxy just forwards TCP packets on that connection, which is nothing that HTTP/2 can improve.

Trying to test my understanding - Does the CONNECT HTTP protocol need to match the underlying payload protocol. Eg After CONNECT over HTTP/1.1 tunnel is established it’s still possible for the client to still use HTTP/2 with the upstream server for its underlying payloads correct?

My intuition is that it doesn’t need to match because the proxy has no way to know what http protocol is being used when the workload is encrypted.

[ Parent | on HN ]

Re:A Primer on Proxies by simmervigor on Monday March 21, 2022 @05:42PM (#30760083)

The vanilla CONNECT method is an instruction to open a TCP connection to the target server. What is sent over that is entirely up to client and target the server it doesn't need to match. Its often TLS carrying HTTP but it could be anything.

The proxy could inspect the traffic it is carrying and try to enforce some access control or policy. However, the use of TLS or other encrypted protocols limits the ability to do see what is happening. Then you get into a different logical layer of whether there is MITM happening, but that is tangential to conventional use case for HTTP proxy.

[ Parent | on HN ]