HTTP/3

HTTP/3 es el nuevo miembro de la familia de pro­to­co­los HTTP y ha llegado para sustituir a sus an­te­ce­so­res HTTP/1, HTTP/2 y HTTP-over-QUIC. Ac­tua­l­me­n­te, HTTP/3 se encuentra en proceso de de­sa­rro­llo, pero ya se ha im­ple­me­n­ta­do en los na­ve­ga­do­res Google Chrome, Microsoft Edge y Firefox, así como en Safari desde abril de 2020.

La tercera ge­ne­ra­ción del estándar HTTP nació ori­gi­na­l­me­n­te como HTTP-over-QUIC y, como protocolo ex­pe­ri­me­n­tal, se basaba en UDP. En un principio, se consideró HTTP-over-QUIC como un sustituto potencial de HTTP/2, pero desde enero de 2020 este proyecto avanza ofi­cia­l­me­n­te con el nombre de HTTP/3. Ahora solo queda esperar y ver con qué rapidez se impone el nuevo estándar. En cualquier caso, HTTP/3 promete reducir el tiempo de carga y aumentar la seguridad gracias a la tra­n­s­fe­re­n­cia de datos por UDP. No obstante, aunque el 80 % de los na­ve­ga­do­res es co­m­pa­ti­ble con HTTP/2 desde su pu­bli­ca­ción en 2015, su uso por parte de los pro­vee­do­res avanza le­n­ta­me­n­te, lo que nos hace pensar que HTTP/3 tampoco será recibido con los brazos abiertos.

En noviembre de 2018, tan solo tres años después de presentar el estándar HTTP/2, el Grupo de Trabajo de In­ge­nie­ría en Internet (IETF) publicó el nuevo estándar de protocolo de tra­n­s­fe­re­n­cia de hi­pe­r­te­x­to HTTP/3. Pero el IETF no descubrió nada nuevo con este nuevo protocolo: úni­ca­me­n­te supo reconocer los signos de nuestro tiempo y concibió un protocolo web que ofrecía una tra­n­s­fe­re­n­cia de datos más rápida, un in­cre­me­n­to en la seguridad y co­ne­xio­nes más eficaces. Ya en 2012, Google había de­sa­rro­lla­do el verdadero sucesor de HTTP/2, llamado QUIC (Quick UDP Internet Co­n­ne­c­tio­ns) y lo había im­ple­me­n­ta­do como HTTP-over-QUIC en variedad de productos.

En todo caso, el estándar HTTP/3 engloba las ventajas de los pro­to­co­los de tra­n­s­fe­re­n­cia ya exi­s­te­n­tes HTTP/2 y HTTP-over-QUIC, logrando una tra­n­s­fe­re­n­cia de datos más rápida y estable. Si todo avanza según lo previsto, HTTP/3, que sigue un pla­n­tea­mie­n­to basado en QUIC o UDP, su­s­ti­tui­rá a HTTP/2, basado en TCP.

Para co­m­pre­n­der la mecánica de HTTP/3, en primer lugar, es necesario entender cómo funcionan QUIC, UDP y HTTP/2, pues HTTP/3 es bá­si­ca­me­n­te una amalgama de estos co­m­po­ne­n­tes. Ya el mismo nombre HTTP-over-QUIC indica que la tra­n­s­fe­re­n­cia de datos no se hace por TCP, sino por UDP.

HTTP/2 utiliza TCP como el protocolo de tra­n­s­fe­re­n­cia más extendido en internet. TCP establece co­ne­xio­nes mediante ha­n­d­sha­kes de varias fases y tra­n­s­fie­re paquetes de datos cro­no­ló­gi­ca­me­n­te; además, solo prosigue una tra­n­s­fe­re­n­cia si un paquete ha sido tra­n­s­mi­ti­do con éxito. La seguridad de las tra­n­s­fe­re­n­cias se da a través de los llamados acks, es decir, co­n­fi­r­ma­cio­nes de petición y entrega y números de ve­ri­fi­ca­ción. Los datos tra­n­s­fe­ri­dos por TCP contienen un en­ca­be­za­do con pa­rá­me­tros que ayudan a los procesos del emisor a co­ne­c­tar­se con los procesos peer del receptor.

En lo que se refiere a la tra­n­s­fe­re­n­cia de datos completa, TCP es muy fiable. Sin embargo, no se puede decir lo mismo en lo referente a la co­n­ge­s­tión de datos y los tiempos de carga, pues, cuando se pierde un paquete de datos, todas las tra­n­s­fe­re­n­cias se detienen hasta que este llega. Con HTTP/2, la familia de pro­to­co­los de internet alcanzaba su límite, porque no era posible acelerar la tra­n­s­fe­re­n­cia de datos sin un protocolo nuevo.

Por lo tanto, Google tomó la ini­cia­ti­va y de­sa­rro­lló QUIC, su propio protocolo de tra­n­s­fe­re­n­cia. QUIC evita la co­n­ge­s­tión de carga por TCP re­cu­rrie­n­do a la tra­n­s­fe­re­n­cia por UDP, que se basa en da­ta­gra­mas y no requiere conexión. Al igual que TCP, UDP trabaja en la capa de tra­n­s­po­r­te, pero, por el contrario, renuncia a las co­n­fi­r­ma­cio­nes de emisor y receptor. Cada tra­n­s­fe­re­n­cia no tiene que esperar a la anterior y los trayectos de ida y vuelta entre cliente y servidor se acortan co­n­si­de­ra­ble­me­n­te. El IETF reconoció las ventajas de este nuevo protocolo y lo presentó en 2018 como HTTP-over-QUIC, la versión que sustituía a HTTP/2.

Bá­si­ca­me­n­te, el protocolo de tra­n­s­po­r­te HTTP se mantiene igual. Se sigue co­m­po­nie­n­do de un en­ca­be­za­do (header) y un cuerpo de mensaje (body), y emplea verbos, cookies y caché. La di­fe­re­n­cia reside en la forma de tra­n­s­fe­rir los datos y en la di­s­po­ni­bi­li­dad del cifrado integrado.

Para que el protocolo HTTP/2 fu­n­cio­na­ra mediante QUIC, era necesario modificar funciones concretas (mediante el ex­pe­ri­me­n­tal HTTP-over-QUIC), lo que llevó a crear HTTP/3.

La nueva función más im­po­r­ta­n­te de la tercera ge­ne­ra­ción de HTTP es la uti­li­za­ción exclusiva de URL de tipo HTTPS. Cualquier URL desfasado y dudoso se marca como no seguro y/o no se cifra. Uti­li­za­n­do QUIC y UDP, HTTP/3 sustituye el paso del cifrado TLS a nivel de TCP y utiliza un cifrado TLS 1.3 au­to­má­ti­ca­me­n­te. Por co­n­si­guie­n­te, HTTP/3 solo se puede aplicar si existe una co­di­fi­ca­ción.

Otras funciones nuevas son la conexión constante en caso de cambio de red durante la tra­n­s­fe­re­n­cia (por parte del cliente o del servidor), la notable reducción de los paquetes de datos gracias a que la tra­n­s­fe­re­n­cia de paquetes se hace pa­ra­le­la­me­n­te, y una forward error co­rre­c­tion, es decir, una co­rre­c­ción de errores que ya tiene lugar a nivel de QUIC.

Las ventajas de HTTP/3 son el aumento de la velocidad de tra­n­s­fe­re­n­cia, la reducción de los tiempos de carga y una conexión más estable. Como está basado en UDP, HTTP/3 suple los puntos débiles de TCP y aprovecha todas las ventajas de HTTP/2 y HTTP-over-QUIC.

Como HTTP/2 recurre a la mu­l­ti­ple­xa­ción, es decir, a la descarga si­mu­l­tá­nea de datos, esta segunda ge­ne­ra­ción de HTTP se ve afectada por el bloqueo head-of-line-blocking. Hablamos de embudos digitales que se encargan de in­te­rru­m­pir todas las tra­s­fe­re­n­cias cuando se pierde un paquete en una de ellas. En cambio, al emplear UDP, HTTP/3 no espera a que finalice la tra­n­s­fe­re­n­cia, sino que prosigue el proceso de carga.

HTTP/3 renuncia a los ha­n­d­sha­kes pre­li­mi­na­res que verifican la seguridad de la conexión. En vez de entregar so­li­ci­tu­des de seguridad a la capa TLS superior, el cifrado tiene lugar di­re­c­ta­me­n­te a través del protocolo de tra­n­s­fe­re­n­cia. HTTP/3 reduce la duración del es­ta­ble­ci­mie­n­to de la conexión de dos pasos a uno.

Para concluir una descarga con éxito, HTTP/3 no depende de di­re­c­cio­nes IP, sino que utiliza ide­n­ti­fi­ca­cio­nes de conexión in­di­vi­dua­les que hacen posible la descarga constante incluso en caso de cambio de red.

Sobre todo, para los usuarios de di­s­po­si­ti­vos móviles, HTTP/3 mejora la comodidad de na­ve­ga­ción gracias a una conexión más estable, flexible y rápida.

A co­n­ti­nua­ción, en­co­n­tra­rás un breve resumen de las di­fe­re­n­cias y si­mi­li­tu­des entre HTTP/2 y HTTP/3.

Di­fe­re­n­cias:

• HTTP/3 se basa, al contrario que HTTP/2, en UDP y no en TCP.
• Mediante el cifrado TLS 1.3 integrado, HTTP/3 renuncia a una petición de co­di­fi­ca­ción adicional (ha­n­d­sha­kes) a nivel de TLS y evita las so­li­ci­tu­des de seguridad in­ne­ce­sa­rias.
• Debido al cifrado TLS 1.3 integrado, HTTP/3 solo soporta co­ne­xio­nes cifradas, todo lo contrario que HTTP/2.

Si­mi­li­tu­des:

• Ambos pro­to­co­los utilizan la co­m­pre­sión del header. HTTP/3, por su parte, sustituye con Qpack la co­m­pre­sión HPAck re­la­cio­na­da con HTTP/2 en una lista ordenada de paquetes.
• Al igual que HTTP/2, HTTP/3 soporta no­ti­fi­ca­cio­nes push de servidor, es decir, el envío acelerado de datos CSS y Ja­va­S­cri­pt im­pre­s­ci­n­di­ble para que el navegador muestre una página.
• Ambos pro­to­co­los utilizan la mu­l­ti­ple­xa­ción de solicitud/respuesta, es decir, la tra­n­s­fe­re­n­cia paralela de datos pro­ce­de­n­tes de di­fe­re­n­tes fuentes.
• La prio­ri­za­ción de tra­n­s­fe­re­n­cias se encarga de que el contenido de las páginas se cargue con prioridad en ambos pro­to­co­los sin tener que esperar a que finalicen otras so­li­ci­tu­des.

Muchos críticos de HTTP/3 claman que ha pasado muy poco tiempo entre esta tercera versión y el protocolo HTTP/2, y co­n­si­de­ran UDP como un protocolo de red con carencias. Además, son los usuarios en especial quienes se be­ne­fi­cian de este nuevo protocolo HTTP, pero los pro­vee­do­res se enfrentan a ciertos retos a la hora de cambiar de TCP y TLS a UDP y QUIC.

Como el control de seguridad y el cifrado no se realizan mediante TLS, sino di­re­c­ta­me­n­te mediante UDP, y UDP tiene que enviar tantos paquetes en el menor tiempo posible, los pro­vee­do­res temen que no se pueda comprobar mi­nu­cio­sa­me­n­te el tráfico de datos debido a la ausencia de la au­te­n­ti­ca­ción TLS. Por lo tanto, los riesgos para la seguridad de las apli­ca­cio­nes y los datos es un punto muy criticado por los pro­vee­do­res de internet. Gracias a la re­gu­la­ción clara de solicitud-respuesta, TCP se co­n­si­de­ra­ba un protocolo fiable y orientado a la conexión. Como QUIC asume él mismo muchos pasos in­te­r­me­dios, en el aire queda la sospecha de si las opciones de control de los pro­vee­do­res se ven limitadas por HTTP/3, y si el riesgo de entrada de malware en el flujo de datos es mayor.

Debido a que la oferta cada vez mayor de archivos mu­l­ti­me­dia, como imágenes, vídeos y otros elementos de las redes sociales, exige más velocidad en las tra­n­s­fe­re­n­cias de datos, a los usuarios solo les queda esperar que la familia de pro­to­co­los de internet avance cuanto antes y que los pro­vee­do­res puedan seguir el ritmo de la evolución constante y cada vez más rápida de internet.