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
Deno should make simultaneous outgoing requests to IPv4 and IPv6 addresses when both exist #23580
Comments
One other difference I noticed (by enabling debug logging in nginx) is that Chrome sends more headers for a socket connection than Deno does. Deno:
Chrome:
Again, I apologize, I'm not sure whether those are relevant. Still trying to debug here. I will say, if the timing of the debug output from nginx is to be trusted, it really looks like Deno just sits there doing nothing for 70+ seconds before making the connection. Immediately, once we get the first message about the connection in nginx:
the entire web socket upgrade process completes within the 1-second resolution of logs:
|
Found the issue: My host, Chrome's implementation simultaneously tries to open an IPv6 and and IPv4 connection, and continues with whichever responds first. Deno's implementation seems to always try IPv6 first. Only after that times out (75 seconds?) does it fall back to IPv4. So, yes, as far as my server was concerned, Deno was doing nothing for 70+ seconds before connecting. Oddly, Deno's fetch() implementation does the same thing that Chrome does, and tries both IPv6 and 4 simultaneously. It might be good to do the same thing for WebSocket! |
This might be a useful thing for us to do for all outgoing connections, but it's definitely more of an infrastructure bug on that server's end. This would apply to |
Version:
I can run this code in my browser and the web socket connects in a reasonable amount of time (given that I'm on a high-latency link, and there's TCP/TLS/HTTP round-trip overhead):
output:
But when I run this in Deno, it takes for-ev-er:
wss://nos.lol
I get reasonable performance there too.So it seems Deno's WebSocket implementation doesn't work well with something on my web socket, in particular. I haven't noticed this in browsers or in iOS apps that connect to that socket. It's likely that I'm just doing something that's an edge case that triggers this poor behavior in Deno's implementation.
I'm just using Axum's WebSocket implementation to handle incoming web sockets. That works instantly when I run locally, without TLS. (127.0.0.1). When I deploy it to my remote server, behind an Nginx proxy, which handles my TLS encryption, then I see the issue. (Again, only in Deno.)
I'm not sure if it's relevant but just in case, my proxy settings in nginx are:
When I enable logging on the proxied service, it seems like it doesn't get the request until many seconds later, at which point things operate "normally" AFAICT. I haven't yet done a packet sniff to see if this delay is in Deno sending the first packet(s) or Nginx holding onto them for a long time before forwarding.
The text was updated successfully, but these errors were encountered: