NodeJS和Socket.io：Chrome无法使用WebSockets加载

Question

谷歌浏览器使用长轮询方式进行加载，加载指示器不停止。

为什么谷歌浏览器不使用WebSockets，如何防止使用长轮询时加载指示器旋转？

我正在使用最新版本的socket.io和nodejs v2.5。

--

第一次连接时，它使用Websocket，但立即断开连接并使用xhr-polling重新连接。

- Luke Burns

---

告诉我你的Chrome版本，我就能告诉你答案 :) - Ivo Wetzel

非常感谢您发布这个问题!! 当然还有 +1 :) - Anmol Saraf

Answer 1

我曾经遇到过类似的问题，发现有一个socketio cookie把传输方法覆盖成了"xhr-polling"。我不知道这个cookie是怎么来的，但删除它就解决了问题。

以下是查找该cookie的代码行的参考链接。 https://github.com/LearnBoost/Socket.IO/blob/master/socket.io.js#L1023

- mbrevoort

---

我找到了这个cookie，将其删除后，问题得到了解决。谢谢！ - Eric Naeseth

删除Cookie解决了问题，并回答了我长期以来的疑问，即为什么WebSocket甚至在我最新的Chrome 30中也不起作用。非常感谢这个答案。+1 - Anmol Saraf

Answer 2

看起来socket.io.js有控制这个的选项。

• tryTransportsOnConnectTimeout - 默认值为true
• rememberTransport - 默认值为true

我认为如果将'tryTransportsOnConnectTimeout'设置为'true'，则socket.io将在连接时遍历所有传输机制，并使用第一个成功的传输机制。

如果将'rememberTransport'设置为'true'，则成功的传输机制将存储在cookie中。

在我的应用程序中，我实现了断开连接后重新连接的逻辑。我发现我必须将上述两个选项都设置为“false”，以防止回退到不想要的传输机制。问题是在断开连接后，服务器可能随时变得可用（例如客户端尝试长轮询而不是WebSockets）。如果发生这种情况，cookie将被设置，并且随后的连接将继续使用不想要的传输机制。

- Jon Nalley

Answer 3

我正在使用Chrome 8，WebSockets似乎可以正常工作。

如果您正在使用socket.io，则应该在长轮询（或永久iframe）之前回退到FlashSockets甚至xhr-multipart。在初始化服务器和客户端上的socket.io时，请检查您的传输选项。

- Robin Duckett

---

我在Webfaction上使用了两个不同的子域 - 我能想到的唯一原因是它认为这是跨域，因此回退到轮询？可能与Webfaction有关。 - Luke Burns

尝试将传输设置为强制使用非轮询的特定传输方式。 - Robin Duckett

我尝试在客户端选项中设置它，但仍然连接到xhr-polling。有没有一种方法可以在服务器上强制它？ - Luke Burns