TCP Proxy Connection Pool

[Ben Gray]

Hey,

I have a tcp based service that requires multiple steps in the handshake and a 'serverless' app that makes requests to it, being that that is a someone heavy operation I have been attempting to alter a filter to maintain a pool of connections so the relatively cheap request/response from the app can be done without having to rebuild the connection each time. The handshake steps for this app are always the same so reuse of the connection isn't an issue from that point of view.

The TCP Proxy filter appears to use a connection pool to manage upstream connections but I don't really understand how a connection can be handed back to the pool when the downstream no longer needs it as it look to terminate when the downstream is also terminated. Can someone point me at an example of how to use connection pools in the TCP Proxy filter, or suggest an alternative way to do the connection pooling if I've just misunderstood how this is working.

Kind regards,

Ben

[Yuchen Dai]

A tcp-ish stream cannot be reused.

However, a tcp conn pool has alternative values

• The upstream tcp connections can be preallocated

There is also a slight chance that an upstream connection is created but downstream tcp proxy decides to close the downstream connection. 

• The upstream stream can be carried by http CONNECT request

When you choose http2 connect or h3 connect, even though the above preallocate is not enabled, you may gain some benefits.

Our use cases enforce expensive TLS handshake. Under this constraint, creating a new http2 connect stream is greatly cheaper than establishing a TLS connection.

-Yuchen

--
You received this message because you are subscribed to the Google Groups "envoy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-dev/2028d80b-8560-44dc-97e3-3d3a2686b678n%40googlegroups.com.

[Zizon Qiu]

The understanding is correct, the reason behind should be that, 

it is not always safe to reuse an aborted connection since  the TCP did not know anything about the application protocol.

It is possible to use the TCPPool to write a specialized filter to handle such connection reuse if one can maintain the right clean connection state.

[Ben Gray]

Looks like with a custom version of the tcp pool I should be able to tell the connections to not be shutdown, and a custom filter means I can handshake on new connections only. Haven;t got that working yet but looks doable.

Thanks for the pointers, hopefully I'm on the right path now.