i am load balancing against 2 squid instances, and have gone down the path of using mode tcp, with proxy protocol, and found that i prefer mode http with http-reuse and x-forwarded-for.
with tcp and proxy protocol, every connection is sent with the clients ip, so any ip based acls or rules are affected by the decision. with http and http-reuse, you use x-forwarded-for, and have collapsed tcp sessions, resulting in better performance and still have the clients ip for acls, etc. as your environment grows, the overhead of huge numbers of tcp connections becomes a factor, and the performance implications grow at a commensurate rate. the instant improvement seen with http-reuse persuaded me to leverage x-f-f, instead of proxy protocol. in other instances like mariadb, or imap, where you expect a single connection to be assoicated with a single ip, i do use proxy-protocol. ymmv On 1/12/22 8:57 PM, Aleksandar Lazic wrote: > > On 12.01.22 21:52, Andrew Anderson wrote: >> >> On Wed, Jan 12, 2022 at 11:58 AM Aleksandar Lazic <[email protected] >> <mailto:[email protected]>> wrote: >> >> Well, looks like you want a forward proxy like squid not a >> reverse proxy like haproxy. >> >> >> The application being load balanced is a proxy, so http_proxy is not >> a good fit (and as you mention on the deprecation list), but haproxy >> as a load balancer is a much better at front-ending this environment >> than any other solution available. >> >> We upgraded to 2.4 recently, and a Java application that uses these >> proxy servers is what exposed this issue for us. Even if we were to >> use squid, we would still run into this, as I would want to ensure >> that squid was highly available for the environment, and we would hit >> the same code path when going through haproxy to connect to squid. >> >> The only option currently available in 2.4 that I am aware of is to >> setup internal-only frontend/backend paths >> with accept-invalid-http-request configured on those paths >> exclusively for Java clients to use. This is effectively how we have >> worked around this for now: >> >> listen proxy >> bind :8080 >> mode http >> option httplog >> server proxy1 192.0.2.1:8080 >> server proxy2 192.0.2.2:8080 >> >> listen proxy-internal >> bind :8081 >> mode http >> option httplog >> option accept-invalid-http-request >> server proxy1 192.0.2.1:8080 track proxy/proxy1 >> server proxy2 192.0.2.2:8080 track proxy/proxy2 >> >> This is a viable workaround for us in the short term, but this would >> not be a solution that would work for everyone. If the uri parser >> patches I found in the 2.5/2.6 branches are the right ones to make >> haproxy more permissive on matching the authority with the host in >> CONNECT requests, that will remove the need for the parallel >> frontend/backends without validation enabled. I hope to be able to >> have time to test a 2.4 build with those patches included over the >> next few days. > > By design is HAProxy a reverse proxy to a origin server not to a > forwarding proxy which is the reason why the > CONNECT method is a invalid method. > > Because of that fact I would not use "mode http" for the squid > backend/servers because of the issues you > described. > Why not "mode tcp" with proxy protocol > http://www.squid-cache.org/Doc/config/proxy_protocol_access/ if you > need the client ip. > > > Regards > Alex
