Chrome comienza sus pruebas sobre el protocolo HTTP/3
Recientemente los desarrolladores que están detrás del navegador web Google Chrome, dieron a conocer la noticia de la adición del soporte para el protocolo HTTP/3 a las compilaciones experimentales de Chrome Canary, que implementa un complemento para habilitar HTTP sobre QUIC.
El protocolo QUIC en sí mismo se agregó al navegador hace cinco años y desde entonces se ha utilizado para optimizar el trabajo con los servicios de Google. Al mismo tiempo, la versión QUIC de Google utilizada en Chrome difería en algunos detalles de la versión de las especificaciones IETF, pero ahora las implementaciones están sincronizadas.
Google Chrome Canary just became the first (available) browser to integrate (very) experimental #QUIC and HTTP/3 support!
Add flags "–enable-quic –quic-version=h3-23" and you should see "http/2+quic/99" show up in the devtools, which is actually http3 in disguise! pic.twitter.com/5Fhui46h3x
— Robin Marx (@programmingart) September 19, 2019
Es importante resaltar que Google ha desarrollado QUIC (Quick UDP Internet Connections) desde 2013 como una alternativa al paquete TCP + TLS para la Web, que resuelve problemas con largos tiempos de configuración y negociación para las conexiones TCP y elimina los retrasos en la pérdida de paquetes durante la transferencia de datos.
QUIC es un complemento del protocolo UDP que admite la multiplexación de múltiples conexiones y proporciona métodos de cifrado equivalentes a TLS / SSL.
El protocolo en cuestión ya está integrado en la infraestructura del servidor de Google, es parte de Chrome, está planeado para su inclusión en Firefox y se utiliza activamente para atender las solicitudes de los clientes en los servidores de Google.
Dentro de las principales características de QUIC que se destacan son:
- Alta seguridad, similar a TLS (de hecho, QUIC proporciona la capacidad de usar TLS sobre UDP)
- Control de integridad de flujo que evita la pérdida de paquetes
- La capacidad de establecer una conexión al instante (0-RTT, en aproximadamente el 75% de los casos, los datos se pueden transmitir inmediatamente después de enviar el paquete de configuración de la conexión) y garantizar retrasos mínimos entre el envío de una solicitud y la recepción de una respuesta (RTT, Tiempo de ida y vuelta)
- No usar el mismo número de secuencia al retransmitir un paquete, lo que evita la ambigüedad en la determinación de los paquetes recibidos y elimina los tiempos de espera
- La pérdida de un paquete afecta la entrega de solo el flujo asociado con él y no detiene la entrega de datos en flujos transmitidos en paralelo a través de la conexión actual
- Herramientas de corrección de errores que minimizan los retrasos debido a la retransmisión de paquetes perdidos.
- El uso de códigos especiales de corrección de errores a nivel de paquete para reducir situaciones que requieren la retransmisión de datos de paquetes perdidos.
- Los límites criptográficos de los bloques están alineados con los límites de los paquetes QUIC, lo que reduce el efecto de la pérdida de paquetes en la decodificación del contenido de los siguientes paquetes
- No hay problemas con el bloqueo de la cola TCP
- Soporte para el identificador de conexión, que reduce el tiempo para establecer una reconexión para clientes móviles
- Capacidad para conectar mecanismos avanzados para controlar la sobrecarga de conexión
También se destaca que hace uso la técnica de predecir el ancho de banda en cada dirección para asegurar una intensidad óptima de envío de paquetes, evitando que llegue a un estado de congestión en el que se observa la pérdida de paquetes;
Así como también un rendimiento notable y ganancias de rendimiento sobre TCP. Para servicios de vídeo como YouTube, QUIC mostró una reducción del 30% en las operaciones de re-almacenamiento en búfer al mirar videos.
El protocolo HTTP/3 estandariza el uso de QUIC como transporte para HTTP/2. Para habilitar HTTP/3 y la versión QUIC de los 23 borradores de las especificaciones IETF, se debe ejecutar Chrome con las opciones “–enable-quic –quic-version = h3-23” y luego, cuando se abra el sitio de prueba quic.rocks:4433 en modo de inspección de red en las herramientas de desarrollador, la actividad HTTP / 3 se mostrará como “http / 2 + quic / 99”.
En comparación con un paquete perdido por conexiones HTTP en paralelo solamente se detendra 1 de las tantas conexiones, con lo cual QUIC puede soportar la entrega fuera de orden de modo que un paquete perdido tendrá menor impacto.
Si quieres conocer mas al respecto sobre esto, puedes consultar el siguiente enlace.