Funcionalidad HTTP2
HTTPS ha llegado al "extremo" en términos de seguridad al introducir SSL/TLS, pero es muy pobre en términos de mejora del rendimiento. Solo optimiza el enlace de cifrado de protocolo de enlace y no propone un mejor plan de mejora para la transmisión de datos general. Solo puede confiar en la tecnología "hacia atrás" de "conexión". Google tomó la iniciativa en la invención del protocolo SPDY y lo aplicó a su propio navegador Chrome, dando el "primer disparo" de optimización del rendimiento HTTP. Posteriormente, la Organización de Normalización de Internet IETF integró las ideas de otros partidos basándose en SPDY. Finalmente lanzó el sucesor de HTTP/1, ¿cuál es el maestro actual? ¿Rendimiento "HTTP/2"? Saltar.
Dado que HTTPS es tan bueno en seguridad, el único objetivo de HTTP/2 es mejorar el rendimiento. Sin embargo, no solo conlleva muchas expectativas, sino que también carga con el enorme bagaje histórico de HTTP/1. Por lo tanto, las modificaciones al protocolo deben ser cautelosas y la compatibilidad es la consideración principal, de lo contrario destruirá innumerables activos existentes en Internet. . Debido a que se debe mantener la compatibilidad funcional, HTTP/2 descompone HTTP en semántica y sintaxis. La capa semántica permanece sin cambios y es completamente consistente con HTTP/1 (es decir, RFC7231). Por ejemplo, conceptos como métodos de solicitud, URI, códigos de estado, campos de encabezado, etc. Al permanecer sin cambios y eliminar el costo de reaprendizaje, las aplicaciones de capa superior basadas en HTTP se pueden convertir sin problemas a HTTP/2 sin ninguna modificación. En particular, a diferencia de https, HTTP/2 no introduce un nuevo nombre de protocolo en el URI, pero aún usa "HTTP" para representar el protocolo de texto sin formato y "httpS" para representar el protocolo cifrado.
Primero, HTTP/2 realiza una "gran operación" en el encabezado del mensaje. En HTTP/1, el campo de encabezado "Codificación de contenido" se puede utilizar para especificar el método de codificación del cuerpo, como la compresión gzip para ahorrar ancho de banda, pero ¿qué pasa con el otro componente del mensaje? El encabezado se ignora, no existe ningún método de optimización para ello.
Debido a que el encabezado del mensaje generalmente contiene muchos campos de encabezado fijos, como "Agente de usuario", "Cookie", "Aceptar", "Servidor", hasta cientos o incluso miles de bytes, pero el cuerpo es a menudo solo tiene docenas de bytes (como la solicitud GET, la respuesta 204/301/304), lo que lo convierte en un "hijo cabezón" absoluto. Es más, hay muchos valores de campo duplicados en miles de mensajes de respuesta a solicitudes, lo cual es un gran desperdicio. La "respuesta de efecto de cola" hará que estos datos altamente redundantes consuman mucho ancho de banda, por lo que HTTP/2 considera la "compresión de encabezado" como un foco de mejora del rendimiento. Por supuesto, puede pensar en un método de optimización o "compresión".
Sin embargo, HTTP/2 no utiliza el algoritmo de compresión tradicional, sino que desarrolló uno especial. Basado en el algoritmo "HPACK", se establecen "diccionarios" en ambos lados del cliente y del servidor, y las cadenas repetidas se representan mediante números de índice. La codificación Huffman también se utiliza para comprimir números enteros y cadenas, y puede alcanzar altas tasas de compresión del 50% al 90%.
Puede que estés acostumbrado a mensajes de texto plano en HTTP/1. Su ventaja es que es "claro de un vistazo" y es muy conveniente empezar a depurar con la herramienta más sencilla. Pero HTTP/2 no se "comprometió" en este sentido y decidió cambiar el status quo que había durado más de diez años sin necesidad de mirarlo a simple vista. Código ASCII, pero "cercano" al protocolo TCP/IP subyacente, utilizando formato binario en todos los ámbitos. Aunque esto no es amigable para los humanos, facilita enormemente el análisis por computadora. Cuando se utiliza texto sin formato, es probable que se produzcan ambigüedades, como mayúsculas, caracteres de espacio, ¿reverso? Saltos de línea, más palabras, menos palabras, etc. , el programa debe utilizar una máquina de estado compleja durante el procesamiento, lo cual es ineficiente y problemático.
Mueve algunas características del protocolo TCP a la capa de aplicación, descompone el mensaje original de "encabezado + cuerpo" en varios "marcos" binarios pequeños y utiliza el marco "encabezado" para almacenar los datos del encabezado. El marco "Datos" almacena datos de la entidad. Este enfoque es algo así como la codificación de bloques "fragmentados". También existe la idea de "dividir todo en partes", pero después de encuadrar los datos HTTP/2, la estructura del mensaje "encabezado + cuerpo" desaparece por completo y el protocolo solo ve los "fragmentos" uno por uno.
¿Cómo se deben ensamblar las “piezas” del mensaje una vez llegan a su destino? HTTP/2 define un concepto de "transmisión" para este propósito, que es una secuencia de transmisión bidireccional de tramas binarias. A las tramas del mismo mensaje se les asigna una ID de transmisión única.
Puede considerarlo como un "flujo de datos" virtual en el que fluye una serie de marcos de datos secuenciales que se ensamblan para convertirse en mensajes de solicitud y mensajes de respuesta en HTTP/1.
Debido a que "stream" es virtual y en realidad no existe, HTTP/2 puede usar "stream" para enviar múltiples mensajes "fragmentados" simultáneamente en una conexión TCP, lo que a menudo se dice "Reutilizar". Maneje múltiples comunicaciones de ida y vuelta multiplexando una sola conexión. En el nivel de "flujo", los mensajes son secuencias ordenadas de "tramas", mientras que en el nivel de "conexión", los mensajes son "tramas" enviadas y recibidas fuera de orden. No existe una relación secuencial entre múltiples solicitudes/respuestas y no es necesario hacer cola. Por lo tanto, el problema del "bloqueo del encabezado de la cola" ya no ocurrirá, lo que reduce la latencia y mejora en gran medida la utilización de la conexión.
Para utilizar mejor la conexión y aumentar el rendimiento, HTTP/2 también agrega algunos marcos de control para administrar "flujos" virtuales e implementar control de flujo y prioridad, que también es muy similar al protocolo TCP.
HTTP/2 también ha cambiado hasta cierto punto el modelo de trabajo tradicional "solicitud-respuesta". El servidor también puede crear una nueva "corriente" para enviar mensajes de manera proactiva a los clientes, en lugar de ser completamente pasivo al responder a las solicitudes. Por ejemplo, cuando el navegador solicita HTML por primera vez, envía los documentos JS y CSS que pueden usarse al cliente con anticipación para reducir los retrasos de espera. Este es el llamado "empuje del servidor" (también llamado envío de caché).
Por compatibilidad, HTTP/2 continúa la característica de "texto sin formato" de HTTP/1. Los datos se pueden transmitir en texto sin formato como antes y la comunicación cifrada no es obligatoria, pero el formato sigue siendo binario, pero no es necesario descifrarlo. Sin embargo, dado que HTTPS es la tendencia general, los principales navegadores como Chrome y Firefox han anunciado públicamente que solo admiten HTTP/2 cifrado, por lo que "de hecho" HTTP/2 está cifrado. En otras palabras, ¿qué está generalmente disponible en línea? Todo HTTP/2 utiliza el nombre del protocolo "https" y se ejecuta sobre TLS. Para distinguir entre versiones cifradas y de texto sin formato, el protocolo HTTP/2 define dos identificadores de cadena: "h2" para HTTP/2 cifrado, "h2c" para HTTP/2 con texto sin formato y la letra adicional "C" para "texto sin formato".
Se descubrieron muchas debilidades de SSL/TLS cuando se formuló el estándar HTTP/2 (2015), pero el nuevo TLS1.3 aún no se ha lanzado, por lo que la versión cifrada de HTTP/2 no está disponible. seguro en términos de seguridad Se ha reforzado, requiriendo que el protocolo de comunicación inferior sea TLS1.2 o superior, admitiendo seguridad avanzada y SNI, y que contenga cientos de conjuntos de cifrado débiles. Por ejemplo, DES, RC4, CBC y SHA-1 no se pueden usar en HTTP/2, lo que equivale a usar "TLS1.25" en la capa inferior.