node.js - real - socket.io chat rooms example

Proxying WebSockets con balanceador de carga TCP sin sesiones pegajosas (2)

Creo que lo que debemos 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 adhesiva de una conexión WebSocket es la conexión TCP subyacente. No estoy seguro de qué 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 del encabezado Upgrade . Ahora, para que ocurra esta solicitud, el cliente debe 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 siguiente respuesta del servidor HTTP se envía a través de la misma conexión TCP.

Tenga en cuenta que ahora, una vez que se ha enviado la respuesta del servidor, la conexión TCP sigue abierta / activa si el cliente o el servidor no la cierran activamente.

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

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

Leí desde aquí que la misma conexión TCP que inició el cliente antes de enviar la solicitud HTTP GET (Actualizar) inicial se dejará abierta y de ahora en adelante servirá como la capa de transporte para la conexión WebSocket de dúplex completo. ¡Y esto tiene sentido!

Con respecto a su pregunta, esto significa que un equilibrador de carga solo desempeñará un papel antes de que se realice la solicitud inicial de GET (Actualización) de HTTP, es decir, antes de que se establezca la única conexión TCP involucrada en dicha creación de conexión WebSocket entre los dos puntos finales de comunicación . A partir de entonces, la conexión TCP permanece establecida y no puede ser "redirigida" por un dispositivo de red intermedio.

Podemos concluir que, en la terminología de su sesión, la conexión TCP define la sesión . Mientras una conexión WebSocket esté activa (es decir, no finalizada), 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 refirió a otra cosa con "sesión", es probable que sea una sesión introducida por la capa de aplicación y no podamos comentarla.

Edita con respecto a tus comentarios:

por lo que está diciendo que el equilibrador de carga no está involucrado en la conexión TCP

No, eso no es cierto, al menos en general. Definitivamente puede influir en el establecimiento de la conexión TCP, en el sentido de que puede decidir qué hacer con el intento de conexión del cliente. Los detalles específicos dependen del tipo exacto de equilibrador de carga (*, consulte a continuación). Importante: una vez establecida la conexión entre dos puntos finales, aunque no considero que el equilibrador de carga sea un punto final, me refiero al cliente WebSocket y al servidor WebSocket. Los dos puntos finales ya no cambiarán durante la vida útil de la conexión WebSocket. . El equilibrador de carga podría * todavía estar en la ruta de la red, pero se puede asumir 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 balanceo de carga. Dependiendo del tipo, la función del equilibrador de carga es diferente después del establecimiento de la conexión entre los dos puntos finales. Ejemplos:

Si el equilibrio de carga se realiza en base a DNS, entonces el equilibrador de carga no está involucrado en la conexión TCP final en absoluto. Simplemente le dice al cliente que el host tiene que conectarse directamente .
Si el equilibrador de carga funciona como el ELB de capa 4 de AWS (docs here ), entonces, por así decirlo, apunta la conexión TCP. Así que el cliente realmente vería el ELB como el servidor. Sin embargo, lo que sucede es que el ELB simplemente 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 nuevamente permanentes durante el tiempo de vida de su conexión WebSocket.

Quiero establecer conexiones de WebSocket a varios servidores node.js usando Amazon Elastic Load Balancer. Dado que Amazon ELB no proporciona soporte WebSocket real, necesitaría usar su mensajería TCP de vainilla. Sin embargo, estoy tratando de entender cómo funcionaría esto sin algún tipo de funcionalidad de sesión pegajosa.

Entiendo que WebSockets funciona enviando primero una solicitud de Actualización HTTP desde el cliente, que es manejada por el servidor enviando una respuesta que maneja correctamente la autenticación clave. Una vez que el servidor envía esa respuesta y el cliente la aprueba, existe 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, ¿cómo notará este nuevo servidor la conexión de WebSocket? ¿O el cliente omitirá automáticamente el equilibrador de carga y enviará los datos directamente al servidor que manejó la actualización inicial?

WebSocket usa 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).

Necesita ser pegajoso. Esto es diferente de los LB HTTP L7 que pueden enviarse por solicitud HTTP.

Un LB puede trabajar pegajoso por diferentes enfoques, es decir,

hash de la IP / puerto de origen al conjunto de servidores backend activos
Al establecer la conexión TCP, elija un servidor backend y recuerde que