Hi, On Fri, Aug 07, 2015 at 12:02:52AM +0200, Thomas Heil wrote: > Hey, > > On 06.08.2015 23:50, Aleksandar Lazic wrote: > > Hi all. > > > > That's cool ;-) > > > > https://www.varnish-cache.org/docs/trunk/whats-new/changes.html#proxy-protocol-support > > That are good news.
Yes I saw it already and that's a great news. > Iam sad that there is still no support that varnish > can also use the proxy protocol as a client. This way proxy chains could > benefit and the x-forwarded-for hell comes to an end. XFF is still needed when you don't have a 1-to-1 relation between front and back connections. And there's a good reason for this. Yesterday I could finally implement basic server connection sharing. This means that now when you balance on uri to a cache farm, you will be able to reuse established connections to the caches. This brings a significant performance boost for small objects. In my tests, the performance climbs from 80k conn/s to 195k req/s, and the perf scales better with processes since we save the connect() and close() dance which uses locks and doesn't scale. This is not possible with the proxy protocol of course since there are multiple source addresses for requests that go over one connection. Please keep in mind that the proxy protocol was designed for "dumb" proxies, working at the TCP level only. It's quite useful for varnish when haproxy is used in front of it as an SSL offloader. But as soon as you use HTTP-aware proxies, better use the HTTP-specific stuff. > A proxy chain could look like this client => haproxy => varnish => > haproxy => backend with the ability to to avoid caching this results to > haproxy =>backend Yes that's exactly it. > Imagine that varnish could also substitute with nginx (naxsi), apache > (mod_security). All these components are HTTP-compatible and it's better to use XFF than the proxy protocol there. Cheers, Willy
