HTTP y Websockets: comprensión de las capacidades de las tecnologías de comunicación web actuales

Decidir qué elegir para su próximo diseño de API web

Hay tantas clasificaciones para las API. Pero cuando se trata de comunicación web, podemos identificar dos tipos de API importantes: API de servicio web (por ejemplo, SOAP, JSON-RPC, XML-RPC, REST) ​​y API de Websocket. Pero, ¿qué significan realmente? Sumérjase en el mundo de los protocolos de comunicación web y analicemos cómo elegir los mejores mecanismos API al final.

HTTP

HTTP es el protocolo de comunicación subyacente de la World Wide Web. HTTP funciona como un protocolo de solicitud-respuesta en el modelo informático cliente-servidor. HTTP / 1.1 es la versión más común de HTTP utilizada en los navegadores web y servidores modernos. En comparación con las primeras versiones de HTTP, esta versión podría implementar optimizaciones de rendimiento críticas y mejoras de características tales como conexiones persistentes y canalizadas, transferencias fragmentadas, nuevos campos de encabezado en el cuerpo de solicitud / respuesta, etc. Entre ellos, los siguientes dos encabezados son muy notables, porque La mayoría de las mejoras modernas a HTTP se basan en estos dos encabezados.

  • Encabezado Keep-Alive para establecer políticas para comunicaciones de larga duración entre hosts (período de tiempo de espera y recuento máximo de solicitudes para manejar por conexión)
  • Actualizar encabezado para cambiar la conexión a un modo de protocolo mejorado como HTTP / 2.0 (h2, h2c) o Websockets (websocket)

Si está interesado en saber lo que realmente hacen, he documentado toda la información importante para usted en el siguiente artículo.

DESCANSO

El estilo arquitectónico, REST (REpresentational State Transfer) es, con mucho, la forma más estandarizada de estructurar las API web para solicitudes. REST es puramente un estilo arquitectónico basado en varios principios. Las API que se adhieren a los principios REST se denominan API RESTful. Las API REST usan un modelo de solicitud / respuesta donde cada mensaje del servidor es la respuesta a un mensaje del cliente. En general, las API RESTful usan HTTP como su protocolo de transporte. Para tales casos, las búsquedas deben usar solicitudes GET. Las solicitudes PUT, POST y DELETE deben usarse para mutación, creación y eliminación respectivamente (evite usar solicitudes GET para actualizar la información).

Sondeo HTTP

En HTTP Polling, el cliente sondea al servidor solicitando nueva información al adherirse a uno de los siguientes mecanismos. La gran mayoría de las aplicaciones utilizan hoy el sondeo y la mayoría de las veces se aplica a las prácticas RESTful. En la práctica, el sondeo HTTP corto se usa muy raramente y el sondeo HTTP largo o el sondeo periódico es siempre la opción.

  • HTTP Short Polling: enfoque más simple. Se procesan muchas solicitudes a medida que llegan al servidor, lo que crea mucho tráfico (utiliza recursos, pero los libera tan pronto como se envía la respuesta). Dado que cada conexión solo está abierta por un corto período de tiempo, muchas conexiones pueden multiplexarse ​​en el tiempo.
00:00:00 C-> ¿Está listo el pastel?
00:00:01 S-> No, espera.
00:00:01 C-> ¿Está listo el pastel?
00:00:02 S-> No, espera.
00:00:02 C-> ¿Está listo el pastel?
00:00:03 S-> Sí. Tener un muchacho.
00:00:03 C-> ¿Está listo el otro pastel?
  • Sondeo largo HTTP: una solicitud va al servidor y el cliente está esperando la respuesta. El servidor mantiene la solicitud abierta hasta que haya nuevos datos disponibles (no se han resuelto y los recursos están bloqueados). Se le notificará sin demora cuando ocurra el evento del servidor. Más complejos y más recursos de servidor utilizados.
Sondeo largo HTTP: la respuesta se retiene hasta que los datos del proceso del servidor (Imagen de shyamapadabatabyal.wordpress.com)
12:00 00:00:00 C-> ¿Está listo el pastel?
12:00 00:00:03 S-> Sí. Tener un muchacho.
12:00 00:00:03 C-> ¿Está listo el otro pastel?
  • Sondeo periódico HTTP: existe un intervalo de tiempo predefinido entre dos solicitudes. Esta es una versión mejorada / administrada de sondeo. Puede reducir el consumo del servidor aumentando el intervalo de tiempo entre dos solicitudes. Pero si necesita ser notificado sin demora cuando ocurre el evento del servidor, esta no es una buena opción.
Sondeo periódico HTTP: la solicitud se envía cada n segundos (Imagen de ibm.com)
00:00:00 C-> ¿Está listo el pastel?
00:00:01 S-> No, espera.
00:00:03 C-> ¿Está listo el pastel?
00:00:04 S-> Sí. Tener un muchacho.
00:00:06 C-> ¿Está listo el otro pastel?

Streaming HTTP

Streaming HTTP: proporciona una conexión de larga duración para la inserción de datos instantánea y continua (Imagen de realtimeapi.io)

El cliente realiza una solicitud HTTP, y el servidor emite una respuesta de longitud indefinida (es como sondear infinitamente). La transmisión HTTTP es eficiente, fácil de consumir y puede ser una alternativa a los sockets web.

  • Problema: los intermediarios pueden interrumpir la conexión (p. Ej., Tiempo de espera, intermediarios que atienden otras solicitudes de forma automática). En tales casos, no puede garantizar el tiempo real completo.
00:00:00 CLIENTE-> Necesito pasteles
00:00:01 SERVIDOR-> Espera un momento.
00:00:01 SERVIDOR-> Cake-1 está en proceso.
00:00:02 SERVIDOR-> Tener pastel-1.
00:00:02 SERVIDOR-> Espera el pastel-2.
00:00:03 SERVIDOR-> Cake-2 está en proceso.
00:00:03 SERVIDOR-> Debes estar disfrutando el pastel-1.
00:00:04 SERVIDOR-> Tener pastel-2.
00:00:04 SERVIDOR-> Espera el pastel-3.
00:00:05 CLIENTE-> Suficiente, estoy lleno.

SSE (Eventos enviados por el servidor / EventSource)

SSE: los eventos se pueden transmitir a varios clientes (Imagen de javaee.ch)
  • Las conexiones SSE solo pueden enviar datos al navegador. (la comunicación se realiza solo del servidor al navegador, los navegadores solo pueden suscribirse a las actualizaciones de datos originadas por el servidor, pero no pueden enviar ningún dato al servidor)
00:00:00 CLIENTE-> Necesito pasteles
00:00:02 SERVIDOR-> Tener pastel-1.
00:00:04 SERVIDOR-> Tener pastel-2.
00:00:05 CLIENTE-> Suficiente, estoy lleno.
  • Aplicaciones de muestra: actualizaciones de Twitter, cotizaciones de bolsa, puntajes de cricket, notificaciones al navegador
  • Problema 1: algunos navegadores no son compatibles con SSE.
  • Problema n.º 2: el número máximo de conexiones abiertas está limitado a 6 u 8 a través de HTTP / 1.1 (según la versión del navegador). Si usa HTTP / 2, no habrá problemas porque una sola conexión TCP es suficiente para todas las solicitudes (gracias al soporte multiplexado en HTTP / 2).

Servidor HTTP / 2 Push

  • Un mecanismo para que un servidor empuje activos de forma proactiva (hojas de estilo, scripts, medios) al caché del cliente por adelantado
  • Aplicaciones de muestra: feeds de redes sociales, aplicaciones de una sola página
HTTP / 2 es una capa de transporte eficiente basada en flujos multiplexados (Imagen de SessionStack.com) - Según IETF, un
  • Problema n. ° 1: los intermediarios (servidores proxy, enrutadores, hosts) pueden optar por no enviar correctamente la información al cliente según lo previsto por el servidor de origen.
  • Problema # 2: Las conexiones no se mantienen abiertas indefinidamente. Una conexión se puede cerrar en cualquier momento, incluso cuando ocurre el proceso de envío de contenido. Una vez cerrado y abierto de nuevo, esta conexión no puede continuar desde donde se fue.
  • Problema # 3: Algunos navegadores / intermediarios no son compatibles con Server Push.

Websockets

WebSockets permite que tanto el servidor como el cliente envíen mensajes en cualquier momento sin ninguna relación con una solicitud previa. Una ventaja notable en el uso de websockets es que casi todos los navegadores admiten websockets.

WebSocket resuelve algunos problemas con HTTP:

  • Protocolo bidireccional: el cliente / servidor puede enviar un mensaje a la otra parte (en HTTP, la solicitud siempre la inicia el cliente y el servidor procesa la respuesta, lo que convierte a HTTP en un protocolo unidireccional)
  • Comunicación full-duplex: el cliente y el servidor pueden comunicarse entre sí de forma independiente al mismo tiempo.
  • Conexión TCP única: después de actualizar la conexión HTTP al principio, el cliente y el servidor se comunican a través de la misma conexión TCP durante todo el ciclo de vida de la conexión Websocket.
00:00:00 CLIENTE-> Necesito pasteles
00:00:01 SERVIDOR-> Espera un momento.
00:00:01 CLIENTE-> Bien, genial.
00:00:02 SERVIDOR-> Tener pastel-1.
00:00:02 SERVIDOR-> Espera el pastel-2.
00:00:03 CLIENTE-> ¿Qué es este sabor?
00:00:03 SERVIDOR-> ¿No te gusta?
00:00:04 SERVIDOR-> Tener pastel-2.
00:00:04 CLIENTE-> Me gusta.
00:00:05 CLIENTE-> Pero esto es suficiente.
Conexión Websocket (Imagen de PubNub.com)

Aplicaciones de muestra: aplicaciones de mensajería instantánea / chat, juegos, interfaces de administrador

Aunque se dice que los websockets son compatibles con todos los navegadores, también puede haber excepciones en los intermediarios:

  • Comportamientos inesperados en los intermediarios: si las conexiones de su websocket pasan por servidores proxy / cortafuegos, es posible que haya notado que tales conexiones fallan todo el tiempo. Utilice siempre Sockets web protegidos (WSS) para reducir drásticamente tales fallas. Este caso se explica muy bien aquí: cómo interactúan los Web Sockets HTML5 con los servidores proxy y también aquí: WebSockets, ¡se requiere precaución! Así que tenga cuidado y prepárese para manejarlos usando WSS y recurriendo a un protocolo de apoyo.
  • Intermediarios que no admiten websockets: si por alguna razón el protocolo WebSocket no está disponible, asegúrese de que su conexión recurra automáticamente a una opción de sondeo largo adecuada.

REST vs Websockets - Prueba de rendimiento

Si realiza una prueba de rendimiento para REST y Websockets, es posible que Websockets funcione mejor cuando hay cargas elevadas. Esto no significa necesariamente que REST sea ineficiente. Mi opinión personal es que comparar REST con Websockets es como comparar manzanas con naranjas. Estas dos características resuelven dos problemas diferentes y no se pueden comparar con una simple prueba de rendimiento como esta:

En el primer gráfico, la sobrecarga REST aumenta con respecto al número de mensajes porque es necesario iniciar y terminar muchas conexiones TCP y se deben enviar y recibir muchas cabeceras HTTP. En el segundo gráfico, el costo incremental de procesamiento de solicitud / respuesta para un punto final REST es mínimo y la mayor parte del tiempo se dedica al inicio / finalización de la conexión y al cumplimiento de la semántica HTTP. (Prueba de rendimiento y análisis de arungupta.me)

Sin embargo, ahora debe comprender que los Websockets son una excelente opción para manejar la transmisión de datos bidireccional de larga duración casi en tiempo real, mientras que REST es ideal para comunicaciones ocasionales. El uso de websockets es una inversión considerable, por lo tanto, es una exageración para las conexiones ocasionales.

Webhooks (para comunicación entre servidores)

Si desea obtener datos de su API sobre el cambio de datos, la encuesta debe ser la primera opción que se le ocurra. Pero cuando se trata de la comunicación entre servidores, las ineficiencias en las encuestas nos cuestan mucho (en promedio, se desperdicia el 98.5% de las encuestas).

Webhooks: forma sencilla de enviar datos entre servidores sin conexiones de sondeo de larga duración (Imagen de realtimeapi.io)

Los webhooks son los salvadores de este problema. Aquí recuerde que la comunicación generalmente ocurre entre servidores. Primero, el nodo emisor registra de antemano una URL de devolución de llamada en el nodo / s receptor. Cuando se produce un evento en el lado del remitente, el webhook se activa y envía un objeto de evento con nuevos datos como una solicitud HTTP POST a los nodos receptores utilizando URL de devolución de llamada registradas en cada uno de ellos.

Lo bueno es que la carga del servidor para los nodos emisor y receptor se puede reducir drásticamente con webhooks. Asegura una mejor experiencia de usuario mientras que sus desarrolladores pueden utilizar sus puntos finales de servicio para cosas significativas sin desperdiciar las encuestas.

Los webhooks se usan generalmente para enviar notificaciones y cambios de estado entre servidores cuando ocurre un evento. Por ejemplo, cuando un usuario se da de baja mediante un clic de botón en el correo electrónico, llega a un servidor y se produce el evento de cancelación de suscripción, este evento activa los webhooks correspondientes y notifica a todos los servidores / servicios que el usuario se ha dado de baja de su servicio (Imagen de kloudymail.com)
  • Aplicaciones de muestra: notificaciones cuando un nuevo usuario se registra o un usuario actual actualiza una configuración de perfil existente
  • Problema: a los desarrolladores les resulta difícil configurar webhooks y escalar servicios HTTP.

¿Qué usar para tu próxima API?

Qué técnica usar depende de lo que tenga más sentido en el contexto de su aplicación. Claro, puede usar algunos trucos para simular el comportamiento de una tecnología con la otra, pero por lo general es preferible usar la que mejor se adapte a su modelo de comunicación cuando se usa de forma oficial.

HTTP / 1.1 vs HTTP / 2: estos son protocolos de transporte. La capacidad de multiplexación en HTTP / 2 es excelente, pero aún no se admite en todas partes. En tales casos, asegúrese de retroceder desde HTTP / 2 y HTTP / 1.1 no creará ningún desorden en su aplicación. Para transferir datos, HTTP / 1.1 sigue siendo una gran opción.

API API RESTful: hasta ahora, las API RESTful están bien para aplicaciones web. Pero hay discusiones sobre explorar mejores formas. Un ejemplo es este concepto: "Reemplazar API RESTful con JSON-Pure". Me gusta la idea, de hecho, JSON es amigable para el desarrollador y puedes hacer maravillas con él. Pero ya sabes, estos son conceptos en desarrollo.

JSON vs XML: use JSON. Es la tendencia, y es muy conveniente tratar con ella también.

Sondeo HTTP: esto es antiguo, pero sigue siendo una excelente opción para tratar con API. Si sus datos cambian con frecuencia o en tiempo real, no use Short Polling, solo use websockets, la mejor tecnología en tiempo real. Utilice siempre encuestas largas y periódicas de manera adecuada (con los principios REST).

HTTP Streaming: esto es bueno para aplicaciones como noticias / feeds de redes sociales, stock / tableros de resultados, tweets, etc. Pero en la práctica, las personas usan websockets que HTTP Streaming.

HTTP / 2 Server Push es ideal para enviar recursos al cliente de una manera más administrada. Pero todos los intermediarios y navegadores no lo admitirán. Asegúrese de manejar con gracia tales retrocesos.

Los eventos enviados por el servidor son una tecnología bastante nueva que aún no es compatible con todos los principales navegadores, por lo que aún no es una opción para una aplicación web seria de nivel empresarial (Sí, estoy de acuerdo en que puede engañar a esta tecnología para que funcione)

WebSockets proporciona un protocolo más rico para realizar comunicación bidireccional, full-duplex. Tener un canal bidireccional es más atractivo para cosas como juegos, aplicaciones de mensajería, herramientas de colaboración, experiencias interactivas (inc. Micro interacciones) y para casos en los que necesita actualizaciones en tiempo real en ambas direcciones.

Los webhooks son diferentes de todas las tecnologías anteriores porque resuelve un problema muy específico. Si sus servidores necesitan comunicarse con frecuencia y / o bidireccionalmente, busque sockets web. Si sus servidores se comunican ocasionalmente, use llamadas REST. Si sus servidores necesitan comunicarse unidireccionalmente en un evento desencadenante, entonces busque webhooks. No utilice el sondeo para verificar los cambios en los datos o el estado, es un desperdicio.

¿Algun consejo?

️ Los representantes e intermediarios están locos. Se comerán tus paquetes o se agotarán inesperadamente. Tenga en cuenta eso y manejarlo con gracia.

️ Use protocolos de transporte seguros (HTTPS o WSS) para manejar su comunicación. Entonces, los intermediarios tendrán menos impacto en sus conexiones. Y es seguro, ya sabes.

️ Los desarrolladores adoran los webhooks. Pero asegúrese de aplicarlo correctamente.

️ Realmente no necesita adoptar la última tecnología siempre, especialmente cuando crea aplicaciones de nivel empresarial. Asegúrese de que toda la infraestructura sea compatible con la tecnología que utiliza. Y si la infraestructura no es compatible con su tecnología / arquitectura, asegúrese de recurrir a una tecnología que simplemente funcione en todas partes y que todo funcione correctamente con capacidades reducidas.

Referencias

  • REST vs WebSocket Comparación y puntos de referencia
  • ¿Sondeo corto versus sondeo largo para aplicaciones web en tiempo real?
  • Comenzando con Realtime