HTTP ha existido desde principios de los años 90s. Entre 2010 y 2015, la cantidad de datos transferidos para una sola página web se ha triplicado. El número de solicitudes necesarias para obtener todos esos datos también está en constante aumento.

HTTP a veces se usa en condiciones que son muy diferentes para lo que fue diseñado. Las opciones de diseño que tenían sentido en los 90s ahora se están convirtiendo en una carga tanto para el desarrollo como para el desempeño.

Algunas de las buenas prácticas actuales, como concatenar todo su JavaScript en un solo archivo, existe únicamente para solucionar deficiencias de HTTP/1. Bajo este panorama entra HTTP/2

HTTP/2 es compatible con versiones anteriores y resuelve los problemas más grandes que tiene HTTP/1. En esta publicación veremos las diferencias entre HTTP/1 y HTTP/2 y como estos cambios ayuda a mejorar sus aplicaciones.

Índice

1. Problema de HTTP/1: Head of Line Blocking
2. Problema de HTTP/1: Encabezado sin comprimir
3. Problema de HTTP/1: Seguridad
4. Mejoras de HTTP/2
5. Trabajando con HTTP/2

Problema de HTTP/1: Head of Line Blocking

Actualmente, el número promedio de solicitudes necesarias para mostrar correctamente un sitio web esta al rededor de 100 peticiones. Este número es alarmante.

Recuerde que HTTP/1 no funciona bien con muchas solicitudes. Afortunadamente HTTP/2 ha salido al rescate. Veremos algunos problemas de HTTP/2 y cómo HTTP/2 los esta resolviendo.

Una de las razones por las que se tienen tantas solicitudes es el bloqueo de cabeza de línea. Este inconveniente los explicamos en la publicación de HTTP/1 y vamos a repasarlos brevemente otra vez. El bloqueo de cabeza de línea es cuando una solicitud está bloqueando otras solicitudes impidiendo que se completen.

Un navegador abrirá a lo sumo seis conexiones al mismo servidor. Eso significa que máximo seis conexiones pueden estar abiertas simultáneamente.

Una vez abierta la conexión, se tendrá que esperar a que se envíe la solicitud y, a continuación, la respuesta que se devolverá. Este proceso es conocido como el round trip (viaje de ida y vuelta, cuando se traduce a español). El tiempo de un round trip puede durar entre 20 y 50 milisegundos en una buena conexión.

Tiempo de hacer cálculos: Digamos que un sitio web necesita enviar 100 solicitudes para cargarse completamente. Podemos manejar 6 solicitudes en paralelo, lo que significa que idealmente cada conexión deberá realizar 100/6 = 17 solicitudes.

Cada solicitud tiene un tiempo de round trip con un promedio aproximado de 35 milisegundos. Esto produce 17*35 = 595 milisegundos para atender la 100 solicitudes. Aproximadamente medio segun de… no hacer nada. Es escenario supone una buena conexión y la transferencia del archivo solicitado no lleva mucho tiempo.

Si el archivo que se transfiere es grande, entonces este número será mucho más grande. Este tiempo de round trip es un promedio. Si hay una conexión a Internet inestable o lenta, las cosas empeoran.

El bloque de cabeza de línea es un desastre para el buen rendimiento de carga de un sitio web. Con HTTP/2 no tenemos que preocuparnos por el bloqueo de cabeza de línea.

Problema de HTTP/1: Encabezado sin comprimir

Para reducir el tiempo que toma el envío de datos, muchos sitios web comprimen sus recursos con Gzip u otros algoritmos que funcionan en la web.

La compresión de los datos es excelente, pero los encabezados de solicitud y respuesta aún se envían sin comprimir. Cuando se piensa, este detalle no tienen mucho sentido. Los encabezados son texto plano y eso los hace altamente compresibles.

Adicionalmente, los encabezados se suelen repetir a través de la peticiones. El encabezado de host es siempre el mismo, las cookies son las mismas, y también lo son algunos otros encabezados.

En un trabajo de investigación de Google, se afirma que en promedio los encabezados ocupan unos 800 bytes.

Veamos los ahorros potenciales que podríamos tener si se comprimen los encabezados. Si un sitio web realiza 100 solicitudes, los encabezados ocuparan aproximadamente 80 kilobytes de datos y la mayoría de ellos serían redundantes.

Si pudiéramos comprimir los encabezados, ahorraríamos mucho espacio. Desafortunadamente, no podemos hacer esto con HTTP/1. Pero con HTTP/2 si es posible.

Problema de HTTP/1: Seguridad

Un aspecto completamente diferente que aborda HTTP/2 es la seguridad.

El comercio electrónico se ha convertido en la norma y también el manejo de datos confidenciales como tarjetas de créditos y contratos. Es justo llamarlo negligencia grave si los sitios web manejan este tipo de datos si TLS.

Es por eso que TLS es una parte requerida en la especificación para HTTP/2. Hay una versión sin cifrar de HTTP/2, pero todos los navegadores principales han optado por dejar de admitirla. Ya hemos hablado de TLS y te alegrará saber que nada ha cambiado al usar TLS con HTTP/2.

Ahora es tiempo de revisar como HTTP/2 soluciona los problemas mencionados anteriormente.

Mejoras de HTTP/2

¿Recuerda la legibilidad de lectura humana de las solicitudes y los encabezados de respuesta?. Pues, en HTTP/2 esta característica fue reestructurada y fue el primer paso para mejorar el rendimiento con HTTP/2. Fue agradable mientras duró, pero nadie se esta beneficiando realmente del enfoque de texto sin formato que adoptó HTTP/1. Por el contrario, se están desperdiciando bytes precioso al escribir cosas en forma de texto cuando un solo bit es suficiente.

No obstante, puede utilizar las herramientas de desarrollo de los navegadores para poder ver los encabezados en texto plano, incluso con HTTP/2.

El segundo gran problema que resuelve HTTP/2 es el bloque de cabeza de línea. Lo hace a través de una técnica llamada multiplexación.

Multiplex: Un sistema o señal que involucra la transmisión simultánea de varios mensaje a lo largo de un solo canal de comunicación.

La multiplexación es un termino elegante que significa combinar múltiples señales en una nueva señal única. Por tanto, en HTTP/2 ahora tenemos una conexión en lugar de seis. Esto parece un paso atrás, pero la conexión única se esta usando de manera diferente a como se haría en HTTP/1.

Lo que solía ser una conexión dedicada en HTTP/1ahora se denomina flujo y todas las secuencia comparten esa única conexión.

Estos flujos se dividen en cuadros y se multiplexan en esa única conexión. Cuando se bloquea un flujo, otro puede tomar la conexión y hacer un buen uso de lo que habría sido el tiempo de inactividad.

En consecuencia el bloqueo de cabeza de línea desaparece.

Por último, HTTP/2 se encarga de los encabezados que son grandes y no se comprimen. Con HTTP/2, los encabezados no solo se comprimen con la llave simétrica. Los ingenieros idearon una compresión HTTP/2 que se adapta a la estructura específica de los encabezados y la función de multiplexación.

Todas las transmisiones no solo comparten la conexión sino que también el compresor. Esto significa que nunca se debe enviar un encabezado dos veces, ya que el compresor reconoce que se envió antes y en su lugar envía una referencia.

Por ejemplo, las cookies son encabezados realmente largos por lo que es una enorme ventaja decir: “Inyecte el mismo encabezado de cookie del las solicitudes previas en esta conexión en lugar del valor real”. El algoritmo de compresión fue llamado HPACK y posee una documentación extensa que no será abordada en este documento.

Trabajando con HTTP/2

HTTP/2 trae muchos cambios. Pero, ¿Cómo hacemos la transición de HTTP/1 a este increíble mundo de HTTP/2?

Con HTTP/2 ya no ha bloqueos de cabeza de línea y sus peticiones comprimen los encabezados haciendo que las solicitudes sean más baratas. Por tanto, practicas com la concatenación de los archivos estáticos como JavaScript y CSS ya no son necesarias, Por otro lado pueden empeorar las cosas.

Supongamos el escenario de actualizar un archivo en caché. Si corrige un error de escritura en un archivo JavaScript, como una llave } que hace falta, forzaría a los usuarios a volver a descargar todo el contenido del archivo JavaScript concatenado, en lugar del fragmento que realmente cambió. Si cada archivo JavaScript estuviera separado, solo se trabajaría con el caché del archivo afectado.

Otra ventaja es que la nueva compresión de encabezados se vuelve más efectiva a medida que se envían más solicitudes. En cuanto más peticiones se envíen, más encabezado se podrán reutilizar. Eso significa que tener múltiples conexiones a diferentes servidores es realmente malo para su rendimiento.

Dicho esto, minimizar y comprimir sus archivos JavaScript, CSS e imágenes sigue siendo una buena idea. Un byte guardado es un byte guardado, y en los países dedicados al desarrollo eso significa dinero ahorrado.

Además, todos los consejos dados para el rendimiento de representación, como diferir un JavaScript o usar estilos de alineación, siguen siendo válidos. Invertir tiempo en la creación de un soporte para trabajar sin conexión con service workers también es recomendado.

Lo más importante, HTTP/2es compatible con versiones anteriores. Todos los servidores que hablan HTTP/2, podrán hablar HTTP/1. Un cliente que no puede hablar HTTP/2 simplemente retrocederá a HTTP/1 y seguirá trabajando como antes. Este tipo de clientes irán desapareciendo con el transcurso del tiempo.

Así que es momento de trabajar con HTTP/2. En el 2016 el 71% del tráfico web tenía soporte para HTTP/2. Entonces, es justo decir que es tiempo de optimizar su web para HTTP/2.

Recapitulación

En lo que a nosotros respecta, HTTP/2 funciona de la misma manera que lo hace HTTP/1. Lo que cambia es el rendimiento y las precauciones que debe tomar.

Debe comenzar a crear una aplicación web teniendo en cuenta HTTP/2, ya que varios navegadores que no admiten soportan están versión son cada vez menos.

Si esta ejecutando su propio servidor o tratando de averiguar dónde alojar su aplicación web, asegúrese de habilitar HTTP/2 allí también.

En el último capítulo de la serie, analizaremos más medidas de seguridad como el intercambio de recursos de origen cruzado y las secuencias de comandos entre sitios.