que - websocket server
¿Deberíamos preferir SSE+REST a través de websocket cuando usamos HTTP/2? (3)
Al usar websocket, necesitamos una conexión dedicada para la comunicación bidireccional. Si usamos http / 2 tenemos una segunda conexión mantenida por el servidor.
En ese caso, el uso de websocket parece introducir una sobrecarga innecesaria porque con SSE y la solicitud http regular podemos tener la ventaja de la comunicación bidireccional en una única conexión HTTP / 2.
¿Qué piensas?
Depende mucho del tipo de aplicación que desee implementar. WebSocket es más adecuado si realmente necesita una comunicación bidireccional entre el servidor y el cliente, pero tendrá que implementar todo el protocolo de comunicación y puede que no sea bien soportado por todas las infraestructuras de TI (algunos cortafuegos, proxy o balanceadores de carga pueden no ser compatibles con WebSockets) . Por lo tanto, si no necesita un enlace bidireccional al 100%, le aconsejo usar SSE con solicitudes REST para obtener información adicional de cliente a servidor. Pero, por otro lado, SSE viene con ciertas advertencias, como por ejemplo en la implementación de JavaScript, no puede sobrescribir los encabezados. La única solución es pasar parámetros de consulta, pero luego puede enfrentar un problema con el límite de tamaño de cadena de consulta. Entonces, de nuevo, elegir entre SSE y WebSockets realmente depende del tipo de aplicación que necesite implementar. Hace unos meses, escribí una publicación de blog que puede proporcionarle cierta información: http://streamdata.io/blog/push-sse-vs-websockets/ . Aunque en ese momento no consideramos HTTP2, esto puede ayudar a saber qué pregunta debe hacerse usted mismo.
Desde la perspectiva de un desarrollador web, la diferencia entre Websockets y una interfaz REST es semántica. REST utiliza un modelo de solicitud / respuesta donde cada mensaje del servidor es la respuesta a un mensaje del cliente. WebSockets, por otro lado, permite que tanto el servidor como el cliente envíen mensajes en cualquier momento sin ninguna relación con una solicitud previa.
Qué técnica usar depende de qué tiene más sentido en el contexto de su aplicación. Claro, puedes usar algunos trucos para simular el comportamiento de una tecnología con la otra, pero usualmente es preferible usar la que mejor se adapte a tu modelo de comunicación cuando se usa con el libro.
Los eventos enviados por el servidor son una tecnología bastante nueva que todavía no es compatible con todos los principales navegadores, por lo que aún no es una opción para una aplicación web seria.
Uso de 2 transmisiones en una conexión multiplexada HTTP / 2 TCP (una transmisión para comunicación de servidor a cliente - Eventos enviados por el servidor (SSE) y una transmisión para comunicación de cliente a servidor y comunicación HTTP normal) versus el uso de 2 conexiones TCP ( uno para comunicación HTTP normal y otro para WebSocket) no es fácil de comparar.
Probablemente el kilometraje variará según las aplicaciones.
Gastos generales ? Bueno, ciertamente la cantidad de conexiones se duplica. Sin embargo, WebSocket puede comprimir mensajes, mientras que SSE no puede.
Flexibilidad? Si las conexiones están separadas, pueden usar diferentes encriptaciones. HTTP / 2 generalmente requiere un cifrado muy fuerte, que puede limitar el rendimiento. Por otro lado, WebSocket no requiere TLS.
¿Funciona WebSocket con texto claro en redes móviles? En la experiencia que tengo, depende. Antivirus, cortafuegos de aplicaciones, operadores móviles pueden limitar el tráfico de WebSocket o hacerlo menos confiable, dependiendo del país en el que opere.
Disponibilidad API? WebSocket es un estándar desplegado y reconocido más amplio; por ejemplo, en Java hay una API oficial ( javax.websocket ) y otra está por venir ( java.net.websocket ).
Creo que SSE es una solución técnicamente inferior para la comunicación web bidireccional y, como tecnología, no se volvió muy popular (sin API estándar, sin libros, etc., en comparación con WebSocket). No me sorprendería si se descarta de HTML5, y no me lo perdería, a pesar de ser uno de los primeros en implementarlo en Jetty.
Dependiendo de lo que le interese, debe hacer sus puntos de referencia o evaluar la tecnología para su caso particular.