El Blog de Marcelo!

De a poquito y con el reset del año, vuelven las ganas de leer y aprender sobre temas nuevos para escribir algo de texto y código como output de lo aprendido. En este caso, y para complementar aquello que escribí sobre HTTP/2, estoy preparando algo similar pero sobre QUIC como protocolo de transporte y HTTP/3 como protocolo de aplicación sobre él.

Ambos son Internet Standard desde hace muy poco tiempo (quic, http/3) y vienen y/o dependen de un paquete de otros protocolos y especificaciones que no son poca cosa.

Aún así, mi idea es describir sus conceptos fundamentales en español, como para que lo entienda un estudiante de una asignatura de redes de una Universidad cualquiera; analizar sus pros y cons, y por último dejar algo de código de ejemplo como para poder entender desde el punto de vista de un programador dónde tiene lugar para hacer un aporte y dónde no.

Les comparto el documento que armé dentro del marco del grupo de Teleinformática y Redes de la Universidad Nacional de Luján sobre el protocolo HTTP/2, a modo de recopilación, traducción y simplificación de todo lo que anda dando vueltas en la web. La idea es ir actualizándolo y completándolo a medida que pase el tiempo.

Dejo el link para bajarlo en PDF.

Se aceptan sugerencias, comentarios y críticas, por qué no. 🙂

Saludos

Una de las cosas que me sorprendió de la versión de Apache 2.4.18 incluida en Ubuntu 16.04 (y también en Ubuntu 16.10) es que el módulo mod_http2 no está habilitado por ser considerado «experimental» por el proyecto Apache.

Discusiones de si debe estar o no al margen, esta característica funciona mayormente bien y no tiene fallas importantes. En mi caso evalué un par de alternativas:

• Compilar un server nuevo desde los fuentes es poco práctico, ya que la integración de Apache lograda por el empaquetado de Debian/Ubuntu es mala o dificultosa como mínimo, además de tener que compilar por futuras actualizaciones de seguridad.
• Confiar en un repositorio PPA ajeno (como indican otros posts) también es un problema, más aún bajo ciertos entornos.

Es por esto que, buscando una alternativa diferente, encontré una manera relativamente fácil, rápida y «con actualizaciones» de habilitar el módulo HTTP/2 sobre el mismo Apache 2.4.18 que trae Ubuntu 16.04/16.10.

Dado que el módulo http2 se incluye en los fuentes, es posible compilarlo y copiarlo nuevamente a la instalación de Apache creada por el paquete Ubuntu. Como requisito, hay que tener los repositorios deb-src habilitados en el archivo /etc/apt/sources.list.

Luego se debe instalar libnghttp2-dev, descargar el paquete fuente de apache2 y compilarlo sin hacer ningún cambio. Los comandos para hacer esto son, como usuario con permisos de sudo sobre el sistema:

$ sudo apt-get install libnghttp2-dev
$ mkdir apache2
$ cd apache2
$ apt-get source apache2
$ sudo apt-get build-dep apache2
$ cd apache-2.4.18
$ fakeroot debian/rules binary

Después, copiar el módulo compilado (mod_http2.so) al directorio de módulos del apache, crear un archivo .load en /etc/apache2/mods-available y ejecutar a2enmod http2 para que Apache lo cargue. Luego, se reinicia el servicio y listo.

$ sudo cp debian/apache2-bin/usr/lib/apache2/modules/mod_http2.so /usr/lib/apache2/modules/
$ cat << EOF > /tmp/http2.load
LoadModule http2_module /usr/lib/apache2/modules/mod_http2.so
<IfModule http2_module>
  LogLevel http2:info
</IfModule>
EOF
$ sudo cp /tmp/http2.load /etc/apache2/mods-available/http2.load
$ sudo a2enmod http2
$ sudo service apache2 restart

Y listo. Luego resta configurar algunas de las opciones del módulo e incorporarlo en los VirtualHosts que necesitemos, indicando «Protocols h2 http/1.1».

Para más info de cómo instalarlo, leer acá.

Saludos

Estuve mirando y por suerte son prácticamente similares las tablas disponibles en cada site (EC2 / GCE) y es relativamente sencillo compararlas [1][2].

Para sus Data Centers en USA, establecí las siguientes relaciones:

• En las versiones de VMs «standard«, los precios son exactamente iguales, con configuraciones llamativamente similares.
• En las versiones «high memory«, es más barato Google (la mitad), aunque Amazon te da el doble de CPUs por una VM con la misma cantidad de memoria.
  Ej: Google te da 4 CPUs / 26 GB de RAM y Amazon en cambio te da 8 CPUs para su configuración de 26 GB de RAM. Dado que estamos en «high memory«, igualé a cantidad de memoria disponible para luego decir «Google es la mitad de barato».
• En las versiones «large» («high cpu» de Google), Amazon es un 15% más caro para igual cantidad de CPUs, pero te da el doble de memoria en sus VMs.

Observaciones:

• Se desprende de lo anterior Amazon EC2 ofrece perfiles más simétricos que Google comparando la relación de cantidades de CPU/Memoria. Puede ser útil para algunas aplicaciones o no, ya que va obviamente asociado al costo.
• Amazon tiene configuraciones con más CPUs ya que llega a 32 CPUs y más memoria también: 244 GB; Google llega a 16 CPUs y 104 GB de memoria.
• No comparé tamaños de almacenamiento, asumo que no tiene tanta relevancia para nuestra aplicación (se disponen de varias decenas de GB en disco en ambos).
• Amazon dice que te incluye discos de estado sólido (SSD). Google te cobra ambos (?) 0,04 USD por GB/mes el disco estándar, 0,325 USD GB/mes el SSD.
• Fundamental para la región en la que vivo: Amazon tiene Data Center en San Pablo (Brasil), Google no; sólo sirve VMs desde USA, Europa y Asia/Pacífico.
• Amazon tiene diferentes tipo de instancias, en este caso comparé las «Bajo demanda» aka «Dedicadas» (según el lugar que se mire en la documentación), que son las más caras. Las otras son tipo prepagas («Instancias Reservadas»), donde según entiendo, uno abona un importe fijo y después usa X cantidad de tiempo y se descuenta del fijo.
  Hay otros tipos de instancias pero no se ajustan a nuestro uso («Instancias Puntuales» y «Instancias optimizadas para EBS»). En este apartado, pareciera que Amazon tiene largamente muchas más ofertas y más desarrollo del negocio que Google.

Bonus Track: versus Linode.com

• Linode tiene hasta 20 CPUs / 96 GB RAM máximo [3].
• Linode es mucho más barato que ambos; es más simple su tabla de precios y más «1 a 1» la distribución de CPUs / RAM (4GB / 4CPUs, 8 GB / 6 CPUs, y así hacia arriba), además de que da bastante más storage en SSD.
  Por ejemplo, 4 GB / 4 CPUs en Linode: USD 0,06/hora (USD 40/mes), mientras que en Amazon estamos en USD 0,28/hora por 15GB / 4 CPUs o USD 0,105/hora por 3,75GB / 2 CPUs. Eso sí, Linode está en USA (Newark/Atlanta/Dallas/Fremont), Europa (Londres) y Asia (Tokio), no en Sudamérica.
• Comparando Linode contra GCE:
  • 1 Linode (2 GB de RAM/ 2 CPUs / 3 TB transfer / 48 GB SSD): U$S 20/mes.
  • 1 GCE (1,70 GB RAM / CPUs «shared» (?) / 48 GB SSD): U$S 33.29/mes (no dicen si hay límite de transferencia).
• A Linode lo conocemos los que estamos «en la pomada», y hay casos en donde suena mucho mejor «lo tengo repartido en la nube de Amazon/Google», nobleza obliga.

[1] http://aws.amazon.com/es/ec2/purchasing-options/dedicated-instances/
[2] https://cloud.google.com/products/compute-engine/
[3] https://www.linode.com/pricing

¿Sugerencias, comentarios?

Saludos

Si bien SPDY/4 todavía está en desarrollo, por lo que se deduce de este hilo y por lo que puede apreciarse en la forma que tienen ambos drafts, éste va a dejar de ser un trabajo separado de HTTP/2.0 como sucedía hasta la versión anterior, sino que será un protocolo que implementará progresivamente lo que se vaya definiendo y ganando adhesiones en la discusión que se está teniendo en el marco del IETF.

Es por esto que además de los cambios previamente definidos para SPDY/4, se le suma un «port» o «sincronización» de características definidas desde HTTP/2.0 hacia SPDY/4.  Los elementos que «se mudan» para desplazar a aquellos definidos en SPDY/3 cuentan con un relativo acuerdo general dentro del HTTPbis WG para ser parte de HTTP/2.0, y son:

• SYN_STREAM, SYN_REPLY, HEADERS pasan a ser reemplazados por HEADERS+PRIORITY* y HEADERS. Ya había un frame de HEADERS en SPDY/3, pero no se usaban en casos comunes; ahora pasan a eliminarse los frames SYN_STREAM y SYN_REPLY, unificando todas las formas de envío de headers HTTP (ya sea para iniciar/responder peticiones) en el frame de HEADERS que ya existía (entiendo que sólo se le agrega un campo de prioridad). En resumen, en SPDY/4 (y en HTTP/2.0), las peticiones se pedirán y responderán con un frame de HEADERS.
• Unificaron los frames de RST_STREAM y GOAWAY. Eran redundantes, claramente.
• Después de ciertas pruebas (ejemplo)(**), ya está definido el magic byte para inicializar una conexión directamente en HTTP/2.0 (o SPDY/4): «FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n». Pasando en limpio, la idea es que (en principio) haya 3 mecanismos de uso de HTTP/2.0:
  • Vía TLS+NPN, como SPDY/3. De todas maneras, NPN se envió hace unos meses al TLS WG y lo modificaron levemente, dándole forma a lo que se llama ALPN. Para el caso, hará lo mismo que NPN. Claro está, esto funciona sobre SSL/TLS (puerto 443), con sus pros y contras.
  • Si el servidor con el que hablamos no sabemos si soporta HTTP/2.0, se intentaría un upgrade mediante el mecanismo estándar de Upgrade de HTTP, como se hace con WebSockets (ejemplo). Esto funciona sobre puerto 80, en claro.
  • Si el servidor con el que hablamos sí sabemos de antemano que soporta HTTP/2.0, directamente se envía el magic byte luego de establecer la conexión TCP, para comenzar a intercambiar frames HTTP/2.0. La idea es ahorrar el tiempo (valioso) de upgrade. El magic byte está elegido en base a que si lo enviamos por equivocación a un server que sólo soporta HTTP/1.1, éste cause el cierre de la conexión inmediatamente.
  • Hay otras propuestas para ahorrarse el tiempo de upgrade sin saber de antemano si el server soporta 2.0, como publicar el soporte de HTTP/2.0 vía DNS (y así el navegador podría saber si el server habla 2.0 al momento de hacer la resolución DNS), pero por el momento la propuesta está en stand-by.
• Incluirá control de flujo por stream (además del control de flujo por sesión de SPDY/3).
• Un algoritmo de compresión de encabezados no basado en el stream completo de éstos, sino basado en cambios (diferencias entre los headers), para evitar los ataques del estilo CRIME. Sobre esto se está trabajando en el HTTPbis WG (principalmente por cosas como el requisito del mantenimiento de estado) y hay dos algoritmos con posibilidades (HeaderDiff y Delta). SPDY/4 incluiría este último.

*: Este frame está en discusión en estos momentos, quizá se defina un nuevo frame PRIORITY para soportar repriorización «al vuelo» de streams.
**: Es interesante comentar que en las pruebas de búsqueda del magic byte realizadas se intentó encontrar un stream de bytes que haga que la gran mayoría de web servers actuales que soporten HTTP/1.1 cierren la conexión inmediatamente o al menos devuelvan un código HTTP de error (4xx). La idea es que si un cliente envía ese stream de bytes, éste se asegure de una respuesta satisfactoria que asegure que el server es HTTP/2.0, y en caso contrario (por error, al suponer que el server soporta 2.0 pero no es así), el efecto producido en el server (y en la comunicación en sí) sea el mínimo posible.

Vamos a ver cómo evoluciona, y si SPDY/4 se hace «estable» en un futuro próximo para poder ir haciendo pruebas. Pero parece ser claro que va a ser bastante diferente a SPDY/3.

Saludos