On Fri, Mar 18, 2016 at 03:04:43PM +0100, Dennis Jacobfeuerborn wrote: > > You don't need, just use the proxy protocol : > > > > listen secure > > bind :443 ssl crt foo.pem process 2-32 > > mode tcp > > server clear 127.0.0.1:81 send-proxy-v2 > > > > frontend clear > > bind 127.0.0.1:81 accept-proxy process 1 > > bind :80 process 1 > > mode http > > use_backend my_wonderful_server_farm > > > > Also, if you have one backend with all frontends bound to many processes, > > then all your backends run on these processes, which makes it harder to > > enforce maxconn limitations or to share stick-tables. That's why it's > > much better to only move SSL out of the regular path. Of course if you > > need to pass extra info, you'll have to enable HTTP in the frontend. > > Doesn't this setup use a lot of additional sockets for the > send/accept-proxy communication?
It only doubles the total number of sockets on the system, but the main process still has the same number. In fact, even slightly less since its client is very close and consumes data much faster. > I'm using abstract namespace sockets to handle this kind of forwarding: > > listen secure > bind :443 ssl crt foo.pem process 2-32 > mode tcp > server clear abns@fclear send-proxy-v2 > > frontend clear > bind abns@fclear accept-proxy process 1 > bind :80 process 1 > mode http > use_backend my_wonderful_server_farm > > Is there any downside to use abstract namespace sockets like this? In general it's even better than TCP and significantly faster. The only case I'm aware of where abstract sockets could be problematic is when multiple processes are bound to them, because they are not resumable. Upon a soft reload, if the new process fails to bind and tells the old ones "ok I changed my mind, continue what you were doing", only one of the old ones will be able to rebind. In the case above there's a single listener so that's fine. Willy
