Thanks, we may use this for a very rough proof-of-concept. However we
are dealing with millions of concurrent connections, 10-100 million
connections per day, so we'd prefer to pay someone to develop (+ test!)
something for haproxy which will work at this scale
Mark
On 20/05/2022 10:12, Илья Шипицин wrote:
in theory, you can try OpenVPN with compression enabled.
or maybe stunnel with compression stunnel TLS Proxy
<https://www.stunnel.org/static/stunnel.html>
пт, 20 мая 2022 г. в 13:59, Mark Zealey <mark.zea...@moya.app>:
Good point, I forgot to mention that bit. We will be
TLS-terminating the connection on haproxy itself so
compress/decompress would happen after the plain stream has been
received, prior to being forwarded (in plain, or re-encrypted with
TLS) to the backends.
So:
app generates gzip+tls TCP stream -> haproxy: strip TLS, gunzip ->
forward TCP to backend servers
We don't have any other implementation of this, at the moment it
is just an idea we would like to implement.
Mark
On 20/05/2022 09:54, Илья Шипицин wrote:
isn't it SSL encapsulated ? how is compression is supposed to
work in details ?
any other implementation to look at ?
чт, 19 мая 2022 г. в 21:32, Mark Zealey <mark.zea...@moya.app>:
Hi there,
We are using HAProxy to terminate and balance TCP streams
(XMPP) between
our apps and our service infrastructure. We are currently running
XMPP-level gzip compression but I'm interested in potentially
shifting
this to the haproxy layer - basically everything on the
connection would
be compressed with gzip, brotli or similar.
If you would be interested in doing paid development on
haproxy for
this, please
drop me a line with some details about roughly how much it
would cost
and how
long it would take. Any development work done for this would be
contributed back to the open source haproxy edition.
Thanks,
Mark
