Espérase que Firefox lance soporte HTTP/3 a finais de maio.

Mozilla anunciou a súa intención de comezar a implementar HTTP/3 e QUIC co lanzamento de Firefox 88, previsto para o 19 de abril (orixinalmente estaba previsto que se lanzara o 20 de abril, pero a xulgar pola programación, retrasarase un día). Inicialmente, a compatibilidade con HTTP/3 só estará habilitada para unha pequena porcentaxe de usuarios e, salvo problemas inesperados, estará dispoñible para todos a finais de maio. Nas compilacións nocturnas e nas versións beta, HTTP/3 habilitouse por defecto a finais de marzo.

Lembremos que a implementación de HTTP/3 en Firefox baséase no proxecto neqo desenvolvido por Mozilla, que proporciona unha implementación de cliente e servidor para o protocolo QUIC. O código do compoñente para compatibilidade con HTTP/3 e QUIC está escrito en Rust. Para controlar se HTTP/3 está activado, about:config proporciona a opción "network.http.http3.enabled". Desde o software cliente, tamén se engadiu soporte experimental para HTTP/3 a Chrome e curl, e para os servidores está dispoñible en nginx, así como en forma de módulo nginx e servidor de proba de Cloudflare. No lado do sitio web, xa se ofrece soporte HTTP/3 nos servidores de Google e Facebook.

O protocolo HTTP/3 aínda está en fase de borrador de especificación e aínda non foi totalmente estandarizado polo IETF. HTTP/3 require soporte de cliente e servidor para a mesma versión do estándar borrador QUIC e HTTP/3, que se especifica na cabeceira Alt-Svc (Firefox admite borradores de especificacións 27 a 32).

HTTP/3 define o uso do protocolo QUIC como transporte para HTTP/2. O protocolo QUIC (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 os datos. Transferir. 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).

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

Engadir un comentario