A construcciones experimentales compatibilidad con el protocolo HTTP/3, que implementa un complemento para garantizar el funcionamiento de HTTP sobre el protocolo QUIC. El protocolo QUIC en sí 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 de QUIC de Google utilizada en Chrome difería en algunos detalles de la versión de IETF, pero las implementaciones ahora están sincronizadas.
HTTP/3 estandariza el uso de QUIC como transporte para HTTP/2. Para habilitar HTTP/3 y la opción QUIC desde Las especificaciones de IETF requieren que Chrome se inicie con las opciones "--enable-quic --quic-version=h3-23", después de lo cual al abrir un sitio de prueba en el modo de inspección de red, las herramientas de desarrollo mostrarán la actividad HTTP/3 como "http/2+quic/99".
Recuerde que el protocolo (Quick UDP Internet Connections) ha sido desarrollado por Google desde 2013 como una alternativa a TCP + TLS para la Web, resolviendo problemas con largos tiempos de configuración y negociación para conexiones en TCP y eliminando retrasos en caso de pérdida de paquetes durante la transferencia de datos. QUIC es un complemento del protocolo UDP que admite la multiplexación de varias 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, para su inclusión en Firefox y se usa activamente para atender las solicitudes de los clientes en los servidores de Google.
El principal RÁPIDO:
- Alta seguridad, similar a TLS (de hecho, QUIC brinda la capacidad de usar TLS sobre UDP);
- Control de integridad de transmisión para evitar la pérdida de paquetes;
- La capacidad de establecer una conexión instantáneamente (0-RTT, en aproximadamente el 75 % de los casos, los datos se pueden transmitir inmediatamente después de enviar un paquete de configuración de conexión) y garantizar demoras mínimas entre el envío de una solicitud y la recepción de una respuesta (RTT, tiempo de ida y vuelta) ;
- No utilice el mismo número de secuencia al retransmitir un paquete, lo que le permite evitar la ambigüedad al determinar los paquetes recibidos y deshacerse de los tiempos de espera;
- La pérdida de paquetes solo afecta la entrega del 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 debidos a la retransmisión de paquetes perdidos. Uso de códigos especiales de corrección de errores a nivel de paquete para reducir las situaciones que requieren la retransmisión de datos de paquetes perdidos.
- Los límites de los bloques criptográficos están alineados con los límites de los paquetes QUIC, lo que reduce el impacto 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 de ID de conexión para reducir el tiempo de reconexión para clientes móviles;
- Posibilidad de conectar mecanismos avanzados para control de sobrecarga de conexión;
- Usar técnicas de predicción de ancho de banda en cada dirección para garantizar la intensidad óptima de envío de paquetes, evitando caer en un estado de congestión, en el que hay una pérdida de paquetes;
- Perceptible rendimiento y rendimiento en comparación con TCP. Para servicios de video como YouTube, se ha demostrado que QUIC reduce las operaciones de almacenamiento en búfer de video en un 30 %.
Fuente: opennet.ru