-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: a "bad" connection could potentially block all https requests #28824
Comments
I make a mistake, my local go version is go1.10.1, which the problem really exists, but it's not the latest code (sorry for that), and the latest code seems fixed the problem. |
The latest code (e8a95ae) maybe have the same problem,
|
Can you tell us the production Go version that you are running where the problem is actually occuring ? |
The production Go version is go1.10.1, and I reproduce the problem with go1.11.2.
Run the code, and shutdown 172.28.128.3 server by pulling power at "2018-11-16 18:17:01",
|
I am running your test against a local http2 server which I then killed. |
Killing local http2 server is different with pulling power (the "shutdown" in previous comment is pulling power exactly). Killing local http2 server,: Pulling power: |
There have been two changes at tip that I think should fix this. Could you try Go 1.12beta1 when it comes out later today? The two changes:
|
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
In out production environment, we found all the outgoing https requests with different destination address happened to blocked at the same time and last for about 14 miniutes, while the http requests were not.
So I check the net/http source code (https://github.com/golang/go/blob/ac7c0ee26dda18076d5f6c151d8f920b43340ae3/src/net/http/h2_bundle.go), and found the "block logic", as show below.
A https request goes through a few stages, step1 get connection, step2 write headers, ...
step1, get connection
step1-1 call http2clientConnPool.GetClientConn to get a valid connection
step1-2 acquire http2clientConnPool.mu, line 738
step1-3 call http2ClientConn.CanTakeNewRequest, line 740, and http2ClientConn.mu is acquired, line 7175
step2, write headers
step2-1 acquire http2ClientConn.mu, line 7335
step2-2 call http2ClientConn.writeHeaders to write request headers
step2-3 http2ClientConn.writeHeaders call bw.Flush which could potentially block
step2-4 release http2ClientConn.mu, line 7384
If a request write headers but block in step2-3,
the next request with the same addr will be blocked in step1-3,
and from now on all the following requests (even with different destination address) will be blocked in step1-2 until the blocked step2-3 writeHeaders returned.
I check the sysctl configuration, the total retransmission timeout is just about 14minutes(with TCP_RTO_MAX = 120):
The text was updated successfully, but these errors were encountered: