Tengo un servidor de nodo que se ejecuta en la instancia de EC2 y el cliente también se ejecuta en la misma instancia de EC2, el cliente abre la conexión websocket para comunicar el servidor de nodo, está funcionando en el entorno de control de calidad y desarrollo de AWS, pero la misma conexión web se está cerrando después de 60 segundos de estar inactivo en el entorno de producción, estoy ejecutando el cliente y el servidor de nodos detrás de ELB en el entorno aws.
Codigo del cliente:
ws = new WebSocket('ws://localhost:8443'); ws.onclose = function () { console.log("Websocket connection has been closed."); clientObj.emit('LogoffSuccess', 'LogoffSuccessfully'); }; ws.onerror=function(event) { console.log(event.data); }; ws.addEventListener('open', function (event) { console.log('Websocket connection has been opened'); ws.send(JSON.stringify(loginCreds)); });Código de servidor de nodo a continuación:
const wss = new WebSocket.Server({ server: app }); const clients = {}; const idMap = {}; wss.on(`connection`, ws => { const headers = ws.upgradeReq.headers; const host = headers.host; const key = ws.upgradeReq.headers[`sec-websocket-key`]; ctiServer.on(`responseMessage`, message => { clients[message.AgentId].send(JSON.stringify(message)); }); ws.on(`message`, message => { log.info(`Message received. Host: ${host}, Msg: ${message}`); if (JSON.parse(message).EventName === `Login`) { clients[JSON.parse(message).AgentId] = ws; idMap[key] = JSON.parse(message).AgentId; } ctiServer.processIncomingRequest(message); }); ws.on(`close`, () => { log.info(`Connection closed. Host: ${host}`); const message = { EventName: `Logoff`, AgentId: idMap[key], EventData: {} }; }); });De forma predeterminada, Elastic Load Balancing establece el valor de tiempo de espera de inactividad en 60 segundos. Por lo tanto, si el destino no envía algunos datos al menos cada 60 segundos mientras la solicitud está en curso, el balanceador de carga puede cerrar la conexión de front-end. Para asegurarse de que las operaciones largas, como las cargas de archivos, tengan tiempo para completarse, envíe al menos 1 byte de datos antes de que transcurra cada período de tiempo de espera inactivo y aumente la duración del período de tiempo de espera inactivo según sea necesario.
Tenga en cuenta que sus intereses se atienden mejor enviando tráfico periódicamente para mantener viva la conexión. Puede configurar el tiempo de espera de inactividad hasta en 4000 segundos en un balanceador de carga de aplicaciones, pero encontrará que la infraestructura de red intermedia con estado (cortafuegos, dispositivos NAT) tiende a restablecer las conexiones antes de que estén realmente inactivas durante tanto tiempo.
¡SILBIDO!
Escriba una implementación de ping (o una implementación de mensaje nil )...
... de lo contrario, el proxy de AWS (probablemente nginx) cerrará la conexión después de un período de inactividad (60 segundos en su caso, pero es un poco diferente en diferentes sistemas).
¿Usas NGINX? Sus solicitudes caducan después de 60 segundos.
Puede extender el tiempo de espera en el archivo de configuración de NGINX para su ubicación específica de websockets.
En su caso, podría verse así al extender el tiempo de espera a una hora:
... location / { ... proxy_pass http://127.0.0.1:8443; ... proxy_read_timeout 3600; proxy_send_timeout 3600; ... }Consulte también este sitio web para obtener más información:
https://ubiq.co/tech-blog/increase-request-timeout-nginx/
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout