-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
measure and decrease delay #2
Comments
another possibility is to always keep a TCP connecion to each backend open to be used for the next client (but this may due to mutable state actually be harder to write cleanly). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
with #1 (and the monitoring branch which contains further fixes), this can be used as a reverse TLS proxy. the flow being that a client connects (TCP) to tlstunnel, which does the TLS handshake, and once established a TCP connection to the backend is established (and data being passed from the client to the backend).
when measuring delay (since the client has to wait for the TCP connection being established), what about opportunistically starting the TCP session once the TLS client hello is received? we do not (yet) have control / event thereof in the TLS stack, but it may be worth a try.
The text was updated successfully, but these errors were encountered: