Archivo

Archivo para la categoría ‘web’

Habilitando HTTP/2 en Apache sobre Ubuntu 16.04 sin PPAs

Martes, 14 de Marzo de 2017 Sin comentarios

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

Categories: codear, linux, sysadmin, web Tags:

Comparando costos de Amazon EC2 y Google Computing Engine

Miércoles, 17 de Septiembre de 2014 Sin comentarios

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

Categories: codear, linux, sysadmin, web Tags:

Novedades en SPDY/4, HTTP/2.0

Domingo, 26 de Mayo de 2013 Sin comentarios

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

Categories: codear, sysadmin, web Tags:

PyConAr 2012: Charla sobre el protocolo SPDY – Video

Miércoles, 2 de Enero de 2013 Sin comentarios

Con el nuevo año, aparecieron en su totalidad los videos de la PyConAr 2012 subidos a Youtube por Mariano Reingart, el Coordinador del evento.

Dejo en este post el mío, no sin un dejo de “vergüencita”, je… (encima todavía no lo vi):

Cualquier duda me pueden consultar o comentar este mismo post. Espero próximamente escribir más en profundidad de ciertos aspectos que me quedaron afuera de la charla.

¡Saludos!

Categories: codear, programación, python, web Tags:

Investigando el protocolo SPDY

Domingo, 15 de Julio de 2012 2 comentarios

Un tiempo atrás venía buscando áreas de investigación para estudiar, y me encontré con una interesante propuesta de Google, de renovar el ya “viejito pero cumplidor” protocolo HTTP 1.1, llamada SPDY (no sin algo de sentido comercial, se nota).

De ahí en adelante (dado que el desarrollo es abierto a la discusión en general) me dediqué a profundizar en él, entender sus ventajas (lo cual implica entender algunas cosas feas de HTTP 1.1 y la Web de hoy en día), limitaciones, y cosas que faltan implementar. Me apasionó el tema, tanto es así que lo propuse como tema de Tesis para mis estudios y hasta ahora vengo bien (bien con las promesas a mi Director, claro está :-P).

Mi idea era con este post abrir una serie de artículos para documentar lo que voy aprendiendo sobre este protocolo, que cada vez tiene más hype en la industria, tanto que Twitter y Google ya lo implementan en sus servidores (Facebook está en camino), mientras que Chrome/Chromium y Firefox (Opera se está sumando) también lo usan si está disponible.

Personalmente me puse a probarlo y a tratar de implementarlo usando Python, forkeando un proyecto que ya existía y arreglando los problemas más obvios que encontré. Todavía tengo todo el código “atado con alambre”, no bien testeado, y no estoy seguro si funciona del todo (jua!), pero de ahora en más voy a tratar de mejorarlo y mantenerlo mientras pueda, además de dejar algún rastro por aquí y por mi trabajo de investigación formal.

En resumen, el IETF draft de SPDY está disponible acá; tanto parece estar movilizando este protocolo, que el HTTPbis Working Group, encargado de definir un futuro HTTP 2.0, se está moviendo desde hace un tiempo para discutir las propuestas de SPDY. Y esto recién empieza…

Les dejo un video del último Google IO 2012 que es un excelente acercamiento técnico al tema:

Saludos

Categories: codear, python, web Tags: