[Inquiry] [HttpClient] Connection reuse for different hostnames that resolves to same IP

[hongrui-zhang]

Description

Our service needs to send HTTP requests to a lot of (e.g. 70k) different host names. What's special about those hostnames is that they resolve to only
roughly 60 IPs, i.e., a lot of the different host names resolve to the same IPs.

If we use a plain HttpClient and send requests with host names in URL, it will open a connection for each host name (if I read source code correctly), resulting in 70k outgoing connections and therefore high SNAT usage.

Is there any way to reduce outgoing connections count in this scenario? For example, is there any way to instruct the client to reuse a connection for requests to the same IP (as usual, new connections should be made when it cannot keep up with request volume)?

We are on .Net Core 8

One idea that we come up with is our code can keep a dictionary from IPAddress to HttpClient. Our code will resolve DNS ourselves and get the HttpClient from the dictionary (create new one if it does not exist). Then, when sending the request, we use IP instead of host name in the URL, so that HttpClient would not open a new connection each time (since all requests sent on this HttpClient has the same IP as hostname). One challenge is that we need to override SSL cert validation maybe through ServerCertificateCustomValidationCallback (since the remote cert does not have IP as subject name), which sounds quite dangerous.

[ManickaP]

So you're connecting to same endpoint, but you're getting different certificates in the TLS handshake? I'm assuming you're setting up Host header and the cert is based on SNI, right?
So you'd have:

1. request A connecting to aaa.com on 123.0.0.1 IP
2. connection to 123.0.0.1 with TLS cert for aaa.com
3. request B to bbb.com on 123.0.0.1 IP
4. re-using connection with cert for aaa.com???

If the second request was just smidge faster you'd set up a connection with a different cert and re-use it for request A.

Is this what you want? If so, than yes you have to override the cert validation callback and do your best to not tot open yourself to MITM.

cc @wfurt @rzikm

[hongrui-zhang]

For us it’s like below

1. request A connecting to aaa.common-suffix.com on 123.0.0.1 IP
2. connection to 123.0.0.1 with TLS cert for *.common-suffix.com
3. request B to bbb.common-suffix.com on 123.0.0.1 IP
4. Ideally, we want the client to reuse the connection opened above, but from reading source code it looks like HttpClient will deterministically open a new connection since it’s a new host name.

[ManickaP]

Ideally, we want the client to reuse the connection opened above, but from reading source code it looks like HttpClient will deterministically open a new connection since it’s a new host name.

Yep, it will open a new connection and there are no settings to change that. Also note that depending on how you construct the request might still open a new connection despite using IP in URL.

Alternatively you can explore ConnectCallback on SocketsHttpHandler which might suite your need better than a dictionary of clients.

Also, writing cert validation callback for this scenario might not be as daunting is it seems. The callback has an argument with validation result which you can use to see if the only problem is name mismatch and perform your own name matching procedure instead, otherwise return based on that argument.

Lastly, I'd suggest to start experimenting and testing. I can provide some hints here, but without a specific code and error we're just speculating here.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.