socket.io 默认支持断开重连。可经常断开长连也很不好。短时间内（比如一分钟）断开重连这种现象，很容易观察到，并且可以观察到时间都很准时，每经过某个时间就会断开然后重连。
遇到这个现象，该怎么处理呢。如果熟悉 socket.io 的机制，可能想到心跳问题。这里先跳过。
遇到这个现象 ，可能你会找服务端的原因。是 nginx 出问题了，还是实现 socket.io 的服务出现问题了。（socket.io 是 websocket 的包装版）
- 观察 nginx，因为 nginx 的代码最少。发现 nginx timeout 都注释掉了。
# proxy_connect_timeout 60s;
# proxy_send_timeout 60s;
# proxy_read_timeout: Nginx will close the connection if the proxied server does not send data to Nginx in 60 seconds; At the same time, this close behavior is also affected by heartbeat setting of Swoole.
# proxy_read_timeout 60s;
- 分析框架源码，这个是最漫长，和可能性大的。毕竟用到别人的框架。这里使用 swoole + laravels + websocket 的 socket.io 的封装。找了好久也没找到问题。
-
找不到具体原因，然后去看 socket.io 的文档。才发现，心跳没发送是一个原因。
https://socket.io/docs/server-api/#new-Server-httpServer-options
重述具体现象
前端页面连接好 socket.io 后，如果前端不发送任何消息，60 秒内，服务端就会断开服务。然后重连。如果在 60 秒之内，你有发送消息，这个断开时间就会延长。直到你不发消息后的 60 秒。那如果这样，利用 socket.io 的心跳不就解决了。可是，从始至终，都没看见过发送过心跳。原来是服务端设置的心跳时间太长了，远远超过了 60 秒。也就是心跳还没来得及发，服务端就已经断开了，前端就已经又重连了。既然这样，那控制心跳时间小于 60 秒不就好了。
既然是一种方法，那么前端 socket.io 怎么发送这个心跳呢。
前端连接好服务端后，服务端会推送一个消息下来，这个消息包裹以下信息：
0{"sid":"NWUwZWY4NzBiYjk1OQ==","upgrades":[],"pingInterval":44000,"pingTimeout":36000}
就是以 pingInterval 这个频率来发送心跳。 pingInterval 要大于 pingTimeout。 这样就可以很直接的看到心跳的间隔。修改服务端代码，onOpen 的时候，推送这个消息过来就好，并 pingInterval 是正确的值。
心跳就是 ping pong。一来一回，建立起来就好。
末了
socket.io 是 websocket 的封装版，就是在 websocket 上加入了约定好的算法以及计算，来实现 socket.io 的这种连接方式。
上边虽然解决了不再一分钟断开又重连。可是这个心跳频率还是有点高。因为上边提到的一分钟就断开，导致没办法把心跳设置大一点。这个问题需要处理。还是得去了解源码，进一步分析吧。