我有一个节点服务器和一个通过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".
每隔几秒钟。它应该这样做还是我错过了一个设置。我真的只是想通过socket明确地来回发送数据。也许我在设置中遗漏了一些东西。
客户端基本上是
var socket = io("http://my_url");
与通常的事件监听器。服务器端是
var io = require('socket.io')(server);
我尝试将其放在服务器端
io.set('transports', ['websocket']);
但这似乎杀了它。
答案 0 :(得分:9)
socket.io
实现(使用webSockets时)定期(每隔几秒)发送一次心跳和响应数据包,以不断验证连接是否正常。这个是正常的。
这些数据包不是实际的http请求(它们是websocket数据包)所以除非socket.io
实际上没有使用webSocket协议,否则不应该有全开的http数据包,而是使用HTTP长轮询。 socket.io
将使用webSocket协议,只要客户端支持它(现在它应该在所有现代浏览器中)。
您可能必须小心如何在调试器中解释请求。 socket.io
连接作为带有一些自定义标头的http请求开始其生命,所有调试器都将显示此初始http请求。如果两端都支持webSocket,那么服务器将返回一个"升级"与webSocket协议的连接。那个以TCP请求开头的TCP套接字然后变成了webSocket连接。在webSocket上发送的后续webSockets消息然后流过该TCP套接字。由调试器决定如何显示该流量。在Chrome调试器中,您必须打开原始的http连接,然后要求查看websocket流量,然后才能真正看到webSocket数据包。但是,我可以想象在其他调试器中没有像webSocket saavy一样,他们可能会显示与原始HTTP连接相关的后续数据包(我还没有看过除Chrome以外的调试器如何显示webSocket流量)。 / p>
我能想到的另一个原因是客户端会重复发送HTTP连接请求,如果连接由于某种原因而不断丢失,那么每次连接断开时客户端都会保持重新连接。 socket.io
具有可以控制客户端在连接丢失时尝试重新连接的频率/次数的设置,但是如果您遇到连接问题,那么您确实需要弄清楚为什么存在连接问题而不是更改重新连接设置