En primer lugar, presentemos el protocolo de transmisión HTTP2.0. El protocolo de transmisión HTTP2.0 mejora en gran medida el rendimiento de HTTP1.x a través de la transmisión binaria, la multiplexación, la compresión de encabezados, la inserción del servidor y otras funciones. Sin embargo, debido a la transmisión HTTP2.0, el protocolo se implementa en base al protocolo TCP, y las características del propio TCP dan lugar a ciertos cuellos de botella y defectos.
①Bloqueo de cabeza de línea: múltiples solicitudes del protocolo de transmisión HTTP2.0 se llevan a cabo en una conexión TCP. Si se pierden paquetes durante la transmisión TCP, todo el TCP debe esperar a que se vuelva a transmitir, lo que hará que se bloqueen todas las solicitudes en esa conexión TCP.
Como puede verse en la figura anterior, el remitente envió un total de cuatro paquetes, de los cuales el paquete 3 se perdió en la capa de red. Aunque el kernel del receptor recibió el paquete 4, debido a que los datos en el kernel no eran continuos, la aplicación de la capa del receptor no se puede leer, y la capa de aplicación puede leer datos del kernel solo después de que se retransmite el paquete3.
② Retraso del protocolo de enlace TCP y TLS:
El protocolo TCP necesita establecer una conexión TCP a través de un protocolo de enlace de tres vías para garantizar la confiabilidad de la comunicación (1,5 RTT). El protocolo envía solicitudes y recibe respuestas (1 RTT) sobre TCP y TLS.
Esto significa que si queremos acceder a un servidor en los Estados Unidos, cuando el RTT es de aproximadamente 250 ms, entonces el tiempo que consume la solicitud HTTPS en este momento es de aproximadamente 1 segundo, que es relativamente alto.
③La migración de conexión requiere reconexión:
Una conexión TCP está determinada por la dirección IP de origen, el puerto de origen, la dirección IP de destino y el puerto de destino. Esto significa que si cambia el puerto o la dirección IP, las conexiones TCP y TLS deben volver a conectarse. Esto no es adecuado para escenarios donde los dispositivos cambian de red.
Los tres problemas anteriores son en realidad problemas inherentes al protocolo TCP. No importa cómo se diseñe la capa de aplicación HTTP/2, estos defectos no se pueden cambiar. Para resolver los problemas fundamentales, es necesario reemplazar el protocolo de capa de transporte TCP con UDP, mientras que HTTP 3.0 ¡Eso es lo que hace!
Sabemos que UDP es un protocolo de transporte simple y poco confiable. Por supuesto, HTTP 3.0 no solo reemplaza el protocolo de transporte de TCP a UDP, sino que también implementa un protocolo llamado QUIC en la capa de aplicación basado en UDP. Este protocolo tiene funciones de control de congestión y administración de conexiones similares a las de TCP, y puede transformar UDP en "confiable".
①Sin bloqueo de cabeza de línea:
El protocolo de transporte utilizado por QUIC es UDP, que no se preocupa por el orden de los paquetes o la pérdida de paquetes, pero QUIC garantizará la confiabilidad de los paquetes, cada paquete tendrá un identificador único, cuando se pierda un paquete de un flujo. Otros paquetes de este flujo, incluso si llegan a HTTP, no se leerán hasta que QUIC retransmita los datos perdidos.
A diferencia de HTTP/2, esto no afecta a otros flujos.
②La conexión se establece más rápido:
QUIC incluye internamente TLS_V1.3, que transporta la información en TLS en el marco de datos. Y QUIC no requiere un protocolo de enlace TCP+TLS como HTTP/2. Su proceso de apretón de manos solo requiere 1RTT. El propósito del apretón de manos es confirmar las identificaciones de conexión de ambas partes. Por lo tanto, QUIC puede completar el establecimiento de la conexión y la clave de cifrado al mismo tiempo con solo un RTT. Incluso cuando se conecta por segunda vez, el paquete de datos de la aplicación se puede enviar junto con la información del protocolo de enlace QUIC para lograr el efecto de 0-RTT.
③ Admite migración de conexión:
El protocolo QUIC no usa la dirección IP y el puerto para determinar la conexión, pero usa la identificación de la conexión para marcar ambos extremos de la comunicación. Incluso si la dirección IP cambia después de que cambia la red del dispositivo, siempre que se conserve la información de contexto (como el ID de conexión, la información TLS), la conexión original se puede reutilizar sin problemas.
HTTP 3.0 utiliza QUIC como protocolo de soporte subyacente, que combina la velocidad y el rendimiento de UDP con la seguridad y confiabilidad de TCP, resuelve algunas de las deficiencias introducidas en HTTP 2.0 y optimiza la experiencia de transmisión de Internet. ¡Creo que la era de HTTP 3.0 llegará en el futuro!