首先有一点背景。在默认配置下，当socket.io连接启动时，它首先进行2-5个http连接，然后一旦建立了“逻辑”连接，它将尝试使用webSocket传输建立连接。如果成功，则它将该webSocket连接保持为持久连接，并通过该连接发送socket.io数据包。

如果客户端在过渡到WebSocket连接的过程中刷新，则会在服务器上创建一个未知状态的周期，在该状态下服务器不确定用户是否仍在过渡到持久的WebSocket连接的过程中，如果用户已经完全走了，如果用户遇到某种连接问题，或者用户正在做一些刷新操作。你很容易遇到服务器认为在确认过程中来自同一用户的多个连接的情况。如果你的服务器对这种情况敏感，可能会有些混乱。

你能做的最快的事情就是强制连接过程立即进入webSocket传输。你可以在客户端中通过向连接代码中添加一个选项来做到这一点：

let socket = io(yourURL, {transports: ["websocket"]});

如果你想防止除你自己的网页之外的任何其他类型的连接，还可以将服务器配置为仅接受webSocket连接。

然后，这将通过通常的webSocket连接进行，该连接以单个http请求开始，然后将其“升级”为webSocket协议。一旦连接，一个插座。服务器将立即知道用户是否连接。并且，一旦切换到webSocket协议，服务器将立即知道用户是否单击刷新，因为浏览器将立即关闭webSocket。

socket.io中的“从http开头”功能主要是存在的，因为在WebSocket的早期，有些浏览器尚不支持它们，而某些网络基础结构（如公司代理）并不总是支持webSocket。连接。浏览器问题现在完全消失了。使用中的所有浏览器均支持webSocket连接。我个人没有关于公司代理问题的任何数据，但是最近我从来没有听说过使用webSockets的人有任何问题，因此我也不再认为这是个大问题。

因此，以上更改将为你提供快速，确认的连接，并且消除了在连接过程的早期阶段是否连接了用户的困惑。

现在，如果仍然有用户通过快速刷新弄乱了事情，则可能只需要在服务器上实施一些保护措施即可。如果你使用Cookie记录每个到达服务器的用户，则可以创建一些中间件，该中间件将跟踪使用该cookie的浏览器在最近的时间间隔内发出了多少页面请求，并仅向他们返回一个错误页面，说明他们可以执行以下操作：不能迅速提出要求。我可能会在网页级别而不是在webSocket级别实现此功能，因为这将为用户提供更好的反馈以停止刷新。如果你确实想防止网站刷新，而不是在网站上进行常规导航，则可以保留Cookie和URL的组合记录，并且几秒钟之内甚至看不到其中的两个，然后返回错误页面，而不是预期的内容。如果你重定向到错误页面，则将迫使他们采取更自觉的操作，以便再次回到正确的页面，然后才能访问内容。