services - ¿Cuáles son las trampas del uso de Websockets en lugar de RESTful HTTP?

websocket vs socket

Question

Actualmente estoy trabajando en un proyecto que requiere que el cliente solicite un gran trabajo y lo envíe al servidor. Luego, el servidor divide el trabajo y responde con una serie de direcciones URL para que el cliente realice una llamada GET y transmita los datos. Soy el novato en el proyecto y actualmente estoy usando Spring Websockets para mejorar la eficiencia. En lugar de que los clientes hagan ping constantemente al servidor para ver si tiene resultados listos para transmitir, el websocket ahora se pondrá en contacto directamente con el cliente ¡hurra!

¿Sería una mala idea que Websockets gestione todo el proceso de principio a fin? Estoy usando STOMP con Spring WebSockets, ¿seguirá habiendo problemas importantes con la eliminación de REST?

Answer 1

Con RESTful HTTP, tiene un sistema de solicitud / respuesta sin estado donde el cliente envía la solicitud y el servidor devuelve la respuesta.

Con webSockets, tiene un sistema de paso de mensajes con estado (o potencialmente con estado) en el que los mensajes se pueden enviar de cualquier manera y el envío de cualquier mensaje dado tiene una sobrecarga menor que con una solicitud / respuesta RESTful HTTP.

Las dos son estructuras bastante diferentes con diferentes fuerzas.

Las principales ventajas de un webSocket conectado son:

1. Comunicación bidireccional. Por lo tanto, el servidor puede notificar al cliente cualquier cosa en cualquier momento. Entonces, en lugar de sondear un servidor en un intervalo regular para ver si hay algo nuevo, un cliente puede establecer un webSocket y simplemente escuchar cualquier mensaje que provenga del servidor. Desde el punto de vista del servidor, cuando ocurre un evento de interés para un cliente, el servidor simplemente envía un mensaje al cliente. El servidor no puede hacer esto con HTTP simple.

2. Menos gastos generales por mensaje. Si anticipa una gran cantidad de tráfico que fluye entre el cliente y el servidor, entonces hay una menor sobrecarga por mensaje con un webSocket. Esto se debe a que la conexión TCP ya está establecida y solo tiene que enviar un mensaje en un socket ya abierto. Con una solicitud HTTP REST, primero debe establecer una conexión TCP que sea de ida y vuelta entre el cliente y el servidor. Luego, envía una solicitud HTTP, recibe la respuesta y cierra la conexión TCP. La solicitud HTTP necesariamente incluirá algunos gastos generales, como todas las cookies que están alineadas con ese servidor, incluso si no son relevantes para la solicitud en particular. HTTP / 2 (la especificación HTTP más reciente) permite una eficiencia adicional a este respecto si está siendo utilizado tanto por el cliente como por el servidor porque una única conexión TCP puede usarse para algo más que una sola solicitud / respuesta. Si trazó todas las solicitudes / respuestas que se realizan en el nivel TCP solo para hacer una solicitud / respuesta REST https, se sorprenderá de cuánto está sucediendo en comparación con solo enviar un mensaje a través de un WebSocket ya establecido.

3. Mayor escala en algunas circunstancias. Con una sobrecarga menor por mensaje y sin encuestas de clientes para averiguar si algo es nuevo, esto puede llevar a una mayor escalabilidad (mayor número de clientes que puede servir un servidor determinado). También hay desventajas en la escalabilidad de webSocket (ver más abajo).

4. Conexiones con estado. Sin recurrir a cookies e ID de sesión, puede almacenar directamente el estado en su programa para una conexión determinada. Si bien se ha desarrollado mucho con conexiones sin estado para resolver la mayoría de los problemas, a veces es más simple con conexiones con estado.

Las principales ventajas de una solicitud / respuesta HTTP RESTful son:

1. Soporte universal Es difícil obtener más compatibilidad universal que HTTP. Si bien ahora webSocket disfruta de un soporte relativamente bueno, todavía hay algunas circunstancias en las que el soporte webSocket no está disponible regularmente.

2. Compatible con más entornos de servidor. Hay entornos de servidor que no permiten procesos de servidor de larga ejecución (algunas situaciones de alojamiento compartido). Estos entornos pueden admitir solicitudes HTTP, pero no pueden admitir conexiones webSocket de larga ejecución.

3. Mayor escala en algunas circunstancias. El requisito de webSocket para un socket TCP conectado continuamente agrega algunos requisitos nuevos de escala a la infraestructura del servidor que las solicitudes HTTP no exigen. Entonces, esto termina siendo un espacio de compensación. Si las ventajas de webSockets no son realmente necesarias o se usan de manera significativa, entonces las solicitudes HTTP podrían escalar mejor. Definitivamente depende del perfil de uso específico.

4. Para una solicitud / respuesta única, una sola solicitud HTTP es más eficiente que establecer un webSocket, usarlo y luego cerrarlo. Esto se debe a que abrir un webSocket comienza con una solicitud / respuesta HTTP y luego, después de que ambas partes hayan acordado actualizar a una conexión webSocket, se puede enviar el mensaje real de webSocket.

5. Apátrida. Si su trabajo no se complica por tener una infraestructura sin estado, entonces un mundo sin estado puede hacer que la escala sea mucho más fácil (solo agregue más procesos de servidor detrás de un equilibrador de carga).

6. Caché automáticamente. Con la configuración correcta del servidor, el navegador o los servidores proxy pueden almacenar en caché las respuestas http. No existe un mecanismo integrado para las solicitudes enviadas a través de webSockets.

Entonces, para abordar la forma en que hizo la pregunta:

¿Cuáles son las desventajas de usar websockets en lugar de RESTful HTTP?

1. A gran escala (cientos de miles de clientes), es posible que deba realizar un trabajo especial en el servidor para admitir grandes cantidades de WebSockets conectados simultáneamente.

2. Todos los clientes o conjuntos de herramientas posibles no admiten webSockets o las solicitudes realizadas sobre ellos al mismo nivel que admiten solicitudes HTTP.

3. Algunos de los entornos de servidor menos costosos no admiten los procesos de servidor de larga ejecución necesarios para admitir webSockets.

Si es importante para su aplicación devolver notificaciones de progreso al cliente, puede usar una conexión http de larga ejecución con el progreso continuo enviado o puede usar un webSocket. El webSocket es probablemente más fácil. Si realmente solo necesita el webSocket para la duración relativamente corta de esta actividad en particular, entonces puede encontrar que el mejor conjunto general de compensaciones se produce al usar un webSocket solo durante el tiempo en que necesita la capacidad de enviar datos al cliente y luego usando solicitudes http para las actividades normales de solicitud / respuesta.

Answer 2

Realmente depende de tus requerimientos. Los servicios REST pueden ser mucho más transparentes y más fáciles de recoger por el desarrollador en comparación con Websockets.

Con Websockets, elimina la mayoría de las ventajas que ofrecen los servicios web RESTful, como la capacidad de hacer referencia a un recurso a través de un URI. Realmente, lo que debe hacer es descubrir cuáles son las ventajas de REST e hipermedia, y en base a eso decidir si esas ventajas son importantes para usted.

Por supuesto, es completamente posible crear un servicio web RESTful y aumentarlo con una API basada en websocket para respuestas en tiempo real.

Pero si está creando un servicio que solo va a consumir en un entorno controlado, la única desventaja podría ser que no todos los clientes admiten websockets, mientras que casi cualquier tipo de entorno puede hacer una simple llamada http.