Tras años de arduo trabajo, el 6 de junio de 2022, el IETF (Internet Engineering Task Force) publicó oficialmente el RFC para HTTP/3, la tercera versión principal del Protocolo de Transferencia de Hipertexto (HTTP), y el RFC completo supera las 20.000 palabras y explica HTTP/3 con gran detalle.
Al mismo tiempo, el Grupo de Trabajo de Ingeniería de Internet (IETF) también ha actualizado los protocolos HTTP/1.1 y HTTP/2, de la siguiente manera:
HTTP/3 - Protocolo RFC 9114:El inicio de sesión del hipervínculo es visible.
HTTP/2 - Protocolo RFC 9113:El inicio de sesión del hipervínculo es visible.
HTTP/1.1 - Protocolo RFC 9112:El inicio de sesión del hipervínculo es visible.
QUIC
QUIC (Quick UDP Internet Connection) es único desarrollado por GoogleBasado en el UDPProtocolo de capa de transporte de Internet de baja latencia. En noviembre de 2016, el Grupo de Trabajo Internacional de Ingeniería de Internet (IETF) celebró la primera reunión del grupo de trabajo de QUIC, que recibió una amplia atención por parte de la industria. Esto también significa que QUIC ha iniciado su proceso de estandarización como protocolo de nueva generación de la capa de transporte.
HTTP/3
HTTP/3 es la tercera versión principal del Protocolo de Transferencia de Hipertexto para el intercambio de información en la World Wide Web, junto con HTTP/1.1 y HTTP/2. HTTP/3 siempre funciona en QUIC (no en TCP para TCP/IP, QUIC lo reemplaza), y ya está hecho (y está en el corazón de HTTP/3).
Existen muchas formas de implementar HTTP/3, como la quiche de Cloudflare, la rama experimental de Caddy y la rama oficial de QUIC de Nginx.
Como Openssl no soporta oficialmente el protocolo QUIC, la razón dada es que todavía están ocupados desarrollando Openssl-3.0 y las actualizaciones QUIC son demasiado rápidas, por lo que necesitamos usar una rama desarrollada por GoogleBoringssl。
BoringSSL es una bifurcación de OpenSSL creada por Google, pero el código que utiliza BoringSSL no garantiza la estabilidad de la API ni de la ABI, por lo que Google seguirá presentando correcciones de errores a OpenSSL y financiando la Core Infrastructure Initiative y la OpenBSD Foundation.
Antecedentes: Google utilizó más de 70 parches de OpenSSL, algunos de los cuales fueron aceptados en el repositorio principal de OpenSSL, pero la mayoría no. A medida que Android, Chrome y otros proyectos empiezan a requerir un subconjunto de estos parches, las cosas se complican cada vez más y requiere demasiado esfuerzo asegurarse de que todos los parches funcionen correctamente en diferentes bases de código. Así que decidieron crear una sucursal de OpenSSL.
Sitio web oficial de NGINX, Sitio de la sucursal de QUIC:El inicio de sesión del hipervínculo es visible.
Sitio de demostración de nginx-quic:El inicio de sesión del hipervínculo es visible.
¿Qué velocidad tiene HTTP/3?
Nueva York, EE. UU.: Aquí están los tiempos de respuesta HTTP/2 vs. HTTP/3 al solicitar desde tres sitios diferentes del centro de datos de Nueva York:
HTTP/3 in:
Los sitios pequeños son 200 milisegundos más rápidos
El sitio de contenido es 325 milisegundos más rápido
Las aplicaciones de una sola página son 300 milisegundos más rápidas
Minnesota está a 1000 millas (aproximadamente 160 kilómetros) de Nueva York; Esta longitud no es nada para una conexión de red. Sin embargo, es importante que HTTP/3 sea capaz de mejorar el rendimiento incluso a distancias relativamente cortas.
La prueba soporta QUIC-HTTP/3
Actualmente, hay dos sitios web que pueden usarse para comprobar si nuestro sitio soporta QUIC-HTTP/3, como sigue:
El inicio de sesión del hipervínculo es visible.
El inicio de sesión del hipervínculo es visible.
(Fin)
|
Publicado en 12/6/2022 14:07:25
|
|
|
|
Propietario|
Publicado en 12/6/2022 14:08:31
|
