Tiempo atrás hablámos sobre cómo funciona el sistema web. En ese momento me basé en las versiones del protocolo más extendidas: 1.0 y 1.1; pero hace tiempo que HTTP/2 está funcionando tanto en servidores como en navegadores y recientemente se está elaborando HTTP/3, ¿sabes qué ventajas nos proporcionarán?
El protocolo HTTP/2 en realidad lleva con nosotros ya bastante tiempo. Los navegadores Firefox en su versión 36, Chrome en su versión 40, Opera en su versión 26 y Explorer en su versión 11 ya lo pusieron a disposición del usuario. No obstante Google Chrome y Firefox en principio solo lo emplean para transmisiones encriptadas. Puedes ver más navegadores en este enlace donde verás una tabla de navegadores y cómo soportan específicamente el protocolo:
Un poco de historia
En estos tiempos las interfaces mostrar información en Internet (web) y conexiones entre máquinas (APIs o servicios web) está monopolizada por HTTP. Este protocolo es simple y ha sido la base para la comunicación a modo cliente servidor de la web 1.0 y 2.0. No obstante, los tiempos cambian. Las webs demandan más interactividad entre cliente y servidor por lo que surgió SPDY (pronunciado como speedy).
El protocolo SPDY tenía como ventajas reducir la latencia y la cantidad de información duplicada que se intercambia entre cliente y servidor. Si revisas el artículo de cómo funciona el servicio web verás que HTTP normalmente abre una conexión, realiza una petición al servidor enviando una serie de cabeceras y después suele cerrar la conexión. Hay excepciones como cuando se usa keep-alive en HTTP/1.1, pero esto aún así se deben enviar todas las cabeceras cada vez.
La mejora de SPDY consiste en enviar estas cabeceras solo la primera vez. En el resto de peticiones dentro de la misma conexión se entiende que aplican las cabeceras enviadas al principio, a menos que se especifique nuevas cabeceras con nuevos valores que sobreescriban las anteriores. Esto ayuda a no tener que enviar cada vez información redundante como cookies, identificador del navegador, el nombre de máquina al que estamos conectando, información del navegador, etc.
HTTP/2
En 2012 pasó a ser parte de HTTP bajo la versión 2.0 agregando además otras características como la posibilidad de realizar peticiones asíncronas. El cliente puede conectarse y enviar de forma seguida todas las peticiones de ficheros necesarios para cargar la web y el servidor las responde a través de una multiplexación todas a la vez aprovechando el ancho de banda y el fraccionamiento de paquetes.
No solo eso. El esquema cliente-servidor queda en entredicho permitiendo al servidor enviar peticiones al cliente una vez la comunicación está abierta. Este mecanismo se conoce como server push. De esta forma el servidor puede notificar al cliente sin necesidad de que el cliente haga ninguna petición previa facilitando la implementación de soluciones como chat y trabajo colaborativo online entre otras.
Para agregar aún mejor rendimiento el protocolo permite enviarse de forma binaria haciéndolo menos propenso a fallos y más compacto.
Soporte HTTP/2
En estos momentos puedes disponer de HTTP/2 en Apache y Nginx. He revisado información para poder disponer de todas las características en frameworks como Rails, Django o en general en PHP pero no dejan claro cómo poder realizar este uso. En Phoenix Framework gracias al uso de cowboy sí disponemos de estas características y están integradas en el sistema para usarlas de forma transparente.
Una de las ventajas de emplear HTTP/2 frente a los mecanismos poll HTTP o el combo formado por HTTP y websocket es la facilidad de realizar todo desde una misma conexión eliminando latencias y tamaño de transmisión del primer caso y la inseguridad de tener dos conexiones separadas del segundo caso.
Servicios como las notificaciones móviles de Apple (APNS) han sido migradas a este protocolo para facilitar la integración de backend de sus usuarios y clientes como curl ya cuentan con soporte para poder realizar llamadas y probar a nivel de consola nuestros servidores:
$ curl -V
curl 7.54.0 (x86_64-apple-darwin18.0) libcurl/7.54.0 LibreSSL/2.6.4 zlib/1.2.11 nghttp2/1.24.1
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy
Ahí vemos en la versión de curl instalada en mi máquina ya tiene soporte HTTP2. Solo tendríamos que realizar una petición agregando el parámetro --http2 para forzar su uso en la petición.
¿Qué es ALPN?
Seguramente si te ha dado por indagar habrás topado con ALPN (Application-Layer Protocol Negotiation) para el uso de HTTP/2. Este protocolo permite al cliente negociar con el servidor el establecimiento de una conexión HTTP/2. De esta forma podemos mantener la compatibilidad en el mismo puerto de versiones HTTP/1.x y HTTP/2.
Este protocolo asegura una forma óptima de establecer una comunicación TLS (encriptada) con el servidor para la negociación del protocolo HTTP a emplear.
Como dije anteriormente la mayoría de navegadores implementan solo HTTP/2 cuando se trata de comunicaciones encriptadas. El protocolo ALPN les permite la negociación fácil de esta elección de protocolo y por lo tanto simplifica la elección de HTTP/2 cuando está disponible tanto en el cliente como en el servidor.
QUIC y HTTP/3
Hasta la fecha el uso de HTTP/2 solventa la mayor parte de los problemas que HTTP y otros aditivos intentaban solucionar y lo hacen de una forma elegante. Pero hay problemáticas a más bajo nivel que grandes empresas como Google han intentado solventar. La implementación de QUIC (Quick UDP Internet Connections) es una solución pensada para acelerar la conexión TCP a través de paquetes UDP.
Este protocolo construido sobre UDP permite simular el estado de conexión de TCP y transportar otros protocolos sobre él con un coste mucho menor y un intercambio de información simplificado. Google ya emplea este protocolo y está implementado tanto en sus servidores como en Chrome desde su versión 29 y en Opera desde su versión 16:
La última noticia de Internet Engineering Task Force (IETF) fue la implementación del borrador de HTTP sobre QUIC como HTTP/3. Aunque parece un caso similar al de SPDY el protocolo QUIC no creo que desaparezca porque aún podría emplearse aparte de HTTP.
El grupo de desarrollo del protocolo HTTP estará ocupado desarrollando en los siguientes meses esta implementación y será el próximo hito para tanto navegadores como servidores web.
Las ventajas que agregará esta extensión serán de nuevo una mayor velocidad de conectividad y por lo tanto menores latencias para acceder a las webs que lo soporten. Sobretodo en segundas conexiones donde la latencia será cero. También agrega mayor seguridad.
Conclusiones
Tras haber hablado hace unos días sobre IPv6 creo que está bien haber sacado el tema de los protocolos HTTP y así revisar lo que ya podemos usar y sacar partido de ello como es el caso de HTTP/2 y lo que está por llegar de la mano los grandes actores del panorama web. En este caso sobre todo Google.
Me gusta sobretodo la forma en la que HTTP/2 dibuja la nueva posibilidad de interaccionar para la web 3.0 donde el chat y la información empujada desde el servidor se hace cada vez más importante así como elementos que van tomando cada vez mejores posiciones se hacen eco de estas nuevas tecnologías desarrollando soluciones cada vez más accesibles y factibles para la mayoría de desarrolladores como es el caso de Phoenix Framework.
¿Has revisado si tu navegador y/o proveedor de web soporta HTTP/2 y HTTP/3?, ¿tienes alguna experiencia traumática con poll-HTTP o incluso con websockets que podría haber sido mejor empleando HTTP/2?, ¿necesitas ayuda con algún proyecto HTTP/2? ¡Déjanos un comentario!
