"script": "./app.js",
"env": {
"NODE_ENV": "development"
},
"env_production": {
"NODE_ENV": "production"
},
"instances": 4,
"exec_mode": "cluster",
"max_restarts" : 3,
"restart_delay" : 5000,
"log_date_format" : "YYYY-MM-DD HH:mm Z",
"combine_logs" : true
}
]}
这样，执行命令
pm2 start pm2.json即可开启服务，访问127.0.0.1:8080/page，点击按钮发起ws连接，观察控制台即可。下图清晰显示了socket.io握手的错误：
可见在websocket连接建立之前多出了3个xhr请求，而websocket连接建立失败后又多出了几个xhr请求，同时最后两个xhr请求失败了。
socket.io没有采用直接建立websocket连接的粗暴方式，而是首先通过http请求（xhr）访问服务端的相关轮训配置信息以及sid。此处sid类似sessionID，但是它唯一标识连接，可理解为socketId，以后每次http请求cookie中都必须携带sid（httponly）；
第二、三个请求用于确认连接，在socket.io中，post请求是客户端发送消息给服务端的唯一形式，而且post响应一定是“ok”，它的“content-length”一定为2；而get请求主要用于轮训，同时获取服务端的相关消息，这会在下文中有体现；
第四个websocket连接请求失败，这主要是由于与后端http握手失败造成的；
第五个请求为xhr方式的post请求，它是作为websocket通道建立失败后的一种兼容性处理，上文讲述了socket.io的post请求只在客户端需要发送消息给服务端时才会使用，因此，为了证实我们查看消息体：
可见，它携带了客户端发出的消息类型b:message,同时包含消息体{}空对象。对应的，服务端返回“OK”；
第六个请求为xhr方式的get请求，用来获取服务端对第五个请求的响应。
至此，大致分析了socket.io建立连接的大致过程以及连接建立失败后如何兜底的方案，下面分析为何出现握手失败的问题。
原因何在
实例中pm2主进程开启了4个工作进程，由主进程侦听8080端口并分发请求给工作进程。pm2进程在分发请求的阶段采用了某种算法的均衡，如round-robin或者其他hash方式（但不是iphash），因此在socket.io客户端连接建立阶段发送的多个xhr请求，会被pm2定位到不同的worker进程中。前文中提到每个xhr请求都会携带sid字段标识当前连接，因此当一个携带sid字段的请求被pm2定位到另一个与该连接无关的worker时，就会造成请求失败，返回
