Servidores, páginas web, lenguajes e Internet.

Como desarrollador de software, constantemente me encuentro instalando servidores, compilando programas y cosas similares. Cuando cuento a alguien no informático lo que estuve haciendo, me encuentro con caras raras que no entienden un pomo de lo que estoy hablando. La gente común tiene creencias anticuadas, como que un servidor es una mega computadora llena de luces raras y con cables por todos lados, piensan que para hacer una página web hay que ser un programador super inteligente, y que una base de datos es un concepto tan raro como abstracto que no tienen ni idea de lo que hace pero suena muy geek.

Bueno, en este post planeo tratar de dejar en claro como funciona todo esto, de manera bien fácil y sin demasiados rodeos. Veamos de que se trata todo esto.

Primero, lo primero ¿Qué es un servidor?
Un servidor es un proceso (o sea, un programa más, como el messenger o el word, pero no que tiene interfaz gráfica y se ejecuta en background), que lo único que hace es esperar que alguien le pida que le brinde un servicio en particular. Así de simple como suena. Cuando esto sucede, el servidor “se despierta”, hace lo que le piden, retorna los resultados, y sigue esperando que alguien mas le pida algo.  Hay dos cosas para tener bien claras:
1)El servidor es un proceso, no es una computadora. O sea, en una misma computadora «fisica» podría tener varios servidores ejecutándose a la vez.
2)El servidor NUNCA inicia la conversación, siempre hay un cliente que le solicita su servicio y toma los resultados.
Por lo general, un servidor escucha peticiones a un servicio en particular en un determinado puerto; por ejemplo, un servidor de paginas web usa el puerto 80, uno de bases de datos usa el puerto 3306, un servidor FTP por el 21, un SSH por el 22, etc…
El Servidor web, un caso común por estos días.

Un servidor web (o también servidor http) es un proceso que se ejecuta sobre alguna computadora en cualquier plataforma (Windows, Linux, unix, mac, solaris,…) y cuya única función es escuchar todo el tiempo las peticiones del puerto 80 (casualmente el puerto por el que funciona el protocolo http, el que usan los navegadores) de la maquina donde se esta ejecutando y responder a esas peticiones con código HTML. O sea, la cosa seria algo asi:
Supongamos que tenemos una PC (cliente, con un browser) que solicita a la dirección http://www.direccion.com una pagina web. El servidor web recibe esto por el puerto 80 y se fija si puede y lo envía (o si no puede, envía una página de error como por ejemplo, el famoso error 404 de No Encontrado, o el 403 de No tiene permisos).
Cada webserver tiene una carpeta o directorio (al menos una, pero podria tener muchas más) que toma como raíz del árbol web.  Por ejemplo, para el apache (el servidor web más utilizado en el mundo) podría ser /var/www .  Todo lo que pongamos ahí, va a ser accesible desde la web (en principio, esto no es necesariamente asi, pero no entremos en detalle).   O sea, si yo estoy parado en la PC que tiene el servidor corriendo, y escribo http://localhost/mispaginas/Gonzalo.html en el navegador, el servidor va a leer esa petición, buscar dentro de su árbol web una carpeta que se llama mis paginas, allí un archivo que se llama pagina.html, y lo va a mandar. Ojo! Si yo escribo en mi browser /var/www/mispaginas/pagina.html  estamos haciendo referencia al mismo archivo, pero en este caso la petición no pasara por el servidor web, sino que será el mismísimo sistema operativo el que envie el archivo al programa que lo solicito. No entremos en detalles tampoco, pero es bueno saber que es muy distinto.
Apache es un servidor web multiplataforma Open Source. IIS es un servidor web solo para Windows, propietario y hecho obviamente por Microsoft. Hay muuuuuchios servidores web, pero estos son los mas conocidos (Google tiene el suyo, hay uno muy livianito que se llama lighttp, etc…).

Bueno, como ya vimos, un web server es un tipo muy básico que sabe hacer muy pocas cosas. Es bien simple: yo tengo una página almacenada en mi servidor, que tiene código html que hace referencia a unas imágenes y a unas animaciones flash, y el servidor solo toma estos archivos y los envía a los clientes a medida que estos los van solicitando. Nada más, ni analiza estos archivos, ni procesa nada, solo toma archivos y los manda (es “casi” lo mismo que hace un servidor ftp cuando alguien copia un archivo del servidor y lo pega en su computadora). Y es el cliente (el navegador, como el Mozilla Firefox, o el Internet Explorer, Opera, Konqueror, Safari, entre otros) el que toma este código y lo «analiza» para mostrarlo de manera coherente.
¿Como hacemos para generar paginas dinámicas, que tienen mucho procesamiento, acceso a bases de datos, y muuuchisimas cositas mas? Bueno, aquí entran en juego los lenguajes de script como asp, php, y tantos otros.  Vale la pena aclarar aquí que estos scripts se ejecutan en el servidor y no en el cliente, y esto nos permite controlar un poco mejor como se ejecutan las cosas, ya que el servidor es un entorno controlado, mientras que las PCs de los usuarios no lo son. Javascript y HTML son lenguajes para generar paginas web que sí se ejecutan en el cliente, mientras que el resto los ejecuta el servidor y envía al cliente la «salida» generada.

¿Cómo funciona esto? Usaremos php como ejemplo.

Primero: la PC con el proceso servidor tiene un programita que saber ejecutar código php y generar código html como respuesta (recordemos que el cliente, o sea el navegador web, solo entiende código html y sus extras – javascript, imágenes, flash, y un par de cositas mas – pero si le mandan otra cosa, no sabrá que hacer). No importa como, pero lo tiene por ahí dando vueltas. Y nuestro proceso servidor tiene alguna configuración que le permite “hablar” con ese programita para pedirle que ejecute códigos php. Cada vez que el servidor web detecta una petición por el puerto 80 y la procesa, se fija si necesita un interprete PHP para poder ejecutarla. De ser asi, le pide al php que se la ejecute y le devuelva un resultado html, el cual es nuevamente tomado por el servidor web y enviado al cliente solicitante.

¿Y los datos de donde los sacamos?
Hasta ahora tenemos un proceso que “sirve” paginas web, y un programita – asistente del servidor web – que sabe ejecutar códigos en un lenguaje de script del lado del servidor (PHP).  Pero que pasa si ese código implica acceder a un repositorio de datos? Por ejemplo, supongamos que tenemos una base de datos de usuarios, con password, permisos y esas cosas…
Aquí entra en juego el motor de base de datos (BBDD).  Un motor de BBDD  es otro programita que sabe recibir peticiones para acceder a un monton de datos almacenados en archivos de manera muuuy rápida y devolver los resultados en forma tablas, con filas y columnas, o en forma de XML, o en forma de Objetos (tampoooco vamos a entrar en detalles aquí). En nuestro caso, hablaremos de MySQL para seguir la movida Open Source, pero nuevamente hay miles (SQL Server, DB2, Access, eXist para XML, Postgrees,…), algunos propietarios, otros OpenSource, otros Freeware, otros en prueba… En fin, para variar, no entraremos en detalles tampoco aquí.
La Base de datos puede estar en la misma computadora que el servidor web, o en otra en la misma red, o en otra a millones de Km de distancia, incluso en el espacio o en otro planeta. La idea es que no importa la localidad de los datos, lo importante es que de alguna mantera nuestro servidor web, por medio del lenguaje de script, pueda comunicarse con ese servidor de BBDD.
Por ahora tenemos un servidor web, un lenguaje de script y ahora le sumamos un proceso para acceder a los datos. ¿Cómo funciona todo esto? Bien simple. Primero usemos la lógica: si hay que acceder a los datos, es porque algún programa o algo medianamente dinamico lo solicitó. O sea, como el HTML es bien chato y el Apache no sabe usar la lógica, tiene que ser el PHP el que lo pidió. Por lo tanto, tenemos un archivo php que tiene en su código algunas líneas que piden conectarse a la BBDD, hacer alguna operación y mostrar resultados (como por ejemplo, listar todos los países registrados). La idea es casi la misma que veníamos viendo, con la diferencia de que, cuando se solicita el acceso a la BBDD, el php se conecta con un proceso servidor de BBDD, pide una operación, recibe los resultados y genera el HTML que le manda al Apache.
Bueno, mucha información por un día. Cuesta un poco procesarlo al principio, pero una vez que lo entendemos no es tan complicado. Les dejo unas recomendaciones para que puedan arrancar:
1. Existe un paquete para Windows, llamado xmapp, que permite instalar con un simple clic, Apache, PHP y MySQL. Es muy piola, yo lo recomiendo. Esto nos permite jugar y romper tranquilos en nuestras Pcs, sin depender de un hosting y de una conexión a internet (el servidor y el cliente se ejecutarían en la misma PC).

En Linux, esto no es necesario. Si queremos instalar apache, php y mysql (LAMP: linux, apache, mysql, php) en Ubuntu, simplemente escribimos:

sudo apt-get install apache2 php5 php5-mysql mysql-server

y listo. Y en otras distros, tendremos tambien estos paquetes disponibles en los repositorios, pues son lo más común del mundo.

2. Hay miles de temas para aprender, pero vamos despacio. Un tema interesante para continuar sería como se crea una página web, como es la estructura de un documento web y que es el HTML y el CSS. Vale la pena.