En este caso se hace un proxy inverso, es decir, se envían las peticiones desde el frontend al backend. El “problema” es que las peticiones tienen origen (frontend) 127.0.0.1 (si en el backend está en la misma máquina) o la ip interna 192.x.x.x (si el backend está en la red interna). Si el frontend es suficientemente flexible soporta balanceo entre servidores. Esta es una lista de frontends que funcionan muy bien:

• pound: básicamente es un balanceador, pero muy eficiente
• perlbal: balanceador hecho en perl y servidor web para archivos estáticos. El código perl es sencillo y muy pontente, por lo que se pueden añadir funcionalidades rápidamente. Muy eficiente.
• squid: el de siempre. Se ha utilizado mucho para hacer proxy directo en vez de inverso, pero también se puede utilizar. Funciona muy bien y tiene un montón de funcionalidades, pero es menos eficiente que los anteriores.
• HAPrroxy: si buscas información detellada no te pierdas la documentación. Al final existe una explicación de la arquitectura separada en contenido estático y dinámico. Es uno de los mejores balanceadores/proxy, aunque incluye más funcionalidades.
• lighttpd: es un servidor web que nos puede servir páginas estáticas y hacer de proxy para el resto de peticiones. Una de las funcionalidades más interesantes es que puedes aplicar regular expressions para decidir el backend. Lo utilizamos en alguna ocasión con éxito.
• nginx: es un servidor web que cada día tiene mejor pinta. Es muy eficiente, rápido y sencillo de configurar. Cada día peligra más la hegemonía del apache. Permite servir un tipo de contenido y reenviar el resto al backend. Permite también regular expressions. Lo tenemos como frontend en algunos servidores y es una maravilla.

Pues bien, todas estas soluciones hay que configurarlas para que envíen la ip real al backend. Por ejemplo, en el caso del nginx hay que poner estas líneas:

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Sin embargo, el apache siempre pinta la ip del que viene la petición: 127.0.0.1 o la ip interna. Para lograr que pinte la ip real hay que utilizar un pequeño módulo: mod_rpaf.

El montaje es sencillo:

$ wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.5.tar.gz
$ tar xzf mod_rpaf-0.5.tar.gz
$ cd mod_rpaf-0.5
$ vi Makefile (editar la variable APXS)
$ make rpaf; make install (para el apache 1.x)
$ make rpaf-2.0; make install-2.0 (para el apache 2.0.x)

Luego hay que editar la configuración del apache y añadir estas líneas:

LoadModule rpaf_module        libexec/mod_rpaf.so
AddModule mod_rpaf.c
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 192.168.1.1
RPAFheader X-Forwarded-For

Ojo, en la línea RPAFproxy_ips hay que poner todas las ips desde donde vengan las peticiones al apache. Reiniciamos el apache y ya están las ips reales en los ficheros de logs.

Más adelante, se empezó a hablar de lenguajes de programación que convertían el contenido estático en páginas dinámicas. Se utilizaban cgis en C o en perl. Si el servidor estaba en unix incluso se podía utilizar shell scripts. Esos cgis en C permitían conectar con gran cantidad de sistemas en backend, desde bases de datos al uso a entornos hosts o middleware creados al efecto. Todas las empresas decidieron que era el momento de sacar sus aplicaciones a internet. Fue el primer boom, proyectos faraónicos y muchas, muchas horas de programación. Era la anarquía. Pero esto era coto cerrado para grandes empresas que invertían grandes cantidades de dinero. El resto se conformaban con una página web estática y un link que enviaba un mail.

Pero en 1995, Rasmus Lerdorf creó un lenguaje de programación que llamó PHP (Personal Home Page). Empezó como un cgi en C que interpretaba páginas con contenido estático y un lenguaje muy sencillo para poder generar el contenido dinámico. Tras varias versiones se incluyó el cgi como módulo del apache y su popularidad empezó a crecer. En ese momento existía un servidor web, llamado apache con un módulo de php que permitía crear páginas web dinámicas de forma sencilla y económica. A partir de ahí se produjo una segunda explosión de la web.

Sin embargo no eran muchas las empresas que se fiaban de “eso del open source”, confundiendo una vez más los terminos y descalificando las tecnologías sin conocerlas. De ahí que muchas empresas comenzaran a crear nuevas tecnologías y dar soporte para que las grandes empresas tuvieran la tranquilidad de entrar en un mundo nuevo. Compañías como Sun Microsystems, Netscape, Bea, IBM o Microsoft entraron en un nuevo nicho de mercado: los servidores de aplicaciones. Sun fue una de las primeras en entrar con su lenguaje java. Fue uno de los lenguajes que más rápido se popularizó. Una de las ventajas era su caracter abierto a la comunidad de desarrolladores. Sun mientras tanto se dedicó a vender su servidor de aplicaciones. Bea fue otro de los competidores que entró de la mano de su producto Weblogic. IBM suele llegar tarde al mercado, pero con el tiempo se impone al resto. Es un corredor de fondo. Su producto Websphere Application Server tardó más que el resto en llegar, sin embargo a día de hoy es el líder frente a sus competidores en el apartado de servidor de aplicación en java. IBM utiliza como frontal web apache. Microsoft emplea sus propios lenguajes que ejecutan sus motores. La web más reconocida para este benchmark es Netcraft que publica semanalmente un informe (por ejemplo Junio 2008), donde muestra este gráfico actualizado:

Lo que nos indica claramente el gráfico es la supremacía de los servidores de código abierto sobre los propietarios, y no sólo por apache. Hay que incluir lighttpd, nginx o google, que aunque no está liberado está basado en apache (al menos eso se dice en la red y es uno de los conocimientos que piden para entrar a trabajar en Google).

Esta es la teoría, en un siguiente post, mostraremos la evolución tecnológica y cómo se mejora el rendimiento con los nuevos productos. LandM empezó con servidores apache sin ningún tipo de lenguaje de programación. Hoy tenemos un frontal para servir contenido estático, un servidor apache que ejecuta cierta lógica y el contenido dinámico que es interpretado por otro motor. Además incorporamos caches intermedias para acelerar la respuesta. ¡Cómo hemos cambiado!