El Comité IETF (Internet Engineering Task Force), encargado del desarrollo de protocolos y arquitectura de internet, ha finalizado la creación del RFC para el protocolo QUIC y ha publicado las especificaciones relacionadas bajo los identificadores RFC 8999 (propiedades del protocolo independientes de la versión), RFC 9000 (transporte sobre UDP), RFC 9001 (cifrado TLS del canal de comunicación QUIC) y RFC 9002 (gestión de sobrecarga y determinación de pérdida de paquetes durante la transmisión de datos).
Los RFC han obtenido el estatus de 'Propuesta de estándar', tras lo cual comenzará el trabajo para otorgar a los RFC el estatus de estándar borrador (Draft Standard), lo que significa la estabilización completa del protocolo y la consideración de todos los comentarios emitidos. El protocolo HTTP/3, que define el uso del protocolo QUIC como transporte para HTTP/2, se encuentra actualmente en la etapa de especificación borrador, pero también será estandarizado en breve por el IETF.
Se espera que la estandarización de QUIC impulse una adopción más amplia de este protocolo y el desarrollo de extensiones basadas en él, como WebTransport (una tecnología para el envío y recepción de datos entre el navegador y el servidor) y MASQUE (una tecnología de proxy de conexiones que amplía las capacidades de SOCKS y HTTP CONNECT, utilizando HTTPS sobre QUIC como transporte).
Recordemos que el protocolo QUIC (Conexiones Rápidas por UDP para Internet) ha sido desarrollado por Google desde 2013 como una alternativa a la combinación TCP+TLS para la Web, resolviendo problemas con el largo tiempo de establecimiento y negociación de conexiones en TCP y eliminando latencias debido a pérdidas 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. Durante el proceso de desarrollo por parte del IETF, se realizaron cambios en el protocolo que dieron lugar a la existencia de dos ramas paralelas, una para HTTP/3 y la otra mantenida por Google (Chrome soporta ambas variantes, mientras que Firefox soporta la variante del IETF).
Características principales de 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;
- Posibilidad de establecer conexión de inmediato (0-RTT, en aproximadamente el 75% de los casos, los datos se pueden transmitir inmediatamente después de enviar el paquete de establecimiento de conexión) y asegurar mínimas latencias entre el envío de la solicitud y la recepción de la respuesta (RTT, Round Trip Time);
- El uso de un número de secuencia diferente al retransmitir un 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 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;
- 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;
- Incremento significativo en el rendimiento y la capacidad de transmisión en comparación con TCP. Para servicios de video como YouTube, la implementación de QUIC ha demostrado reducir las operaciones de rebuffering al ver videos en un 30%.
Fuente: opennet.ru
