关闭从代理服务器到目标服务器的连接，而不是从客户端到代理服务器的连接

Question

Objective: Never close connection between client and SOCKS proxy + reuse it to send multiple HTTPS requests to different targets (example targets: google.com, cloudflare.com) without closing the socket during the switch to different target.

Step 1: So I have client which connects to SOCKS proxy server over TCP connection. That is client socket(and only socket(file descriptor) used in this project). client -> proxy

Step 2: Then after connection is established and verified. Then it does TLS connect to the target server which can be for example google.com (DNS lookup is done before this).

Now we have connection: client -> proxy -> target

Step 3: Then client sends HTTPS request over it and receives response successfully.

Issue appears: After that I want to close connection explicitly between proxy and target so I can send request to another target. For this it is required to close TLS connection and I don't know how to do it without closing connection between client and proxy which is not acceptable.

Possible solutions?:

1: Would sending Connection: close\n\r request to current target close connection only between proxy and target and not close the socket.

2: If I added Connection: close\n\r to headers of every request, would that close the socket and thus it's not valid solution?

Question: (NodeJS) I made custom https Agent which handles Agent-s method -> callback(req, opts) where opts argument is request options from what client sent to target (through proxy). This callback returns tls socket after it's connected, I built tls socket connection outside of the callback and passed it to agent. Is it possible to use this to close connection between proxy and target using req.close() , would this close the socket? Also what is the point of req in Agent's callback, can it be used in this case?

Any help is appreciated.

Answer 1

If you spin up wireshark and look at what is happening through your proxy, you should quickly see that HTTP/S requests are connection oriented, end-to-end (for HTTPS) and also time-boxed. If you stop and think about it, they are necasarily so, to avoid issues such as the confused deputy problem etc.

So the first bit to note is that for HTTPS, the proxy will only see the initial CONNECT request, and then from there on everything is just a TCP stream of TLS bytes. Which means that the proxy won't be able to see the headers (that is, unless your proxy is a MITM that intercepts the TLS handshake, and you haven't mentioned this, so I've assumed not).

The next bit is that the agent/browser will open connections in parallel (typically a half-dozen for a browser) and will also use pipelining and keep-alive to send multiple requests down the same connection.

Then there are connection limits imposed by the browser, and servers. These typically cap the number of requests, and the duration that they are held open, before speculatively closing them. If they didn't, any reasonably busy server would quickly exhaust all their TCP sockets.

So all-in, what you are looking to achieve isn't going to work.

That said, if you are looking to improve performance, the node client has a few things you can enable and tweak:

• Enable TLS session reuse , which will make connections much more efficient to establish.

• Enable keep-alive , which will funnel multiple requests through the same connection.