lunes, 23 de febrero de 2015

Las cosas chulas de HTTP/2

Ya tenemos el draft 17 del protocolo y la cosa está bastante consolidada. También hay un buen puñado de implementaciones. Pero, ¿que podemos esperar a grandes rasgos de este nuevo protocolo por mucho que cambien cosas en los sucesivos draft? Os voy a contar, así a salto de mata, con lo que os vais a encontrar.

La API no cambia

HTTP/2 no introduce cambios en las cabeceras, códigos de estado, verbos, etc. Teóricamente, podrías sustituir la librería HTTP/1 que usas actualmente por una HTTP/2 y no deberías tener que cambiar ni una sola línea de código.
Esto no quiere decir que no existan mejoras en la API que agreguen nuevas capacidades y mejoras al protocolo, pero éstas son de uso opcional y, aunque recomendadas, su aplicación se puede posponer.

Request ligeros y baratos

Con HTTP/1, los request son caros y pesados. Tanto es así, que han surgido una gran variedad de técnicas para reducirlos, como puede ser el inlining , el spriting o el batching.
HTTP/2 reduce en gran medida esa pesadez usando multiplexación de varios mensajes HTTP a través de una sola conexión. Esto permite que utilizando una sola conexión abierta se puedan enviar varios mensajes al servidor y además éstas no se bloquean entre ellas.
HTTP/2 también comprime las cabeceras, por lo que nos ahorramos un montón de ancho de banda. Esto es genial para clientes de celulares que suelen tener limites de datos y para Single Page Applications (SPA) que realizan un montón de requests cuyo body suele ser muy pequeño (un par de Identificadores de entidades y poco más)

Cache pushing

Aunque el computo de tiempo de carga final sea el mismo, siempre queda mejor, de cara al usuario, una espera inicial más larga (app bootstrap) y que el proceso posterior, mientras se trabaja, sea más fluido.
HTTP/2 permite mandar datos al cliente explícitamente para su cacheo y futuro uso. También permite  al servidor invalidar o actualizar esa cache de forma proactiva.

Protocolo binario

HTTP/2 ya no esta basado en texto. Es binario puro. Esto minimiza la carga de procesamiento del request/response, ocupa menos ancho de banda y es más simple y menos dado a errores. El problema de la depuración se tendrá que solventar con nuevas herramientas. De momento, el sniffer de red más popular, WireShark,  ya tiene un plugin para esta tarea.

domingo, 22 de febrero de 2015

viernes, 6 de febrero de 2015