Proxy WebSockets con TCP balanceador de carga sin sesiones adhesivas

Question

Proxy WebSockets con TCP balanceador de carga sin sesiones adhesivas

Quiero proxy conexiones WebSocket a múltiples nodos.servidores js que utilizan Amazon Elastic Load Balancer. Dado que Amazon ELB no proporciona soporte WebSocket real, tendría que usar su mensajería TCP vanilla. Sin embargo, estoy tratando de entender cómo funcionaría esto sin algún tipo de funcionalidad de sesión pegajosa.

Entiendo que los WebSockets funcionan enviando primero una solicitud de actualización HTTP desde el cliente, que es manejada por el servidor enviando una respuesta que correctamente maneja la autenticación de claves. Después de que el servidor envía esa respuesta y es aprobada por el cliente, hay una conexión bidireccional entre ese cliente y el servidor.

Sin embargo, digamos que el cliente, después de aprobar la respuesta del servidor, envía datos al servidor. Si envía los datos al equilibrador de carga, y el equilibrador de carga luego transmite esos datos a un servidor diferente que no manejó la solicitud de actualización de WebSocket original, entonces cómo este nuevo servidor será consciente del WebSocket conexión? ¿O el cliente omitirá automáticamente el equilibrador de carga y enviará datos directamente al servidor que gestionó la actualización inicial?

29

node.js websocket socket.io tcp load-balancing

Author: Justin Meltzer, 2013-03-07

Source

2 answers

WebSocket utiliza una conexión TCP persistente, y por lo tanto requiere que todos los paquetes IP para esa conexión TCP se reenvíen al mismo servidor backend (durante la vida útil de la conexión TCP).

Tiene que ser pegajoso. Esto es diferente de L7 HTTP LBs que son capaces de despachar sobre una base de solicitud HTTP.

Una LB puede funcionar pegajosa por diferentes enfoques, es decir,

hash la IP/puerto de origen para el conjunto de servidores backend vivos
con conexión TCP establecimiento, elija un servidor backend y recuerde que

5

Author: oberstet,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-07 16:26:06

score 49 · Accepted Answer

Creo que lo que necesitamos entender para responder a esta pregunta es cómo evoluciona exactamente la conexión TCP subyacente durante todo el proceso de creación de WebSocket. Se dará cuenta de que la parte sticky de una conexión WebSocket es la conexión TCP subyacente en sí. No estoy seguro de lo que quiere decir con "sesión" en el contexto de WebSockets.

En un nivel alto, iniciar una "conexión WebSocket" requiere que el cliente envíe una solicitud HTTP GET a un servidor HTTP, mientras que la solicitud incluye el campo de encabezado Upgrade. Ahora, para que esta solicitud suceda, el cliente necesita haber establecido una conexión TCP con el servidor HTTP (eso podría ser obvio, pero creo que aquí es importante señalar esto explícitamente). La respuesta del servidor HTTP posterior se envía a través de la conexión TCP same .

Tenga en cuenta que ahora, después de que se haya enviado la respuesta del servidor, la conexión TCP sigue abierta/viva si no se cierra activamente por el cliente o por el servidor.

Ahora, de acuerdo con RFC 6455, el estándar WebSocket, al final de la sección 4.1:

Si la respuesta del servidor se valida como se indica anteriormente, es
dijo que Se Establece la Conexión WebSocket y que el
La conexión WebSocket está en estado ABIERTO

He leído desde aquí que la misma conexión TCP que fue iniciada por el cliente antes de enviar la solicitud inicial HTTP GET (Upgrade) simplemente se dejará abra y a partir de ahora servirá como la capa de transporte para la conexión WebSocket full-duplex. Y esto tiene sentido!

Con respecto a su pregunta, esto significa que un balanceador de carga solo jugará un papel antes de que se realice la solicitud inicial HTTP GET (Upgrade), es decir, antes de que la única conexión TCP involucrada en dicha creación de conexión WebSocket se establezca entre los dos puntos finales de comunicación. A partir de entonces, la conexión TCP permanece establecida y no puede convertirse en "redirigido" por un dispositivo de red en el medio.

Podemos concluir que {en su terminología de sesión { la conexión TCP define la sesión . Mientras una conexión WebSocket esté activa (es decir, no esté terminada), por definición proporciona y vive en su propia sesión. Nada puede cambiar esta sesión. Hablando en esta imagen, dos conexiones WebSocket independientes, sin embargo, no pueden compartir la misma sesión.

Si se refiere a otra cosa con "sesión", entonces probablemente es una sesión que es introducida por la capa de aplicación y no podemos comentar sobre esa.

Editar con respecto a sus comentarios:

Así que estás diciendo que el balanceador de carga no está involucrado en el TCP conexión

No, eso no es cierto, al menos en general. Definitivamente puede tomar influencia sobre el establecimiento de la conexión TCP, en el sentido de que puede decidir qué hacer con el intento de conexión del cliente. Concreto depende del tipo exacto de balanceador de carga ( * , ver más abajo). Importante: Después de establecer la conexión entre dos endpoints whereas mientras que no considero que el balanceador de carga sea un endpoint, me refiero al cliente WebSocket y al servidor WebSocket the los dos endpoints ya no cambiarán durante la vida útil de la conexión WebSocket. Es posible que el equilibrador de carga* siga estando en la ruta de red, pero se puede suponer que ya no tendrá influencia.

Por lo tanto, la conexión full-duplex es entre el cliente y el ¿servidor final?

¡Sí!

***Hay diferentes tipos de equilibrio de carga. Dependiendo del tipo, el rol del balanceador de carga es diferente después del establecimiento de la conexión entre los dos puntos finales. Ejemplos:

Si el balanceo de carga se realiza en base a DNS, entonces el balanceador de carga no está involucrado en la conexión TCP final en absoluto. Simplemente le dice al cliente a qué host se tiene que conectar directamente.
Si la carga balancer funciona como el Layer 4 ELB de AWS (docs aquí), entonces por así decirlo proxies la conexión TCP. Así que el cliente realmente vería el ELB como el servidor. Lo que sucede, sin embargo, es que el ELB solo reenvía los paquetes en ambas direcciones, sin cambios. Por lo tanto, todavía está muy involucrado en la conexión TCP, solo de forma transparente. En este caso, en realidad hay dos conexiones TCP permanentes involucradas: una de usted al ELB y otra del ELB al servidor. Estos son de nuevo permanentes durante la vida útil de su conexión WebSocket.