-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
net/http: local IP address change caused timeouts for outgoing HTTPS requests #23008
Comments
For completeness, #23427 is the server-side counterpart issue, though it does not have a breakdown of http vs https behavior.
(I wonder if this more of a difference between http/1.1 and http/2 implementations as opposed to a difference between http and https.) |
It sounds like the problem is:
Why is it Go's responsibility to work around this? I would have expected the kernel to make the operations on the socket in step 3 return some kind of error. What is happening instead? Do the writes just get discarded? If it's HTTPS-specific, can someone find out if maybe crypto/tls is not handling an error from the socket correctly? |
The kernel does not detect this quickly: https://stackoverflow.com/a/60366786. I haven't tested it but the default seems to be > 10 minutes. Red Hat say "Too low a setting will result in TCP connections apparently failing during load peaks". This is also difficult to work around in the application layer without effectively disabling connection pooling (with DisableKeepAlives or low IdleConnTimeout), as even if you can detect this, http.Transport only offers you CloseIdleConnections() and there is no way to close the connections that are trying HTTP requests in vain. Another possible workaround that I haven't tested is to
|
Using Go 1.9.2 on linux amd64.
Using the net/http client on a device whose IP address changes while the program is running, we started getting timeouts for HTTPS requests. To troubleshoot, we set up a DHCP server with very short leases and a minimal program that made requests every 10s and were able to reproduce the problem. We used a client with a transport based on http.DefaultTransport and a timeout (you can see it below).
I found I had to set DisableKeepAlives on the transport or set the IdleConnTimeout shorter than the frequency of our requests, or HTTPS requests would fail consistently after the IP address changed.
The following shows one run of the program. It was compiled with Go 1.9.2. The four routines are: HTTP with keep alive, HTTPS with keep alive disabled, HTTPS with keep alive, and HTTPS with the default http.Client (no timeout, keep alive enabled).
After the IP changes at about 4:04:10, you can see both the HTTP and HTTPS with keep alive fail. HTTP recovers (it isn't worth caching?), but HTTPS keeps timing out. As expected, HTTPS with the default client never times out or recovers.
I'll include the code used to generate this output below. But it's not trivial to reproduce because you need a DHCP server with a short lease and configurable static IPs.
In the short-term, we're just going to disable keep alives for our transports; but I'm reporting this because graceful IP renewal handling seems something Go should have.
The text was updated successfully, but these errors were encountered: