¿Cómo funcionan los VirtualHost?
Los servidores web actuales tienen facilidades para hospedar múltiples dominios teniendo una sóla dirección IP pública. A éstas facilidades se les llama VirtualHost.
Para entender cómo funcionan los VirtualHost podemos comenzar tratando de entender el protocolo HTTP.
En palabras muy coloquiales, podríamos decir que el protocolo HTTP es una serie de frases entre un servidor (la máquina en donde está el sitio), y un cliente (que puede ser el navegador).
El cliente busca al servidor e inicia la conversación, le pide un objeto y le da algunos detalles del objeto. El servidor busca al objeto con los detalles que el cliente le dio, en caso de que lo encuentre, envía al objeto requerido además de información adicional, en caso contrario, el servidor explica lo que ha sucedido.
Dejándo de lado las malas analogías, comencemos a jugar con algo más interesante, utilizemos netcat para entender el funcionamento del protocolo. Netcat es un programa muy simple, como todas las herramientas UNIX, pero con el que se pueden realizar tareas bastante interesantes, netcat se dedica a manejar conexiones entre un cliente y un servidor.
Utilizemos a netcat y a google.com como ejemplo para entender el protocolo.
Nos queremos conectar a google.com por el puerto de HTTP, para saber cuál utilizar le podemos preguntar al archivo /etc/services.
$ grep http /etc/services
# Updated from http://www.iana.org/assignments/port-numbers and other
# sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services .
www 80/tcp http # WorldWideWeb HTTP
https 443/tcp # http protocol over TLS/SSL
https 443/udp
http-alt 8080/tcp webcache # WWW caching service
http-alt 8080/udp # WWW caching servic
Ahora sabemos que debemos conectar al puerto 80.
$ nc -v google.com 80
DNS fwd/rev mismatch: google.com != eh-in-f99.google.com
DNS fwd/rev mismatch: google.com != py-in-f99.google.com
DNS fwd/rev mismatch: google.com != jc-in-f99.google.com
google.com [72.14.207.99] 80 (www) open
Rápidamente escribimos:
GET /
Seguido de dos {enter} más.
Según el país de procedencia, google nos responde con un mensaje que indica que debemos hacer la petición a otro servidor, en mi caso google.com me dice que le pregunte a www.google.com.mx.
Repetimos el paso con www.google.com.mx (o con el servidor que google.com te indique):
$ nc -v www.google.com.mx 80
GET /
Extrañamente recibimos la misma indicación, al parecer el servidor no entendió la pregunta que el cliente le hizo. Ésto se debe a que la petición está mal formulada, en realidad la petición debe ser así:
GET /archivo/requerido.txt HTTP/X.Y\r\n
Header1: valor\r\n
Header2: valor\r\n
\r\n
\r\n
Los \r\n representan retornos de carro. Es necesario terminar la petición con dos retornos de carro vacíos, ésto le indica al servidor que hemos terminado de enviar datos y que esperamos respuesta.
Reintentemos de nuevo sabiendo más sobre peticiones:
$ nc -v www.google.com.mx 80
GET / HTTP/1.1
Host: www.google.com.mx
La cabecera “Host” es obligatoria para jugar con VirtualHost, es la única forma que el servidor tiene para saber qué buscar y en qué parte.
Ésta vez debemos tener una respuesta parecida a ésta:
$ nc -v www.google.com.mx 80
GET / HTTP/1.1
Host: www.google.com.mx
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6e786c9ea2b43da6:TM=1205966447:LM=1207966447:S=Z3TC-WmVvTmmdhX9; expires=Mon, 12-Apr-2010 02:14:07 GMT; path=/; domain=.google.com.mx
Date: Sat, 12 Apr 2008 02:14:07 GMT
Server: gws
Transfer-Encoding: chunked
15b1
...
c7
...
0
Ésta vez le hemos dicho a google.com.mx que requerimos el virtualhost www.google.com.mx de la IP 74.14.207.104.
$ host 72.14.207.104
104.207.14.72.in-addr.arpa domain name pointer eh-in-f104.google.com.
Ahora intenta hacer lo mismo, pero utilizando la IP en vez del dominio google.com.mx
$ nc -v 72.14.207.104 80
GET / HTTP/1.1
Host: www.google.com.mx
El resultado del proceso usando la IP en vez del dominio debe ser exactamente el mismo.
En realidad el proceso interno es más complicado que un típico VirtualHost, las IP asignadas a aquellos nombres de dominio son más bien variables, intenta haciendo varios pings a www.google.com.mx con un intervalo de un segundo (para el ping con Ctrl+C y comienza de nuevo), verás que las IP no son constantes para el mismo dominio y ésto no tiene relación con con el servidor web.
Ahora quisiera explicar en que consiste la respuesta del servidor y qué es ese “Content-Encoding: chunked”, así como el envío de contraseñas y demás cosas pero eso corresponde a otro tema que espero pueda tratar mañana :).
Protocolos como SMTP para envío de correo y FTP para transmisión de datos son otro par de cosas bastante interesantes para jugar.
About the author
xiam
José Carlos Nieto is a nerd that pretends to be a Math student (UNAM), he works with his friends creating amazing stuff at Astrata Software.






