Programacion

Los Beneficios de las API REST con HTTP / 2

Compártelo

HTTP / 1.x frente a HTTP / 2
Primero, veamos algunas de las diferencias de alto nivel:

HTTP / 2 es binario, en lugar de textual
Los protocolos binarios son más eficientes de analizar, más compactos “sobre la marcha” y, lo que es más importante, son mucho menos propensos a errores en comparación con los protocolos de texto como HTTP / 1.x, porque a menudo tienen una serie de posibilidades para “ayudar”. “con cosas como manejo de espacio en blanco, mayúsculas, finales de línea, líneas en blanco, etc.

Por ejemplo, HTTP / 1.1 define cuatro formas diferentes de analizar un mensaje; en HTTP / 2, solo hay una ruta de código.

HTTP / 2 está completamente multiplexado, en lugar de ordenado y bloqueado
HTTP / 1.x tiene un problema llamado “bloqueo de cabecera de línea”, donde efectivamente solo una solicitud puede estar pendiente en una conexión a la vez.

HTTP / 1.1 intentó solucionar esto con pipelining, pero no resolvió completamente el problema (una respuesta grande o lenta puede bloquear a otros detrás de ella). Además, se ha descubierto que la canalización es muy difícil de implementar, porque muchos intermediarios y servidores no la procesan correctamente.

Esto obliga a los clientes a usar una cantidad de heurísticas (a menudo adivinar) para determinar qué solicitudes se deben establecer en qué conexión con el origen y cuándo; dado que es común que una página cargue 10 veces (o más) la cantidad de conexiones disponibles, esto puede afectar gravemente el rendimiento, lo que a menudo resulta en una “cascada” de solicitudes bloqueadas.

La multiplexación soluciona estos problemas al permitir que múltiples mensajes de solicitud y respuesta estén en vuelo al mismo tiempo; incluso es posible mezclar partes de un mensaje con otro en el cable.

Esto, a su vez, permite que un cliente use solo una conexión por origen para cargar una página.

HTTP / 2 puede usar una conexión para el paralelismo
Con HTTP / 1, los navegadores abren entre cuatro y ocho conexiones por origen. Dado que muchos sitios usan orígenes múltiples, esto podría significar que una única carga de página abre más de treinta conexiones.

Una aplicación que abre tantas conexiones simultáneamente rompe muchas de las suposiciones sobre las que se construyó TCP; dado que cada conexión iniciará una avalancha de datos en la respuesta, existe un riesgo real de que los buffers en la red intermedia se desborden, causando un evento de congestión y retransmite.

Además, el uso de tantas conexiones monopoliza injustamente los recursos de red, “robándolos” de otras aplicaciones de mejor comportamiento (por ejemplo, VoIP).

HTTP / 2 usa la compresión de encabezado para reducir gastos generales
Si supone que una página tiene alrededor de 80 activos (que es conservadora en la Web de hoy), y cada solicitud tiene 1400 bytes de encabezados (una vez más, no es raro, gracias a las cookies, Referer, etc.), se necesita al menos 7-8 viajes de ida y vuelta para sacar los encabezados “en el cable”. Eso no cuenta el tiempo de respuesta, eso es solo para sacarlos del cliente.

Esto se debe al mecanismo de inicio lento de TCP, que estimula los paquetes en las nuevas conexiones en función de la cantidad de paquetes reconocidos, lo que limita efectivamente el número de paquetes que se pueden enviar en los primeros viajes de ida y vuelta.

En comparación, incluso una compresión leve en los encabezados permite que esas solicitudes lleguen al cable en un viaje de ida y vuelta, tal vez incluso un paquete.

Esta sobrecarga es considerable, especialmente cuando se considera el impacto sobre los clientes móviles, que normalmente ven la latencia de ida y vuelta de varios cientos de milisegundos, incluso en buenas condiciones.

HTTP / 2 permite a los servidores “presionar” las respuestas de manera proactiva en cachés de clientes
Cuando un navegador solicita una página, el servidor envía el código HTML en la respuesta y luego necesita esperar a que el navegador analice el HTML y emita solicitudes para todos los activos incorporados antes de que pueda comenzar a enviar JavaScript, imágenes y CSS.

Server Push potencialmente permite que el servidor evite este viaje de ida y vuelta al “empujar” las respuestas que cree que el cliente necesitará en su caché.

Sin embargo, presionar respuestas no es “mágico”: si se usa incorrectamente, puede dañar el rendimiento. Por ahora, muchos todavía seguirán trabajando con Webhooks.

¿Cómo afecta esto a las API REST existentes creadas en HTTP / 1.1?

La semántica principal de HTTP se ha retenido en HTTP / 2. Esto significa que todavía tiene métodos HTTP como GET, POST, encabezados HTTP y URI para identificar recursos.

Lo que ha cambiado en HTTP / 2 con respecto a HTTP / 1.1 es la forma en que la semántica de HTTP (por ejemplo, “Quiero PUT resource / foo en host domain.com”) se transporta por cable. Esto significa que las API REST creadas en HTTP / 1.1 continuarán funcionando de forma transparente como antes, sin cambios en las aplicaciones.

El contenedor web que ejecuta las aplicaciones se ocupará de traducir el nuevo formato de cable en la semántica HTTP habitual en nombre de las aplicaciones, y la aplicación solo ve la semántica HTTP de nivel superior, sin importar si fue transportada a través de HTTP / 1.1 o HTTP. / 2 sobre el cable.

Debido a que el formato HTTP / 2 es más eficiente (en particular debido a multiplexación y compresión), las API REST sobre HTTP / 2 también se beneficiarán de esto.

La otra mejora importante presente en HTTP / 2, HTTP / 2 Push, apunta a la descarga eficiente de recursos correlacionados y, como probablemente no sea útil en la mayoría de casos de uso REST API, tal vez solo los Servicios de almacenamiento de objetos se puedan beneficiar de esto (como Amazon S3).

Un requisito típico de HTTP / 2 es desplegarse sobre TLS. Esto requiere que los implementadores pasen de HTTP a HTTPS, lo que significa que deben comprar certificados SSL de una autoridad de confianza, etc.

Beneficios de HTTP / 2 explicados

Entre las principales mejoras aportadas por HTTP / 2 se encuentran las transmisiones multiplexadas, la compresión de encabezados, la inserción del servidor y un protocolo binario en lugar de uno textual. Estos y otros cambios positivos permitieron obtener buenos resultados de carga de páginas web, incluidos los que tienen muchos archivos adicionales adjuntos (por ejemplo, estilos, secuencias de comandos, imágenes, fuentes, etc.).

HTTP / 2, la nueva versión del protocolo HTTP, también ofrece muchas características nuevas para la comunicación de servidor a servidor:

Comunicación bidireccional utilizando solicitudes de inserción

El “envío de servidor” de HTTP / 2 permite a un servidor enviar cosas proactivamente a la memoria caché del cliente para uso futuro.

Esto ayuda a evitar un viaje de ida y vuelta entre buscar HTML y hojas de estilo vinculadas y CSS, por ejemplo; el servidor puede comenzar a enviar estas cosas de inmediato, sin esperar a que el cliente las solicite.

También es útil para actualizar o invalidar proactivamente la caché del cliente, algo que las personas han pedido.

Por supuesto, en algunas situaciones, el cliente no quiere que se le agregue algo, generalmente porque ya tiene una copia, o sabe que no la usará. En estos casos, puede decir “no” con RST_STREAM.

Multiplexación dentro de una única conexión TCP

HTTP / 2 usa multiplexación para permitir que muchos mensajes se intercalen en una conexión al mismo tiempo, de modo que una respuesta grande (o una que requiera un tiempo prolongado para que el servidor lo piense) no bloquea otras.

Además, agrega compresión de encabezado, por lo que los encabezados de solicitud y respuesta normales no dominan el ancho de banda, incluso si lo que está solicitando es muy pequeño. Esa es una gran ganancia para los dispositivos móviles, donde obtener grandes encabezados de solicitud puede simplificar el tiempo de carga de una página con muchos recursos en varios viajes redondos.

Long Running Connections

HTTP / 2 está diseñado para usar menos conexiones, por lo que los servidores y las redes disfrutarán de menos carga. Esto es especialmente importante cuando la red se congestiona porque el uso de HTTP / 1 de múltiples conexiones para el paralelismo se suma al problema.

Por ejemplo, si su teléfono abre seis conexiones TCP a cada servidor para descargar los recursos de una página (recordando que la mayoría de las páginas usan múltiples servidores actualmente), puede sobrecargar fácilmente los buffers de la red móvil, lo que hace que descarten paquetes, retransmiten, y empeorando el problema

HTTP / 2 permite el uso de una sola conexión por host y alienta a los sitios a consolidar su contenido en un host siempre que sea posible.

Conexiones con estado

Si su cliente HTTP / 1 envía una solicitud y luego descubre que no necesita la respuesta, necesita cerrar la conexión si quiere ahorrar ancho de banda; no hay forma segura de recuperarlo.

HTTP / 2 agrega el marco RST_STREAM para permitir que un cliente cambie de opinión; si el navegador navega fuera de una página, o el usuario cancela una descarga, puede evitar tener que abrir una nueva conexión sin desperdiciar todo ese ancho de banda.

Una vez más, se trata de mejorar el rendimiento percibido y la compatibilidad con la red; al permitir que los clientes mantengan viva la conexión en este escenario común, se evitan los viajes de ida y vuelta y el consumo de recursos adicionales.

Pero…
Como siempre, no todo se trata de beneficios, hay algunas desventajas cuestionables:

Uso de Binary en lugar de texto
Esta también es una característica buena y no tan buena.

Una de las cosas buenas de HTTP / 1 es la capacidad de abrir telnet, escribir una solicitud (¡si el servidor no se detiene!) Y luego mirar la respuesta. Esto no será práctico en HTTP / 2 porque es un protocolo binario. ¿Por qué?

Considere cómo podemos almacenar short int 30000 (0x7530), tanto como texto como binario:

Como puede ver, en lugar de usar 5 bytes, estamos usando 2 bytes. Es más de 50% de reducción de tamaño.

Si bien los protocolos binarios tienen una sobrecarga menor para analizar, así como una huella de red ligeramente más ligera, la verdadera razón de este gran cambio es que los protocolos binarios son más simples y, por lo tanto, menos propensos a errores.

Esto se debe a que los protocolos textuales deben cubrir cuestiones como la delimitación de cadenas (contadas, ¿doble línea nueva?), Cómo manejar espacios en blanco, caracteres adicionales, etc. Esto lleva a una gran complejidad de implementación; en HTTP / 1, hay no menos de tres formas de saber cuándo termina un mensaje, junto con un complejo conjunto de reglas para determinar qué método está en uso.

La naturaleza textual de HTTP / 1 también ha sido la fuente de una serie de problemas de seguridad; Debido a que diferentes implementaciones toman decisiones diferentes sobre cómo analizar un mensaje, las partes malintencionadas pueden abrirse camino (por ejemplo, con el ataque de división de respuesta).

Una razón más para alejarse del texto es que cualquier cosa que se parezca remotamente a HTTP / 1 se procesará como HTTP / 1, y cuando agregue funciones fundamentales como la multiplexación (donde asociar contenido con el mensaje incorrecto puede tener resultados desastrosos), necesita para hacer una pausa limpia

Por supuesto, todo esto es un pequeño consuelo para la persona de operaciones pobres que solo quiere depurar el protocolo. Eso significa que necesitaremos nuevas herramientas y muchas de ellas para abordar esta deficiencia; para empezar, Wireshark ya tiene un complemento.

Más Encriptación

HTTP / 2 no requiere el uso de TLS (la forma estándar de SSL, la capa de cifrado de la Web), pero su mayor rendimiento facilita el uso del cifrado, ya que reduce el impacto sobre la velocidad de su sitio. Esto significa que probablemente necesite comprar certificados SSL, renovarlos, etc. No es una cantidad pequeña de dinero para gastar cuando trabaja con muchos microservicios que utilizan API REST.

De hecho, muchas personas creen que la única forma segura de implementar el nuevo protocolo en la Internet “abierta” es usar el cifrado; Firefox y Chrome han dicho que solo admitirán HTTP / 2 con TLS.

Ellos tienen dos razones para esto. Una es que la implementación de una nueva versión de HTTP en Internet es difícil, porque muchos “middleboxes”, como los servidores proxy y firewalls, suponen que HTTP / 1 no cambiará nunca, y pueden introducir interoperabilidad e incluso problemas de seguridad si Intenta interpretar una conexión HTTP / 2.

El otro es que la Web es un lugar cada vez más peligroso, y el uso de más cifrado es una forma de mitigar una serie de amenazas. Al utilizar HTTP / 2 como una zanahoria para que los sitios usen TLS, esperan que mejore la seguridad general de la web.

Resumen

El beneficio real para sus API REST existentes será que la mayoría de sus microservicios que probablemente estén basados ​​en REST estén trabajando en la comunicación de servidor a servidor. En la arquitectura actual de microservicios, cuando muchos microservicios hablan entre sí de muchas maneras pero aún usan REST, HTTP / 2 puede aumentar la velocidad de sus flujos de trabajo.

HTTP / 2 no define una API de JavaScript ni le ayuda a construir sus API de REST mucho más fácilmente. Por ahora, los clientes JavaScript que se ejecutan en un navegador web pueden hacer un uso limitado de las nuevas capacidades. Sin embargo, para la comunicación de servidor a servidor, HTTP / 2 ofrece muchas maneras de ir más allá de las API REST existentes.

Además, la desventaja de la compatibilidad de red de HTTP / 2 es que hace que el control de la congestión de TCP sea más notorio; ahora que los navegadores solo usan una conexión por host, la ventana inicial y las pérdidas de paquetes son mucho más evidentes.

Así como HTTP ha pasado por un período de escrutinio, experimentación y evolución, se está volviendo evidente que la atención de la comunidad se está volcando hacia TCP y su impacto en el rendimiento; ya hubo una discusión temprana sobre ajustes e incluso reemplazo de TCP en el IETF.

Compártelo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *