Traffic compression

[slava-re]

Feature Description

Good day to you!

We're seeing internet speed cap being a bottleneck on some of the dump operations we perform. Since compressed dumps can be less than ten times what the uncompressed dump is, I thought, it could be an interesting enhancement to add compression to the proxied traffic.

I understand that this would also involve the proxy software on the other end, so not sure if this is the right repo to submit a feature request like this, and it's high effort/low prio, but still submitting this just in case.

Sample code

No response

Alternatives Considered

Postgres had compression implemented in their SSL transport, but it got retired mainly because the underlying SSL library has an insecure implementation.

Additional Details

No response

[enocom]

This is an interesting idea. Would this be for the Postgres protocol or for the raw bytes going back and forth?

[jackwotherspoon]

This is an interesting idea. Would this be for the Postgres protocol or for the raw bytes going back and forth?

@slava-re just wanted to follow-up on the above question ^

[slava-re]

Sorry that I missed the question first time!

I think, by default Postgres doesn't encrypt the connection traffic (if it did, compressing encrypted stream would be useless), so this could be compression just at a proxy level, regardless of a protocol or the type of database. That's why adding it to Cloud SQL Proxy would be viable and beneficial to all DB types potentially.

[enocom]

More from the Postgres docs linked above. This is apparently an OpenSSL feature.

SSL compression is nowadays considered insecure and its use is no longer recommended. OpenSSL 1.1.0 disables compression by default, and many operating system distributions disable it in prior versions as well, so setting this parameter to on will not have any effect if the server does not accept compression. PostgreSQL 14 disables compression completely in the backend.

Looking at Go's TLS implementation, I don't see any mention of compression (other than here). If we were to pursue compression, it would be using the Go TLS implementation of it. So unless I've missed something in the API, I think this is presently infeasible.

[slava-re]

Yeah, I've had in mind some kind of custom compression layer before the data is handed off to the encryption layer, which would require support on the other end (which Google technically would have ability to implement). But I totally see that this is not an easy thing to do a custom implementation of!