DNS resolution for websocket connection ignores IPv6 prefix precedencene
Reported by
jas...@clearcanvas.ca,
May 10 2017
|
|||
Issue descriptionChrome Version : 60.0.3095.0 (Official Build) canary (64-bit) (cohort: 64-Bit) OS Version : Windows Server 2012 R2 URLs (if applicable) : N/A Other browsers tested: Safari: N/A Firefox: OK IE 11: OK What steps will reproduce the problem? 1. Have a dual stack IPv4/IPv6 Windows environment, with IPv4 configured to have precedence over IPv6 2. Open a page that loads XHR resources and opens websocket connections from the same server hostname (that has both IPv4 and IPv6 entries) 3. Check server logs to see the origin IP of the requests What is the expected result? Both XHR and websocket requests originate from same IP (should be IPv4, since that has precedence) What happens instead of that? XHR request originates from an IPv4 address, websocket upgrade request originates from IPv6. Please provide any additional information below. Attach a screenshot if possible. We have a stateful server that is accessed via both XHR and websockets. On one particular server with IPv4 precedence, the XHR request is served over v4, but a websocket connection opened from the same page uses v6. We would argue that, since IPv4 has precedence, both requests should be using v4. At the very least, they should be consistently resolved. We created a simple nodejs server to demonstrate the problem. It hosts a simple HTTP server that responds to both XHR and websocket upgrade requests, and responds with a JSON payload containing the origin IP of the incoming request. Attached screenshot and network log are from this nodejs sample, and show that Chrome is making the websocket request over IPv6 instead of IPv4. IE11 is shown performing as expected. Note that, in the example, the hostname of the server is the IPv4 with dashes instead of periods. Possibly related to 516305, but that one suggests that prefix precendence is not applied at all, whereas it appears to be functioning for non-websockets here.
,
May 11 2017
,
May 11 2017
Haven't reproduced but based on code reading, marking as triaged. ricea@ implemented the Happy Eyeball algorithm along with WebSocket throttling implementation in https://codereview.chromium.org/240873003. It attempts to use v6 addresses first and then fallback to v4 which is different from one in transport_client_socket_pool.cc and the example in RFC 6555 which tries the first entry in the resolution result list and then fallback to ones with different family than the first one. So, even when v4 precedes WebSocket tries v6 ones first. Assigning to ricea@ for further analysis.
,
May 19 2017
I'm confused, because as far as I know both HTTP and WebSocket race IPv6 and IPv4 in a way that prefers IPv6. They have distinct implementations but the timing is identical. What I've seen happen before is that HTTP and WebSocket end up making different choices because the algorithm is timing-sensitive and so non-deterministic.
,
May 19 2017
I mentioned this on the net-dev thread, but posting here as well: for HTTP(S) requests, happy eyeballs is only used if the first address in the list is IPv6. If getaddrinfo returns a list with an IPv4 address first, that address will be tried first with no IPv6 race, even if there are IPv6 addresses later in the list.
,
May 22 2017
#5 Thank you. I wonder if this means metrics get logged as IPV4_SOLO when they ended up connecting to IPv6? Do you think I should change the WebSocket behaviour to match the HTTP behaviour?
,
Jun 12 2017
I have found out the command needed to reproduce this on Windows: netsh interface ipv6 set prefixpolicy ::/0 3 6 I have confirmed that with this setting HTTP prefers IPv4 and WebSocket prefers IPv6. I have also confirmed that HTTP records cases where both IPv4 and IPv6 addresses are available under the "Net.TCP_Connection_Latency_IPv4_No_Race" UMA histogram. WebSocket connect jobs also use the same histograms, but I really don't want to log things as IPv4_No_Race when there was an IPv6 address present. Or maybe that's okay? After all, the result was an IPv4 address, and no connection race was done. The fix should be trivial, but I'm blocked on the UMA issue. |
|||
►
Sign in to add a comment |
|||
Comment 1 by kkaluri@chromium.org
, May 11 2017Labels: TE-NeedsTriageHelp