html5 - websockets - websocket vs rest

Escalabilidad del servidor-HTML 5 websockets vs Comet

Question

Muchas implementaciones de cometas como Caplin proporcionan soluciones de servidor escalables.

A continuación una de las estadísticas del sitio de Caplin :

Una sola instancia de Caplin liberator puede admitir hasta 100,000 clientes, cada uno de los cuales recibe 1 mensaje por segundo con una latencia promedio de menos de 7 ms.

¿Cómo se compara esto con los websockets HTML5 en cualquier servidor web? ¿Alguien puede señalarme alguna estadística de HTML 5 websockets?

Answer 1

Divulgación - Yo trabajo para Caplin.

Hay un poco de desinformación en esta página, así que me gustaría intentarlo y aclararlo.

Creo que podríamos dividir los métodos de los que estamos hablando en tres campos.

1. Comet HTTP polling - incluyendo polling largo
2. Transmisión HTTP Comet: los mensajes del servidor al cliente utilizan un único socket persistente sin sobrecarga de encabezado HTTP después de la configuración inicial
3. Comet WebSocket - único zócalo bidireccional

Los veo a todos como Comet, ya que Comet es solo un paradigma, pero desde que WebSocket apareció, algunas personas quieren tratarlo como si fuera diferente o reemplazan a Comet, pero es solo otra técnica, y a menos que esté contento de que solo sea compatible con los últimos navegadores. entonces no puedes simplemente confiar en WebSocket.

En lo que respecta al rendimiento, la mayoría de los puntos de referencia se concentran en los mensajes de servidor a cliente: número de usuarios, número de mensajes por segundo y la latencia de esos mensajes. Para este escenario, no hay una diferencia fundamental entre HTTP Streaming y WebSocket: ambos están escribiendo mensajes en un socket abierto con poco o ningún encabezado o sobrecarga.

Un sondeo largo puede dar una buena latencia si la frecuencia de los mensajes es baja. Sin embargo, si tiene dos mensajes (de servidor a cliente) en una sucesión rápida, el segundo no llegará al cliente hasta que se realice una nueva solicitud después de que se reciba el primer mensaje.

Creo que alguien tocó en HTTP KeepAlive. Obviamente, esto puede mejorar el sondeo largo: aún tiene la sobrecarga del viaje de ida y vuelta y los encabezados, pero no siempre la creación de socket.

Donde WebSocket debería mejorar la transmisión HTTP en escenarios donde hay más mensajes de cliente a servidor. Al relacionar estos escenarios con el mundo real se crean configuraciones un poco más arbitrarias, en comparación con la simple comprensión de "enviar muchos mensajes a muchos clientes" que todos puedan entender. Por ejemplo, en una aplicación de negociación, crear un escenario en el que incluya usuarios que ejecutan operaciones (es decir, mensajes de cliente a servidor) es fácil, pero los resultados son un poco menos significativos que los escenarios básicos de servidor a cliente. Los operadores no intentan realizar 100 operaciones por segundo, por lo que terminan obteniendo resultados como ''10000 usuarios que reciben 100 mensajes por segundo y también envían un mensaje al cliente una vez cada 5 minutos''. La parte más interesante para el mensaje del cliente al servidor es la latencia, ya que la cantidad de mensajes requeridos generalmente es insignificante en comparación con los mensajes del servidor al cliente.

Otro punto que alguien mencionó anteriormente, unos 64 mil clientes, no necesita hacer nada inteligente para admitir más de 64 mil sockets en un servidor, aparte de configurar los descriptores de archivo de números, etc. Si intentaba hacer una conexión de 64 mil desde una sola máquina cliente , eso es totalmente diferente ya que necesitan un número de puerto para cada uno, aunque en el extremo del servidor está bien, ese es el extremo de escucha, y puede ir bien por encima de los zócalos de 64k.

Answer 2

En teoría, WebSockets puede escalar mucho mejor que HTTP, pero hay algunas advertencias y algunas formas de abordar esas advertencias también.

La complejidad del procesamiento de encabezado de protocolo de enlace de HTTP vs WebSockets es aproximadamente la misma. El protocolo de enlace HTTP (y WebSocket inicial) puede ser más de 1 K de datos (debido a las cookies, etc.). La diferencia importante es que el protocolo de enlace HTTP vuelve a ocurrir en todos los mensajes. Una vez que se establece una conexión WebSocket, la sobrecarga por mensaje es de solo 2-14 bytes.

Los excelentes enlaces de referencia de Jetty publicados en la respuesta de @David Titarenco ( 1 , 2 ) muestran que WebSockets puede lograr fácilmente una latencia superior a un orden de magnitud en comparación con Comet.

Consulte esta respuesta para obtener más información sobre la escala de WebSockets vs HTTP.

Advertencias :

• Las conexiones WebSocket son de larga duración, a diferencia de las conexiones HTTP, que son de corta duración. Esto reduce significativamente la sobrecarga (sin creación y administración de socket para cada solicitud / respuesta), pero sí significa que para escalar un servidor por encima de 64k hosts de cliente simultáneos separados, necesitará usar trucos como varias direcciones IP en el mismo servidor.

• Debido a problemas de seguridad con los intermediarios web, los mensajes WebSocket de navegador a servidor tienen todos los datos de carga útil XOR enmascarados. Esto agrega cierta utilización de la CPU al servidor para decodificar los mensajes. Sin embargo, XOR es una de las operaciones más eficientes en la mayoría de las arquitecturas de CPU y con frecuencia hay asistencia de hardware disponible. Los mensajes de servidor a navegador no están enmascarados y dado que muchos usos de WebSockets no requieren grandes cantidades de datos enviados desde el navegador al servidor, esto no es un gran problema.

Answer 3

Es difícil saber cómo eso se compara con cualquier cosa porque no sabemos qué tan grande es el tamaño de la carga útil (promedio). Bajo el capó (como en la forma en que se implementa el servidor), la transmisión HTTP y los websockets son virtualmente idénticos, aparte del protocolo de enlace inicial, que es más complicado cuando se hace con HTTP, obviamente.

Si escribió su propio servidor websocket en C (ala Caplin), probablemente podría alcanzar esos números sin demasiada dificultad. La mayoría de las implementaciones de websocket se realizan a través de paquetes de servidores existentes (como Jetty), por lo que la comparación no sería realmente justa.

Algunos puntos de referencia :
1
2

Sin embargo, si nos fijamos en los puntos de referencia de C event lib, como libev y libevent, los números se ven mucho más atractivos:
http://libev.schmorp.de/bench.html

Answer 4

Ignorar cualquier forma de sondeo, que como se explica en otra parte, puede introducir latencia cuando la tasa de actualización es alta, las tres técnicas más comunes para la transmisión de JavaScript son:

1. WebSocket
2. Comet XHR / XDR streaming
3. Comet Forever IFrame

WebSocket es, con mucho, la solución más limpia, pero todavía hay problemas en cuanto a que la infraestructura de red y del navegador no lo admite. Cuanto antes se pueda confiar en lo mejor.

XHR / XDR y Forever IFrame están bien para enviar datos a los clientes desde el servidor, pero requieren que se realicen varios trucos para que funcionen de forma coherente en todos los navegadores. En mi experiencia, estos enfoques de Comet son siempre un poco más lentos que WebSockets, no solo porque se requiere mucho más código de JavaScript del lado del cliente para que funcione; desde la perspectiva del servidor, el envío de datos a través del cable sucede a la misma velocidad.

Aquí hay algunos más gráficos de referencia de WebSocket , esta vez para nuestro producto my-Channels Nirvana .

Omita los gráficos de datos binarios y de multidifusión hasta el último gráfico de la página (Alta tasa de actualización de JavaScript)

En resumen: los resultados muestran que Nirvana WebSocket entrega 50 eventos / seg a 2,500k usuarios con una latencia de 800 microsegundos. A 5,000 usuarios (un total de 250k eventos / seg. Transmitidos) la latencia es de 2 milisegundos.