Socket.io 不断轮询……它应该这样做吗？

Question

我有一个节点服务器和一个通过 socket.io 连接的网页。我在浏览器控制台中注意到它正在输出

XHR finished loading: GET "http://my_url/socket.io/?EIO=3&transport=polling&t=1418944327412-412&sid=vqLTUtW3QhNLwQG8AAAA".

和

XHR finished loading: POST "http://my_url/socket.io/?EIO=3&transport=polling&t=1418944385398-415&sid=vqLTUtW3QhNLwQG8AAAA".

每隔几秒。它应该这样做还是我错过了一个设置。我真的只是想通过套接字显式地来回发送数据。也许我在设置中遗漏了一些东西。

客户端基本上是

var socket = io("http://my_url");

使用通常的事件侦听器。服务器端是

var io = require('socket.io')(server);

我试着把它放在服务器端

io.set('transports', ['websocket']);

但这似乎杀死了它。

Answer 1

socket.io 实现（使用 webSockets 时）会定期（每隔几秒）发送心跳和响应数据包，以不断验证连接是否正常。这个是正常的。

这些数据包不是实际的 http 请求（它们是 websocket 数据包），所以不应该有完整的 http 数据包，除非socket.io 实际上没有使用 webSocket 协议，而是使用 HTTP 长轮询。 socket.io 将使用 webSocket 协议，只要客户端支持它（现在所有现代浏览器都应该支持它）。

您可能必须小心在调试器中解释请求的方式。 socket.io 连接以带有一些自定义标头的 http 请求开始其生命周期，所有调试器都将显示此初始 http 请求。如果两端都支持 webSocket，那么服务器将返回一个响应，将连接“升级”到 webSocket 协议。同一个 TCP 套接字最初是一个 TCP 请求，然后变成一个 webSocket 连接。然后在 webSocket 上发送的后续 webSockets 消息流过该 TCP 套接字。由调试器决定如何显示该流量。在 Chrome 调试器中，您必须打开原始 http 连接，然后要求查看 websocket 流量，然后才能真正看到 webSocket 数据包。但是，我可以想象在其他不那么精通 webSocket 的调试器中，它们可能会显示与原始 HTTP 连接相关的后续数据包（我没有研究除 Chrome 之外的调试器如何显示 webSocket 流量）。

我能想到客户端重复发送 HTTP 连接请求的唯一其他原因是，如果连接由于某种原因不断断开，因此客户端在每次连接断开时都会重新连接。 socket.io 的设置可以控制客户端在连接丢失时尝试重新连接的频率/强烈程度，但如果您遇到连接问题，那么您确实需要弄清楚为什么存在连接问题而不是更改重新连接设置。