O Internet Engineering Task Force (IETF), responsable do desenvolvemento de protocolos e arquitectura de Internet, finalizou o RFC para o protocolo QUIC e publicou especificacións relacionadas baixo os identificadores RFC 8999 (propiedades do protocolo independente da versión), RFC 9000 (transporte). mediante UDP), RFC 9001 (cifrado TLS da canle de comunicación QUIC) e RFC 9002 (control de conxestión e detección de perda de paquetes durante a transmisión de datos).
Os RFC recibiron o status de "Proposta de Estándar", tras o cal comezará a traballar para darlle ao RFC o estado de borrador de estándar (Draft Standard), o que significa en realidade unha estabilización completa do protocolo e tendo en conta todos os comentarios realizados. O protocolo HTTP/3, que define o uso do protocolo QUIC como transporte para HTTP/2, aínda está en fase de borrador de especificación, pero pronto será finalmente estandarizado polo IETF.
Espérase que a estandarización de QUIC dea un impulso a unha maior adopción deste protocolo, así como ao desenvolvemento de extensións baseadas nel, como WebTransport (unha tecnoloxía para enviar e recibir datos entre un navegador e un servidor) e MASQUE. (unha tecnoloxía de proxy de conexión que amplía as capacidades de SOCKS e HTTP CONNECT e usa HTTPS sobre QUIC como transporte).
Lembremos que o protocolo QUIC (Quick UDP Internet Connections) foi desenvolvido por Google desde 2013 como alternativa á combinación TCP+TLS para a Rede, solucionando problemas cos longos tempos de configuración e negociación das conexións en TCP e eliminando atrasos cando Os paquetes pérdense durante a transferencia de datos. QUIC é unha extensión do protocolo UDP que admite a multiplexación de varias conexións e proporciona métodos de cifrado equivalentes a TLS/SSL. Durante o desenvolvemento do estándar IETF realizáronse cambios no protocolo, o que provocou a aparición de dúas ramas paralelas, unha para HTTP/3 e a segunda soportada por Google (Chrome admite ambas opcións e Firefox admite a versión IETF). .
Características principais de QUIC:
- Alta seguridade semellante a TLS (esencialmente QUIC ofrece a posibilidade de usar TLS sobre UDP);
- Control de integridade do fluxo, evitando a perda de paquetes;
- A capacidade de establecer unha conexión instantáneamente (0-RTT, en aproximadamente o 75% dos casos os datos pódense transmitir inmediatamente despois de enviar o paquete de configuración da conexión) e proporcionar atrasos mínimos entre o envío dunha solicitude e a recepción dunha resposta (RTT, Tempo de ida e volta);
- Usar un número de secuencia diferente ao retransmitir un paquete, o que evita a ambigüidade na identificación dos paquetes recibidos e elimina os tempos de espera;
- A perda dun paquete afecta só á entrega do fluxo asociado a el e non detén a entrega de datos en fluxos paralelos transmitidos a través da conexión actual;
- Funcións de corrección de erros que minimizan os atrasos debidos á retransmisión de paquetes perdidos. Uso de códigos especiais de corrección de erros a nivel de paquetes para reducir as situacións que requiren a retransmisión de paquetes de datos perdidos.
- Os límites dos bloques criptográficos están aliñados cos límites dos paquetes QUIC, o que reduce o impacto das perdas de paquetes na decodificación do contido dos paquetes posteriores;
- Non hai problemas co bloqueo da fila TCP;
- Soporte para o identificador de conexión, que reduce o tempo necesario para establecer unha reconexión para os clientes móbiles;
- Posibilidade de conectar mecanismos avanzados de control de conxestión da conexión;
- Utiliza técnicas de previsión de rendemento por dirección para garantir que os paquetes se envían a velocidades óptimas, evitando que se conxestionen e causen a perda de paquetes;
- Aumento significativo do rendemento e do rendemento en comparación co TCP. Para servizos de vídeo como YouTube, demostrouse que QUIC reduce nun 30 % as operacións de rebuffer ao ver vídeos.
Fonte: opennet.ru