Google anunciĆ³ hace pocos dĆas que ya ha comenzado con el despliegue de HTTP/3 e IETF QUIC en Chrome y en el anuncio da a conocer que espera que esta actualizaciĆ³n traiga algunas mejoras de rendimiento adicionales, especialmente con soporte para QUIC.
QUIC es un nuevo protocolo de transporte de red que combina las caracterĆsticas de TCP, TLS y mĆ”s. HTTP/3 es la Ćŗltima versiĆ³n de HTTP, el protocolo que transporta la gran mayorĆa del trĆ”fico web. HTTP / 3 solo funciona en QUIC.
El Grupo de trabajo de ingenierĆa de Internet, o IETF, introdujo HTTP/2 en 2015 y una de las grandes mejoras que realizĆ³ es la compatibilidad con la multiplexaciĆ³n.
Sin embargo, usĆ³ TCP como protocolo de transporte y los mecanismos de recuperaciĆ³n de pĆ©rdidas en TCP, por lo que los paquetes perdidos aĆŗn pueden causar un retraso en todas las transacciones activas.
Al adoptar QUIC, HTTP/3 puede mejorar aĆŗn mĆ”s el proceso de transferencia, ya que los paquetes perdidos en este caso solo afectan las transacciones directamente afectadas.
De hecho, QUIC fue desarrollado originalmente por Google y anunciado por primera vez en 2013. Desde entonces, el protocolo ha alcanzado la mayorĆa de edad y actualmente es responsable de transportar un tercio del trĆ”fico de Google.
Luego, en 2015, el desarrollo de QUIC pasĆ³ a manos del IETF, el organismo de estĆ”ndares responsable del mantenimiento de los protocolos de Internet. El IETF ha mejorado QUIC con varios cambios. Hasta la fecha, existen dos protocolos similares, pero diferentes, que son: Google QUIC e IETF QUIC.
Google ha anunciado que siempre ha utilizado su propia versiĆ³n de QUIC, pero que su equipo QUIC tambiĆ©n estĆ” involucrado en la implementaciĆ³n de la versiĆ³n propiedad de la IEFT. Ā«Hemos realizado esfuerzos significativos para hacer evolucionar Google QUIC durante los Ćŗltimos cinco aƱos para mantenernos al dĆa con los cambios realizados por el IETF, y la Ćŗltima versiĆ³n actual de Google QUIC tiene muchas similitudes con IETF QUICĀ», se lee en la publicaciĆ³n del blog de Google, ademĆ”s, aclarĆ³ que aĆŗn faltaban algunas cosas.
Como ejemplo, hasta ahora la mayorĆa de los usuarios de Chrome no pueden comunicarse con los servidores IETF QUIC sin habilitar algunas opciones de lĆnea de comandos. Asimismo, Google agregĆ³ que ahora ha descubierto que IETF QUIC supera significativamente a HTTP en comparaciĆ³n con TLS 1.3 en comparaciĆ³n con TCP.
En particular, la compaƱĆa dijo que la latencia del motor de bĆŗsqueda de Google se reduce en mĆ”s de un 2%. El tiempo de almacenamiento en bĆŗfer de YouTube se ha reducido en mĆ”s del 9%. AdemĆ”s, el rendimiento del cliente ha aumentado en mĆ”s del 3% en las computadoras de escritorio.
En los telĆ©fonos mĆ³viles, el rendimiento de los clientes aumentĆ³ en mĆ”s del 7%. Estas y otras razones estĆ”n detrĆ”s del cambio de Chrome a la versiĆ³n QUIC del IETF. āNos complace anunciar que Chrome estĆ” implementando soporte para IETF QUIC (especĆficamente, la versiĆ³n piloto h3-29).
Hoy en dĆa, alrededor del 25% de los usuarios de la versiĆ³n estable de Chrome estĆ”n usando h3-29, y planeamos aumentar esta cifra en las prĆ³ximas semanas al continuar monitoreando los datos de rendimientoā, dijo la compaƱĆa en su entrada en el blog.
āChrome admitirĆ” activamente tanto el IETF QUIC h3-29 como la versiĆ³n Google QUIC (Q050) para dar tiempo a los servidores que admiten Q050 para actualizar a IETF QUICā, agregĆ³. Chrome m85 aĆŗn no es compatible con IETF QUIC 0-RTT y Google espera que este rendimiento sea aĆŗn mejor cuando lance la compatibilidad con IETF QUIC 0-RTT en los prĆ³ximos meses. AdemĆ”s, dado que las versiones 30 y 31 de IETF QUIC no contienen cambios que puedan romper la compatibilidad, la compaƱĆa no planea cambiar el identificador Ā«over-the-wireĀ».
Esto significa que continuarĆ” rastreando los cambios en la versiĆ³n IETF, pero los implementarĆ” como h3-29 / 0xff00001d.
Por lo tanto, recomienda que los servidores continĆŗen admitiendo h3-29 hasta que se completen las RFC finales si desean interoperar con Chrome. Sin embargo, si el IETF realiza cambios que rompan la compatibilidad en un proyecto futuro, Chrome revertirĆ” esa decisiĆ³n.
Fuente: https://blog.chromium.org