HAProxy tcp multiplex - tcp

help me please. I'm new and have little experience. There is a task, a permanent TCP connection to the LDAP server. There are several options. Nginx, HAProxy, ssh multiplexing. I settled on HAProxyn. But I can't figure out if it can observe a TCP-enabled connection. This is necessary so that each new request does not open a new connection to the server, and use the existing one. Can you suggest what I can use for this?
On each new request - HAProxy open new connection. But I need that all requests go through one TCP connections

Related

Delete hostname HTTP client DNS cache and close connections to specific IP

I'm using the net/http library to make HTTP requests.
I have a use case where sometimes I resolve a domain name that fronts an Amazon CloudFront distribution. Occasionally for reasons of its own, CloudFront will resolve the DNS to a point of presence (POP) on a different continent, resulting in very high latencies.
When this happens, I want to cause a "targeted reset" making my http.Client "forget" about that POP, basically closing open TCP connections and forcing the DNS for that hostname to be re-resolved.
I'm not able to find a way to force this "targeted reset". My options seem to be:
Close all idle connections in the http.Transport using Transport.CloseIdleConnections(), but this will close all TCP connections and it won't do anything about cached DNS results.
Construct a whole new http.Client. I've confirmed this does result in re-doing the DNS lookup and it does also create a new connection pool. The downside is it forces re-resolution of all other DNS and force-closes all other TCP connections, even ones I like.
Is there a way to achieve the "targeted reset" (DNS for specific hostnames, TCP connections for specific IP addresses) I've described? I'm happy to use reflection and traverse down into the http.Client implementation to some extent.

Transparent HTTP tunnel to TCP

I want to open any arbitrary TCP socket on a server, but it's behind a proxy and I can only use a port that is intended for HTTP hosting only. Simply put, what is the most transparent way to wrap such a socket into an HTTP connection? Preferably I would call a *nix program through a shell script in the server that would take care of translating the requests.
I apologize if this was answered before, but I am struggling to find and understand anything.
I ended up going with Chisel, which provides a single binary for both servers and clients, with features like authentication and reverse port forwarding. For instance:
chisel server
will run an HTTP server in $PORT or 8080, and
chisel client server.com 4567:123
connects to server.com and maps the remote port 123 into the local port 4567.
Other solutions are still welcome, particularly if they involve more transparency, frequently preinstalled tools like netcat, and if they also provide support for other protocols like UDP.

Telling a TCP client to seamlessly switch to new server

Does TCP have something in place for telling a client "continue this same conversation but at a different address"?
There is no way to do that with TCP. You would have to make the client close its current connection and open a new connection. Or else you would need a proxy that can manage multiple connections on its side and switch between them as needed, then have the client connect to the proxy.

Http requests and TCP connections

My understanding so far is that when someone tries to access web page the following happens:
HTTP request is formed
New socket is opened
HTTP request is sent
If everything went OK, the web browser accepts HTTP response and builds DOM tree out of received HTML. If there are any resources missing, new HTTP request needs to be made for each one separately.
Each of those HTTP requests requires opening another socket (establishing new virtual connection with server).
Q: How is that efficient? I understand those resources could be located on another host (which would indeed require new TCP connection) but if they are all on the same host wouldn't it be way more efficient to transfer all data within single TCP connection.
Each of those HTTP requests requires opening another socket (establishing new virtual connection with server).
No it doesn't. HTTP 1.1 uses persistent connections by default, and HTTP 1.0 before it had the unofficial Connection: keep-alive header, which accomplished the same thing, nearly twenty years ago.
Q: How is that efficient?
It isn't, and that's why it doesn't happen.
I understand those resources could be located on another host (which would indeed require new TCP connection) but if they are all on the same host wouldn't it be way more efficient to transfer all data within single TCP connection.
Yes, and that is what happens by default.

nginx stream mode reconnect to upstream without close downstream connection

Hi,I am using nginx stream mode to proxy tcp connection. Could this be possible if I restart my app on the upstream, nginx could auto reconnect to upstream without lost the tcp connection on the downstream?
I found some clue from this HiveMQ blog post comment, hope this help. I copied them as below:
Hi Sourav,
the load balancer doesn’t have any knowledge of MQTT; at least I don’t
know any MQTT-aware load balancer.
HiveMQ replicates its state automatically in the cluster. If a cluster
node goes down and the client reconnects (and is assigned to another
broker instance by the LB), it can resume its complete session. The
client does not need to resubscribe.
Hope this helps, Dominik from the HiveMQ Team

Resources