En versiones experimentales soporte del protocolo HTTP/3, que implementa una capa para que HTTP funcione sobre el protocolo QUIC. El protocolo QUIC fue añadido al navegador hace cinco años y desde entonces se utiliza para optimizar el funcionamiento de los servicios de Google. Sin embargo, la variante del QUIC implementada en Chrome tenía algunas diferencias respecto a la variante de IETF, pero ahora las implementaciones están sincronizadas.
HTTP/3 estandariza el uso de QUIC como transporte para HTTP/2. Para habilitar HTTP/3 y la variante de QUIC de de las especificaciones de IETF se requiere iniciar Chrome con las opciones «--enable-quic --quic-version=h3-23», tras lo cual, al abrir un sitio de prueba en el modo de inspección de red en las herramientas de desarrollo, la actividad por HTTP/3 se mostrará como «http/2+quic/99».
Recordemos que el protocolo (Conexiones Rápidas de UDP por Internet) ha sido desarrollado por Google desde 2013 como una alternativa a la combinación TCP+TLS para la web, resolviendo problemas con largos tiempos de establecimiento y negociación de conexiones en TCP y eliminando retrasos por la pérdida de paquetes durante la transmisión de datos. QUIC es una capa sobre el protocolo UDP, que soporta multiplexión de múltiples conexiones y proporciona métodos de cifrado equivalentes a TLS/SSL. Este protocolo ya está integrado en la infraestructura de servidores de Google, forma parte de Chrome, para su inclusión en Firefox y se utiliza activamente para atender solicitudes de clientes en los servidores de Google.
Principales QUIC:
- Alta seguridad, similar a TLS (de hecho, QUIC permite el uso de TLS sobre UDP);
- Control de integridad del flujo, previniendo la pérdida de paquetes;
- La posibilidad de establecer una conexión de inmediato (0-RTT, en aproximadamente el 75% de los casos los datos se pueden transmitir inmediatamente después del envío del paquete de establecimiento de conexión) y asegurar una latencia mínima entre el envío de la solicitud y la recepción de la respuesta (RTT, Round Trip Time);
- No utilizar el mismo número de secuencia para la retransmisión del paquete, lo que permite evitar ambigüedades al determinar los paquetes recibidos y eliminar los tiempos de espera;
- La pérdida de paquetes afecta solo a la entrega de la corriente asociada y no detiene la entrega de datos en las corrientes que se transmiten en paralelo a través de la conexión actual;
- Mecanismos de corrección de errores que minimizan la latencia debido a la retransmisión de paquetes perdidos. 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 un paquete perdido.
- Los límites criptográficos de los bloques están alineados con los límites de los paquetes de QUIC, lo que reduce el impacto de la pérdida de paquetes en la decodificación del contenido de paquetes subsiguientes;
- Ausencia de problemas de bloqueo de la cola TCP;
- Soporte para un identificador de conexión que permite reducir el tiempo de establecimiento de una nueva conexión para clientes móviles;
- Capacidad de conectar mecanismos avanzados de control de congestión de la conexión;
- Uso de técnicas de predicción de ancho de banda en cada dirección para asegurar la intensidad óptima de envío de paquetes, evitando caer en un estado de congestión donde se observa la pérdida de paquetes;
- Notable rendimiento y capacidad de transporte en comparación con TCP. Para servicios de video como YouTube, la aplicación de QUIC ha demostrado reducir las operaciones de repetición de búfer al ver videos en un 30%.
Fuente: opennet.ru
