¿HTML WebSockets mantiene una conexión abierta para cada cliente? ¿Esto escala?

Tengo curiosidad por saber si alguien tiene alguna información sobre la escalabilidad de HTML WebSockets. Por todo lo que he leído, parece que cada cliente mantendrá una línea de comunicación abierta con el servidor. Me pregunto cómo se escala y cuántas conexiones WebSocket abiertas puede manejar un servidor. Quizás dejar esas conexiones abiertas no es un problema en realidad, pero parece que lo es.

En la mayoría de los casos, WebSockets probablemente escalará mejor que las solicitudes AJAX / HTML. Sin embargo, eso no significa que WebSockets sea un reemplazo para todos los usos de AJAX / HTML.

Cada conexión TCP en sí misma consume muy poco en términos de recursos del servidor. A menudo, configurar la conexión puede ser costoso, pero mantener una conexión inactiva es casi gratis. La primera limitación que generalmente se encuentra es el número máximo de descriptores de archivo (los sockets consumen descriptores de archivo) que se pueden abrir simultáneamente. A menudo, el valor predeterminado es 1024, pero puede configurarse más fácilmente.

¿Alguna vez intentó configurar un servidor web para admitir decenas de miles de clientes simultáneos AJAX? Cambie esos clientes a clientes de WebSockets y podría ser factible.

Las conexiones HTTP, si bien no crean archivos abiertos ni consumen números de puerto durante un período prolongado, son más caras en casi cualquier otro sentido:

• Cada conexión HTTP lleva una gran cantidad de equipaje que no se usa la mayor parte del tiempo: cookies, tipo de contenido, longitud del contenido, agente de usuario, identificación del servidor, fecha, última modificación, etc. Una vez que se establece una conexión WebSockets, solo el los datos requeridos por la aplicación deben enviarse de un lado a otro.

• Por lo general, los servidores HTTP están configurados para registrar el inicio y la finalización de cada solicitud HTTP que ocupa el tiempo de disco y CPU. Se volverá estándar registrar el inicio y la finalización de los datos de WebSockets, pero mientras la conexión de WebSockets realice la transferencia dúplex no habrá ninguna sobrecarga de registro adicional (excepto por la aplicación / servicio si está diseñado para hacerlo).

• Por lo general, las aplicaciones interactivas que usan AJAX sondean continuamente o utilizan algún tipo de mecanismo de sondeo largo. WebSockets es una forma mucho más limpia (y con menos recursos) de hacer un modelo más eventual donde el servidor y el cliente se notifican entre sí cuando tienen algo que informar sobre la conexión existente.

• La mayoría de los servidores web populares en producción tienen un conjunto de procesos (o subprocesos) para manejar solicitudes HTTP. A medida que aumenta la presión, aumentará el tamaño del grupo porque cada proceso / subproceso maneja una solicitud HTTP a la vez. Cada proceso / subproceso adicional utiliza más memoria y la creación de nuevos procesos / subprocesos es bastante más costoso que la creación de nuevas conexiones de socket (que esos procesos / subprocesos todavía tienen que hacer). La mayoría de los marcos de servidores WebSockets populares siguen la ruta del evento que tiende a escalar y funcionar mejor.

El beneficio principal de WebSockets serán las conexiones de baja latencia para aplicaciones web interactivas. Se escalará mejor y consumirá menos recursos de servidor que HTTP AJAX / long-poll (suponiendo que la aplicación / servidor esté diseñada correctamente), pero la latencia IMO es el beneficio principal de WebSockets porque habilitará nuevas clases de aplicaciones web que no son posibles con la sobrecarga actual y la latencia de AJAX / long-poll.

Una vez que el estándar WebSockets esté más finalizado y tenga un soporte más amplio, tendrá sentido usarlo para la mayoría de las nuevas aplicaciones web interactivas que necesitan comunicarse con frecuencia con el servidor. Para las aplicaciones web interactivas existentes, realmente dependerá de qué tan bien esté funcionando el modelo actual de AJAX / long-poll. El esfuerzo para convertir no será trivial, por lo que en muchos casos el costo no valdrá la pena.

Actualización :

Enlace útil: 600k conexiones websocket concurrentes en AWS usando Node.js

Solo una aclaración: la cantidad de conexiones de clientes que un servidor puede admitir no tiene nada que ver con los puertos en este escenario, ya que el servidor [típicamente] solo está escuchando conexiones WS / WSS en un solo puerto. Creo que a lo que se referían los otros comentaristas eran descriptores de archivos. Puede establecer el número máximo de descriptores de archivo bastante alto, pero luego debe tener cuidado con los tamaños de búfer de socket que se suman para cada socket TCP / IP abierto. Aquí hay información adicional: /server/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system

En cuanto a la disminución de la latencia a través de WS vs. HTTP, es cierto ya que no hay más análisis de encabezados HTTP más allá del apretón de manos WS inicial. Además, a medida que se envían más y más paquetes con éxito, la ventana de congestión TCP se amplía, reduciendo efectivamente el RTT.

Cualquier servidor único moderno puede servir a miles de clientes a la vez . Su software de servidor HTTP tiene que estar orientado a eventos (IOCP) (ya no estamos en la antigua conexión Apache one = one thread / process ecuación). Incluso el servidor HTTP integrado en Windows (http.sys) está orientado a IOCP y es muy eficiente (se ejecuta en modo kernel). Desde este punto de vista, no habrá mucha diferencia en el escalado entre WebSockets y la conexión HTTP normal. Una conexión TCP / IP utiliza un pequeño recurso (mucho menos que un subproceso), y los sistemas operativos modernos están optimizados para manejar muchas conexiones concurrentes: WebSockets y HTTP son solo protocolos de capa de aplicación OSI 7, heredados de estas especificaciones TCP / IP.

Pero, por experimento, he visto dos problemas principales con WebSockets:

1. No son compatibles con CDN;
2. Tienen posibles problemas de seguridad.

Por lo tanto, recomendaría lo siguiente, para cualquier proyecto:

• Use WebSockets solo para notificaciones de clientes (con un mecanismo de reserva para sondeo largo; hay muchas bibliotecas disponibles);
• Use RESTful / JSON para todos los demás datos, usando un CDN o proxies para caché.

En la práctica, las aplicaciones completas de WebSockets no se escalan bien. Simplemente use WebSockets para lo que fueron diseñados: enviar notificaciones del servidor al cliente.

Sobre los posibles problemas del uso de WebSockets:

1. Considere usar un CDN

Hoy (casi 4 años después), el escalado web implica el uso de front-end de Content Delivery Network (CDN), no solo para contenido estático (html, css, js) sino también para los datos de su aplicación (JSON) .

Por supuesto, no colocará todos sus datos en su caché CDN, pero en la práctica, una gran cantidad de contenido común no cambiará con frecuencia. Sospecho que el 80% de sus recursos REST pueden almacenarse en caché ... Incluso un tiempo de espera de caducidad de CDN de un minuto (o 30 segundos) puede ser suficiente para darle a su servidor central una nueva vida y mejorar mucho la capacidad de respuesta de la aplicación, ya que CDN puede estar geográficamente sintonizado ...

Que yo sepa, todavía no hay soporte de WebSockets en CDN, y sospecho que nunca lo sería. Los WebSockets tienen estado, mientras que HTTP no tiene estado, por lo que se almacena en caché con mucha facilidad. De hecho, para que WebSockets sea compatible con CDN, es posible que deba cambiar a un enfoque RESTful sin estado ... que ya no sería WebSockets.

2. Problemas de seguridad

WebSockets tiene posibles problemas de seguridad, especialmente sobre los ataques de DOS. Para obtener una ilustración sobre las nuevas vulnerabilidades de seguridad, consulte este conjunto de diapositivas y este ticket del kit web .

Los WebSockets evitan cualquier posibilidad de inspección de paquetes a nivel de la capa de aplicación OSI 7, que hoy en día es bastante estándar en cualquier seguridad empresarial. De hecho, WebSockets hace que la transmisión se ofusque, por lo que puede ser una violación importante de la fuga de seguridad.

Piénselo de esta manera: lo que es más barato, mantener una conexión abierta o abrir una nueva conexión para cada solicitud (con la sobrecarga de negociación de hacerlo, recuerde que es TCP).

Por supuesto, depende de la aplicación, pero para las conexiones en tiempo real a largo plazo (por ejemplo, un chat AJAX) es mucho mejor mantener la conexión abierta.

El número máximo de conexiones estará limitado por el número máximo de puertos libres para los sockets.

No, no escala, da un trabajo tremendo a los conmutadores de rutas intermedias. Luego, en el lado del servidor, las fallas de la página (debe mantener todos esos descriptores) están alcanzando valores altos, y aumenta el tiempo para llevar un recurso al área de trabajo. Estos son en su mayoría servidores escritos en JAVA y podría ser más rápido mantener esos millones de sockets que destruir / crear uno. Cuando ejecuta dicho servidor en una máquina, cualquier otro proceso ya no puede moverse.