On Mon, Sep 03, 2012 at 11:21:51PM -0700, Justin Karneges wrote:
> On Tuesday, September 04, 2012 01:37:17 AM Willy Tarreau wrote:
> > After several months of efforts by the Exceliance team, we managed to
> > rework all the buffer and connection layers in order to get SSL working
> > on both sides of HAProxy.
>
> Very cool.
>
> Since HAProxy is event-driven, is anything done to avoid expensive crypto
> operations from blocking the event loop? Maybe that is what you intend for
> "remote sockets" ?
Exactly !
That said, as I've always said, the problem is not the relative cost of
crypto but the computation time. On small devices, if an operation can
take 10ms, it clearly is a problem. However on larger devices, if no
operation takes more than 100 microseconds, then the added latency is
minimal compared to system latency. That does not mean it's not a problem,
just that when you're at 100% CPU, you might still have enough scheduling
capacity to process the rest of the traffic without too much impact.
But clearly when we can offload SSL to other processes, that will be much
better. This can already be done BTW, but you have to chain proxies. For
instance :
global
nbproc 4
listen front
bind-process 1,2
bind :443 ssl haproxy.pem
server http 127.0.0.1:8888 send-proxy
listen http
bind-process 3
bind 127.0.0.1:8888 accept-proxy
mode http
server back 127.0.0.1:8443 send-proxy
listen back
bind-process 4
bind 127.0.0.1:8443 accept-proxy
server out 192.168.0.1:443 ssl
You see, https is accepted on processes 1 and 2, which decipher the
traffic and pass it to process 3, preserving IP information. This
process does the HTTP handling and passes the traffic to process 4
which will re-cipher it before going to the server.
Admittedly this is ugly and that's why we'd like to implement the
remote sockets soon, so that you can write something like this :
listen http
bind-process 3
bind :443 ssl haproxy.pem process 1,2
mode http
server out 192.168.0.1:443 ssl process 4
Also, using socketpair() internally will be much faster and have a lower
overhead than TCP connect/accept.
Regards,
Willy
