Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué viene en HTTP / 3 QUIC?

 



HTTP / 3 es un protocolo robusto que ofrece muchas ventajas con pocos bloqueadores de adopción. La promesa de este protocolo, sin embargo, es solo eso: una promesa. Si bien el protocolo es, en teoría, una propuesta atractiva, todavía tiene bastante iteración por recorrer, lo que ha dejado a muchos programadores con una pregunta simple: cuál es el estado actual de HTTP / 3 y QUIC , y qué es explícitamente la oferta de protocolo en comparación con HTTP / 2 y HTTP / 1?

Hoy vamos a responder esas preguntas. Profundizaremos un poco en la historia del protocolo y averiguaremos cuál es el estado actual de HTTP / 3 a mediados de 2019.

¿Qué es HTTP / 3?

HTTP / 3 es la siguiente iteración de la familia de protocolos HTTP de uso frecuente. Está destinado a ser una especie de reemplazo, aunque al igual que con HTTP / 1, se espera cierto nivel de co-utilización en Internet en un futuro previsible debido a la naturaleza de la adopción de un nuevo protocolo. HTTP / 3 es muy similar a HTTP / 2, pero ofrece algunos avances y cambios significativos en el método de utilización subyacente. Su modo de implementación lo convierte en una bestia extraña; si bien lo ampliaremos en breve, HTTP / 2 es un desafío para actualizar de una manera que alivie sus fallas centrales, ya que se basa en TCP.

HTTP / 3, por otro lado, aunque sigue siendo funcional con TCP (por razones obvias), en realidad se basa en QUIC , un híbrido de Google / IETF que es fundamentalmente un protocolo de transporte desarrollado sobre UDP. Al estar construido sobre UDP, QUIC logra solucionar muchos de los problemas centrales que se encuentran en HTTP / 2 mientras opera bajo una nueva metodología de implementación. Esta adopción de UDP también permite aumentos significativos en la velocidad, sin mencionar la confiabilidad.

¿Por qué actualizar desde HTTP / 2?

Antes de discutir QUIC, deberíamos ver por qué uno querría actualizar HTTP / 2 en primer lugar. Debido a que HTTP / 2 es fundamentalmente una actualización de HTTP / 1, muchos de los problemas centrales encontrados en la primera implementación se han propagado. Estos problemas centrales se derivan principalmente de la realidad de TCP y de la forma en que se implementa TCP en las redes e Internet en general.

Quizás uno de los más notables de estos problemas es el hecho de que la conexión única de HTTP / 2 termina siendo un cuello de botella para los datos en un entorno de baja calidad de red: a medida que la calidad de la red se degrada y los paquetes se caen, la conexión única ralentiza todo el proceso. proceso hacia abajo, y no se pueden transferir datos adicionales durante este tiempo de retransmisión. HTTP / 1 originalmente ofrecía seis conexiones, que resolvieron gran parte de este problema, pero ambos protocolos fueron diseñados para una red y una época en la que las demandas actuales de latencia, velocidad y concurrencia aún no eran una realidad.

QUIC, y por lo tanto HTTP / 3, utiliza multiplexación para resolver este problema. Si se pierde un paquete, los flujos de conexión adicionales establecidos por HTTP / 3 permiten una funcionalidad independiente. En otras palabras, si un paquete falla, el resto de los flujos de conexión pueden continuar mientras ese flujo intenta repararse. En última instancia, esto reduce la congestión con bastante facilidad, sin mencionar que mejora la confiabilidad general del protocolo.

Un problema intrínseco con HTTP / 2 en realidad no es un problema de HTTP / 2 en sí mismo; más bien, es un problema de cómo los proveedores han elegido implementarlo. Debido a que este protocolo a menudo está integrado en enrutadores, firewalls y otros dispositivos de red (sin mencionar los middleboxes), cualquier desviación de HTTP / 2 a menudo se considera inválida o, lo que es peor, un ataque. Estos dispositivos están configurados para aceptar solo TCP o UDP entre los servidores contactados y sus usuarios dentro de una definición muy estricta y estrecha de cómo debería verse el tráfico esperado: cualquier desviación, como cuando un protocolo se ha actualizado, una nueva funcionalidad, se rechaza casi instantáneamente porque los dispositivos simplemente no quieren lidiar con ellos.

Este problema se conoce como osificación del protocolo y es un gran problema para resolver los problemas subyacentes de HTTP / 2. Las nuevas opciones de TCP están severamente limitadas o completamente bloqueadas, por lo que arreglar HTTP / 2 se vuelve menos un problema de "qué arreglamos" y más un problema de "cómo implementamos el arreglo".

¿Por qué QUIC?

Para resolver los problemas subyacentes de HTTP / 2, y más específicamente el problema de la osificación del protocolo, HTTP / 3 se basa en QUIC . QUIC, que alguna vez fue el acrónimo de "Conexiones de interacción rápida UDP", fue creado por Google como una solución a muchos de los problemas intrínsecos en la pila de protocolos de red actual. Es de baja latencia por diseño. El protocolo también ha sido diseñado para ser seguro, debido a que no existe una versión en texto claro del protocolo (ya que todo se enruta a través de TLS 1.3), es altamente seguro y no está sujeto a problemas de osificación. El tráfico TLS no es comprensible ni "escaneable" en términos de inspección por intermediarios estándar y, por lo tanto, el tráfico simplemente se enruta en lugar de detenerse.

QUIC también está diseñado para ser muy rápido. Al ofrecer apretones de manos 0-RTT y 1-RTT (Round Trip Time) contra los apretones de manos de 3 vías TCP, el proceso de transferencia de QUIC es muy rápido . QUIC es altamente confiable, debido a que admite los flujos adicionales mencionados anteriormente, lo que significa que la transmisión de datos está asegurada con mayor velocidad y precisión . Esta confiabilidad, combinada con la velocidad, ofrece un control de congestión superior y retransmisión de flujo. De hecho, el principal problema planteado contra HTTP / 3, el hecho de que utiliza UDP, un método de transporte relativamente poco confiable, es en gran parte negado por estas facetas.

Además, el hecho de que QUIC haya sido desarrollado para su implementación en el espacio de usuario también es notable. Esto significa que, a diferencia de los protocolos integrados en el sistema operativo o en el nivel de firmware, QUIC puede iterar con bastante rapidez y eficacia sin tener que lidiar con el afianzamiento de cada versión de protocolo. Este es un gran problema para un protocolo tan grande y, en muchos sentidos, debe considerarse una característica central por derecho propio.

Implementación e iteración

El historial de QUIC es esencialmente el historial de HTTP / 3 hasta cierto punto, por lo que para comprender el estado actual de implementación e iteración, debemos volver a los primeros días de QUIC. QUIC, como se señaló anteriormente, originalmente se llamaba "Conexiones de interacción rápida UDP". Fue diseñado por primera vez en Google por Jim Roskind y se implementó formalmente en 2012. En este punto, QUIC era estrictamente un producto de Google; se implementó en Chrome, Búsqueda de Google, YouTube y otros productos de Google, lo que brinda incrementos de velocidad excelentes y mejora al usuario experiencia en redes de baja calidad.

En junio de 2015 se desarrolló un borrador de QUIC IETF , proponiendo la integración de QUIC como estándar formalizado. En 2016, se aprobó el Grupo de Trabajo QUIC y la estandarización comenzó rápidamente. Para 2017, los ingenieros de QUIC en Google afirmaron que casi el 7% de todo el tráfico de Internet se enrutaba utilizando la variante de QUIC de Google, y con estos datos, la idea de convertirlo en un estándar global ganó peso.

Durante este tiempo, la implementación de Google QUIC esencialmente se fragmentó. Mientras Google continuaba con su propio desarrollo de QUIC, el grupo de trabajo decidió basar la implementación de QUIC estandarizada sobre TLS 1.3 en lugar de seguir utilizando el método de cifrado personalizado implementado por Google. El grupo de trabajo declaró que QUIC debería ser eventualmente más que HTTP sobre QUIC, lo que requería la separación del protocolo en QUIC como método de transporte y HTTP sobre QUIC como protocolo. La capa HTTP sobre QUIC luego se renombró como HTTP / 3 en noviembre de 2018, y es el enfoque principal actual del grupo de trabajo.

Cabe señalar que, a partir de ahora, nadie está ejecutando la variante IETF de QUIC; la única variante actual en uso es la versión de Google de QUIC, que Google está intentando activamente avanzar hacia el estándar IETF con cada iteración.

HTTP / 3 y API, IoT

Una de las ganancias más sustanciales detrás de HTTP / 3 es el impacto que tendrá en las API y el Internet de las cosas (IoT). Las API y el Internet de las cosas, la mayoría de las veces, operan en redes impredecibles. La calidad de la red, la calidad de los medios de transmisión y la seguridad general subyacente es muy dinámica, y la pérdida de paquetes y los errores de transmisión son los componentes principales detrás de la mayoría de las fallas de datos.

Con HTTP / 3, sin embargo, muchos de estos problemas, al menos aparentemente, se niegan. El hecho de que los problemas de velocidad derivados de la pérdida de paquetes se solucionen principalmente con la multiplexación y que los apretones de manos se hagan fundamentalmente más ligeros y eficientes conduce a un entorno en el que las API y los dispositivos de IoT tienen un perfil de transporte más estable, seguro y predecible. Desafortunadamente, estas ganancias no son del todo fáciles de implementar todavía. No hay funciones de API centrales en este momento como las hay para TCP, y como tal, aunque HTTP / 3 se puede habilitar, requiere algunas bibliotecas e implementaciones específicas. Esto, a su vez, conduce al bloqueo de la biblioteca y puede generar inflexibilidad en la lógica empresarial y de datos para las API que intentan implementar QUIC a través de HTTP / 3.

Conclusión

En concepto, HTTP / 3 es un protocolo excelente. Sin embargo, en la aplicación e implementación actuales, todavía tiene mucho que iterar. Si bien la promesa de QUIC y UDP, en general, ha brindado excelentes ejemplos del mundo real para Google, el estándar IETF aún no está al alcance. Si bien la adopción de QUIC tal como está bajo Google es ciertamente un argumento sólido, bloquear una API o aplicación en un protocolo específico con bibliotecas patentadas es riesgoso y debe sopesarse con los beneficios entregados para ver si es apropiado para el caso de uso dado.

¿Qué opinas de QUIC y HTTP / 3? ¿Es este el protocolo del futuro o es simplemente una mejora de la arquitectura en lugar de un nuevo estándar? Déjanos saber que piensas abajo.

Publicar un comentario

0 Comentarios