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.
> 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.
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.
> What if we wanted to proxy QUIC? What if we wanted to proxy entire IP datagrams, similar to VPN technologies like IPsec or WireGuard? This is where MASQUE comes in.
I will do once I've figured out what is actually going on. Maybe it's as banal as a rule to always allow traffic to a specific IP that's added by some macOS component to PF.
I really don't want to get sidetracked into a political or philosophical conversation. But to me, a policy of content neutrality is tacitly supporting extremist content. Cloudflare has to be dragged kicking and screaming before it stops profiting and protecting extremist sites and sites which host illegal content.
The concentration of internet infrastructure into a few companies is something to be concerned about. But my bigger beef with Cloudflare is that they profit from and protect despicable websites and only cave when public pressure is high enough.
The company sure made a courageous stance protecting a site which advocates explicitly for accelerationist race wars, and another image board that was notorious for housing child abuse imagery and conspiracies which led to real-world deaths.
The answer to where a company should draw the line isn't 'OMG, slippery slope!' It's 'somewhere.' And preferably the CEO of the company shouldn't agonize about getting rid of stuff like the Daily Stormer and 8chan.
> But to me, a policy of content neutrality is tacitly supporting extremist content.
When I read this, I agreed, but as I continued I realized that we come to opposite conclusions. A platform that espouses neutrality and fairness _should_ support extremist content, but it should be the reader's job to determine if the content is despicable.
Intermediaries can have different purposes. The official alternative to reverse proxy is "gateway", which is unfortunately overloaded with other kinds of gateways in networking.
Naming things is hard. Reverse proxy isn't great but all things considered is unique enough to allow folks to discriminate the sort of HTTP proxying that is happening
> What is the difference between a reverse proxy and a load balancer?
Reverse proxy may or may not loadbalance requests. For example, in a sidecar configuration it can just terminate tls, provide telemetry, etc and forward everything to local port.
A [load-balancing] reverse proxy can also keep WAF rules in RAM for processing requests and responses.
WAF: Web Application Firewall (OWASP CRS ruleset, CF ruleset,)
Methods for delegating HTTP requests to another application, with per-message overhead and inevitably-necessarily-tunable buffering: Layer 2 (MAC on a local segment), Layer 3 (IP), Layer 4 (TCP, UDP ports), Layer 7: HTTP parse and forward over network sockets or file sockets, defy separation of concerns and least privileges and run the (e.g. non-blocking Lua,) app within the webserver, Layer 7+: container service mesh Ingress API,
e.g. FastCGI uses file sockets, which avoids additional TCP overhead but doesn't really scale because sockets and network filesystems.
(ASGI is the Asynchronous WSGI, which specifies $ENVIRONMENT_VARIABLE names as an interface contract in order to decouple web [[reverse] proxy] servers from web applications.)
Fundamentally, which variables passed in the e.g. os.environ dict like $REMOTE_USER and IDK is it like $SSL_CLIENT_CERT_SHA384, SSL_CLIENT_CERT_*; should downstream web applications simply trust as valid strings over what network path?
TLS re-termination.
Non-root [web] servers must run on ports less than 1024, which e.g. iptables or nftables (or eBPF) can easily port-forward to only if rewriting URLs within potentially-signed assets within HTTP messages and HTTP/3 UDP streams isn't necessary.
It would be nice if there was a way to more easily debug caching issues with CF workers being used as proxies. There is very little visibility into how headers affect things and it is poking in the dark to make it all work.
I haven't paid much attention to this stuff, but recently I discovered a trick for slowly migrating the web services on an old server to a new one: via reverse proxy definitions on the new server that pass through selective paths to the old one. To the outside, it looks like one server. The new server has the SSL identity with up-to-date crypto and all and terminates the HTTPS connections. As I'm doing this, suddenly it hits me: oh so this is Cloudfare in a mini nutshell?
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.