Colección de citas famosas - Slogan de motivación - 12-19La diferencia entre HTTP 2.0 y HTTP1.1

12-19La diferencia entre HTTP 2.0 y HTTP1.1

Se reduce el tiempo de ida y vuelta de la red y se pueden realizar múltiples conexiones TCP simultáneamente. Si hay demasiadas conexiones TCP, aumentará la presión sobre el servidor (ataque D-DOS). Cada navegador tendrá sus propias ideas y considerará los sentimientos del servidor.

Uso de compresión de encabezados (diccionario)

La capa de marco binario resuelve el bloqueo del encabezado de la cola, porque los datos enviados por HTTP1.0 están ordenados y el cliente puede manejar devoluciones intercaladas Orden de datos .

La multiplexación permite que una conexión HTTP/2 inicie múltiples mensajes de solicitud-respuesta simultáneamente. Mire un ejemplo:

La página index.html se solicita por primera vez durante toda la visita y luego el navegador solicitará los archivos style.css y scripts.js. La imagen de la izquierda muestra los dos. Los archivos se cargan secuencialmente y la imagen de la derecha muestra Cargar dos archivos en paralelo.

Sabemos que la capa inferior de HTTP en realidad depende del protocolo TCP, por lo que la pregunta es, ¿cómo pueden responder dos solicitudes al mismo tiempo en la misma conexión?

En primer lugar, debes saber que una conexión TCP equivale a dos canalizaciones (una de servidor a cliente y otra de cliente a servidor). La transmisión de datos en la tubería utiliza la transmisión de código de bytes (TCP está orientada a bytes. La transmisión está ordenada y cada byte se transmite uno por uno).

Por ejemplo, si el cliente quiere enviar Hola y Mundo al servidor, solo puede enviar Hola primero y luego Mundo. Es imposible enviar estas dos palabras al mismo tiempo. De lo contrario, el servidor puede recibir HWeolrllod (tenga en cuenta que se envía alternativamente, pero no en orden). Esto hará que el servidor sea más tonto.

Siguiendo la pregunta anterior, ¿es posible enviar las palabras Hola y Mundo al mismo tiempo? Por supuesto que es posible. Puede dividir los datos en paquetes y etiquetar cada paquete. Cuando se envía, se ve así: 1 H2 w1e 2 o 1l 2r 2l 02d. Entonces, cuando se trata del servidor, el servidor diferencia entre las dos palabras según las etiquetas. El efecto de envío real es el siguiente:

Para lograr el efecto anterior, introducimos un nuevo concepto: marco binario.

La capa de trama binaria se encuentra entre la capa de aplicación (HTTP/2) y la capa de transporte (TCP o UDP). HTTP/2 no modifica el protocolo TCP, pero utiliza las características de TCP tanto como sea posible.

En la capa de marco binario, HTTP/2 dividirá toda la información transmitida en marcos y los codificará en formato binario. La información del encabezado se encapsulará en el marco del encabezado y el cuerpo de la solicitud correspondiente se encapsulará en. el marco de datos.

La clave para la optimización del rendimiento de HTTP no es un gran ancho de banda, sino una baja latencia. Las conexiones TCP se "ajustan" con el tiempo, limitando inicialmente la velocidad máxima de la conexión y aumentando la velocidad de transferencia con el tiempo si la transferencia de datos se realiza correctamente. Este ajuste se llama inicio lento de TCP. Debido a esto, las conexiones HTTP repentinas y de corta duración se vuelven muy ineficientes.

Al usar la misma conexión para todos los flujos de datos, HTTP/2 puede usar conexiones TCP de manera más eficiente, de modo que un ancho de banda elevado realmente pueda contribuir a mejorar el rendimiento de HTTP.

A través de las siguientes dos imágenes, podemos tener una comprensión más profunda de la reutilización:

HTTP/1

HTTP/2

Para resumir: tecnología de multiplexación: una única conexión con múltiples recursos reduce la presión del enlace en el servidor, ocupa menos memoria y aumenta el rendimiento de la conexión a medida que se reduce el tiempo de inicio lento de TCP y aumenta la velocidad de transmisión;

¿Por qué compresión? En HTTP/1, las solicitudes y respuestas HTTP constan de tres partes: línea de estado, encabezados de solicitud/respuesta y cuerpo del mensaje. En términos generales, el cuerpo del mensaje se comprime con gzip, o el archivo binario comprimido (como imágenes y audio) se transmite solo, pero la línea de estado y el encabezado se transmiten directamente como texto sin formato sin ninguna compresión.

A medida que las funciones web se vuelven cada vez más complejas, cada página genera más y más solicitudes, lo que hace que el encabezado consuma cada vez más tráfico, especialmente contenido que no cambia con frecuencia, como UserAgent. Las cookies son una completa desperdiciar.

Expliquemos el principio de compresión en un lenguaje sencillo. Se requiere compresión de encabezado entre navegadores y servidores que admitan HTTP/2.

Mantenga la misma tabla estática, incluidos nombres de títulos comunes y combinaciones particularmente comunes de nombres y valores de títulos;

Mantenga la misma tabla dinámica y podrá agregar contenido dinámicamente;

Admite codificación Huffman); basado en la tabla de códigos estáticos de Huffman;

El diccionario estático tiene dos funciones:

1) Para pares de valores clave principales coincidentes, como ": método: GET", se puede representar directamente con un carácter;

2) Para pares clave-valor que pueden coincidir con el nombre del encabezado, como "cookie: xxxxxxx", el nombre se puede representar mediante un personaje.

El diccionario estático en HTTP/2 es el siguiente (a continuación solo se intercepta una parte, la tabla completa está aquí):

Al mismo tiempo, tanto el navegador como el servidor Puede agregar una clave al par de valores del diccionario dinámico y luego este par clave-valor se puede representar con un carácter. Cabe señalar que los diccionarios dinámicos son sensibles al contexto y es necesario mantener un diccionario diferente para cada conexión HTTP/2. Durante el proceso de transmisión, se utilizan caracteres en lugar de pares clave-valor, lo que reduce en gran medida la cantidad de datos transmitidos.

El push del lado del servidor es un mecanismo para enviar datos antes de que el cliente los solicite. Las páginas web contemporáneas utilizan muchos recursos: HTML, hojas de estilo, scripts, imágenes, etc. Cada uno de estos recursos debe solicitarse explícitamente en http/1.x, lo que puede ser un proceso muy lento. El navegador comienza buscando HTML y luego gradualmente busca más recursos a medida que analiza y evalúa la página. Debido a que el servidor tiene que esperar cada solicitud del navegador, la red a menudo permanece inactiva y está infrautilizada.

Para mejorar la latencia, HTTP/2 introdujo el servidor push, que permite al servidor enviar recursos al navegador antes de que el navegador los solicite explícitamente. El servidor generalmente sabe que una página requiere muchos recursos adicionales y puede comenzar a enviar esos recursos cuando responde a la primera solicitud del navegador. Esto permite que el servidor aproveche al máximo la red potencialmente inactiva y mejore los tiempos de carga de la página.