A construcións experimentais soporte para o protocolo HTTP/3, que implementa un complemento para permitir que HTTP funcione sobre o protocolo QUIC. O propio protocolo QUIC engadiuse ao navegador hai cinco anos e desde entón utilizouse para optimizar o traballo cos servizos de Google. Ao mesmo tempo, a versión QUIC de Google utilizada en Chrome difería nalgúns detalles da versión de IETF, pero agora as implementacións están sincronizadas.
HTTP/3 estandariza o uso de QUIC como transporte para HTTP/2. Para activar a opción HTTP/3 e QUIC de As especificacións do IETF requiren que Chrome se inicie coas opcións "-enable-quic -quic-version=h3-23" e despois ao abrir o sitio de proba No modo de inspección de rede nas ferramentas para desenvolvedores, a actividade HTTP/3 mostrarase como "http/2+quic/99".
Recordemos que o protocolo (Quick UDP Internet Connections) foi desenvolvido por Google desde 2013 como unha alternativa á combinación TCP+TLS para a Web, resolvendo problemas con longos tempos de configuración e negociación para conexións en TCP e eliminando os atrasos cando se perden paquetes 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. O protocolo en cuestión xa está integrado na infraestrutura do servidor de Google e forma parte de Chrome. para a súa inclusión en Firefox e úsase activamente para atender solicitudes de clientes nos servidores de Google.
O principal 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);
- Non utilizar o mesmo número de secuencia 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;
- Perceptible rendemento e 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