Funcionamiento del Protocolo HTTP

El protocolo HTTP es el usado en lo que popularmente se conoce como web. Se usa tanto para que el navegador pida una página a un servidor, como para que éste envíe la página solicitada al navegador. Está basado en el envío de comandos y respuestas en texto ASCII, si bien cada tipo de contenido enviado (archivo en formato HTML, imágenes en diversos formatos, documentos en formato PDF, etc.) se enviará tal cual está almacenado en el servidor. Es decir, los archivos binarios se envían tal cual, aunque los comandos y las respuestas del protocolo HTTP vayan siempre en texto.

En realidad, cuando un navegador conecta con un servidor web remoto no sólo le solicita la página cuya URL el usuario ha tecleado (o la indicada en el enlace seleccionado con el ratón), sino que le informa de detalles del navegador, de la página que solicita, etc. Quizás viendo un ejemplo esto último quede más claro. A continuación se muestra una petición HTTP típica, de la página principal de este sitio:

GET / HTTP/1.1Host: www.24x7linux.comUser-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2, text/css,*/*;q=0.1Accept-Language: es-es, en-us;q=0.66, en;q=0.33Accept-Encoding: gzip, deflate, compress;q=0.9Accept-Charset: ISO-8859-15, utf-8;q=0.66, *;q=0.66Keep-Alive: 300Connection: keep-alive

El proceso completo es el siguiente. El usuario teclea www.24x7linux en su navegador (el prefijo http:// indica el protocolo que habrá de usar el navegador tras conectar con el servidor, que es el protoclo predeterminado). El navegador realiza una consulta DNS para averiguar la dirección IP asociada al nombre www.24x7linux.com, por ejemplo 66.227.74.170. Y entonces intenta establecer una conexión TCP al puerto 80 (el predeterminado para los servidores web).

Cuando dicha conexión se ha establecido, el navegador envía la petición HTTP solicitando la página indicada tecleada por el usuario. Puesto que no se indicó una página en concreto, el navegador asume que se solicita la página principal, que se representa como /. Como se ve en el listado anterior, además se envía información adicional.

Por ejemplo, se informa del navegador en uso (User-Agent) y en qué idioma se prefiere visualizar la página que se está solicitando (Accept-Language) (esto permite que una web albergue los contenidos en varios idiomas, y se le envía al navegador la versión en el idioma que tenga configurado en sus opciones).

Las cabeceras Accept-Encoding y Accept-Charset y Accept le indican al servidor qué tipos de contenidos el navegador entiende y sabe representar. Por ejemplo, mientras que el navegador usado entiende imágenes PNG (image/png), es muy probable que un navegador en modo texto no, y por lo tanto enviará unas cabeceras acorde con sus capacidades. De hecho, estas y otras cabeceras son personalizables, de manera que podemos forzar que nuestro navegador se identifique como otro, para entrar en esos sitios que nos impiden el acceso por la arbitraria razón de no usar un navegador en concreto.

La pareja de cabeceras Keep-Alive y Connection, sólo está presente en la versión 1.1 del protocolo HTTP, y permite recibir muchos recursos (páginas HTML, imágenes, etc.) a través de la conexión TCP recién establecida. En la versión 1.0 del protocolo HTTP era necesario establecer y terminar una conexión TCP por cada recurso, lo que resultaba tremendamente ineficiente.

Hasta ahora, el servidor sólo sabe que tiene que enviar al navegador remoto la página inicial del servidor web asociado a la IP a que se ha conectado. Pero no sería posible tener hospedadas las páginas de varios clientes en el mismo servidor y usando la misma dirección IP (virtual hosting). Para ello, la versión 1.1 del protocolo HTTP añadió la obligatoriedad de la cabecera Host, que indica al servidor las páginas de qué sitio queremos ver, aunque haya varias asociadas a un servidor web en la misma dirección IP.

El servidor recibe todas estas (y posiblemente más cabeceras, por ejemplo, en el caso de que haya algún proxy intermedio), las interpreta, y devolverá al navegador una respuesta estándar HTTP (indicando si la petición tuvo éxito o no), y a continuacón la página solicitada. En el caso de la página principal implícita (/), el servidor tendrá configurada un archivo, normalmente index.html, que enviará en caso de no especificarse una página en concreto:

HTTP/1.1 200 OKDate: Sun, 10 Nov 2002 22:50:55 GMTServer: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2 mod_log_bytes/0.3 FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6bContent-Type: text/htmlAge: 130Connection: close

<-- archivo index.html que contiene la página principal del sitio -->

Se ha recortado la respuesta del servidor web a la parte interesante de la misma. Como se ve, en primer lugar el servidor informa del éxito de la petición (200 OK) y de la versión del protocolo que conoce (HTTP/1.1). También indica la fecha y hora en el servidor (Date) y la versión y módulos del servidor web (Server).

Lo realmente interesante es la cabecera Content-Type, que le dice al navegador el tipo de contenido que viene a continuación (text/html) seguido del contenido propiamente dicho (el archivo index.html en el directorio base del servidor web). Si en lugar de pedir una página en formato HTML se solicita un recurso binario, como por ejemplo un archivo gráfico, la respuesta será de la forma siguiente:

HTTP/1.1 200 OKDate: Sun, 10 Nov 2002 23:15:31 GMTServer: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2 mod_log_bytes/0.3 FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6bLast-Modified: Fri, 01 Nov 2002 12:23:38 GMTETag: "23c32f-171cb-3dc2724a"Accept-Ranges: bytesContent-Length: 94667Content-Type: image/pngAge: 131

Una respuesta como la primera, pero en este caso se indica que a continuación viene el contenido de un archivo binario en formato PNG, el tamaño en octetos del archivo, y la fecha de su última modificación. Esta fecha, y el valor de las etiquetas ETag son usados por los cachés de protocolo HTTP para decidir si almacenar o no en su memoria y disco el recurso al cual se refieren, por considerarlo más reciente que la copia que ya tenían (en caso de tenerla). Cuando alguien vuelve a solicitar ese mismo recurso y la caché ve la petición, devuelve al cliente la copia almacenada en su memoria, lo cual acelera la carga del recurso y reduce la carga en los enlaces de la red y en el servidor remoto.

Evidentemente el protocolo HTTP es mucho más amplio que lo visto en este breve artículo, pero espero sirva para saber qué sucede desde que introducimos una URL en nuestro navegador, hasta que vemos el resultado en pantalla. Saber estos detalles es especialmente útil a la hora de intentar resolver problemas de navegación, como por ejemplo los que ha venido sufriendo este sitio durante los últimos días.