Entendiendo El Funcionamiento Del Protocolo HTTP

Entendiendo el funcionamiento del protocolo HTTP

Pongámonos técnicos para conocer y entender uno de los protocolos mas importantes y que se han vuelto esenciales en nuestra vida. ¿Protocolos de actuación en caso de emergencia? Bah eso son chorradas, hablamos de Internet y cómo el HTTP ha conseguido que dependamos completamente de el.

¿Qué narices es el protocolo HTTP?

Buena pregunta mi pequeño padawan. Y según su definición mas técnica de la Wikipedia:

HTTP, también conocido como Protocolo de Transporte de Hipertexto es un protocolo en la capa de aplicación del modelo OSI que se utiliza para transmitir prácticamente todos los archivos y datos de Internet, ya sean archivos HTML, imágenes, resultados de consultas u otras cosas.

Pues así es. Casi todo lo que recibes en tu smartphone, desde la foto de la chica que te gusta de Tinder hasta los mensajes de Whatsapp de tu madre llegan a través este protocolo.

Podríamos llegar a imaginar que el HTTP es como si fueran las carreteras del Interné pero al tratarse de un protocolo es mas bien un manual, un tutorial, una serie de reglas de cómo se tiene que comportar la información cuando viaja desde un punto A a un punto B.

Por lo general, HTTP se realiza a través de unos canales de comunicación llamados sockets TCP/IP.

Pero párate a pensar en cómo funciona el HTTP, no hace falta que entres en cuestiones técnicas, tan solo trata de imaginar que pasa cuando ves la foto de la chica del Tinder.

Cuando abres la aplicación en tu smartphone y quieres consultar el perfil de una usuaria tu móvil pide la información a un sitio indefinido de la “nube”, esa información se procesa y te llega una respuesta de ese sitio indefinido en forma de foto de perfil y demás información relativa a esa usuaria.

Esa información no te llega por arte de magia sino que alguien te la da cuando la pides.

Pues bueno siguiendo con el paralelismo, ya sea un navegador web o una aplicación, es un recurso que se comporta como cliente HTTP porque envía solicitudes a un servidor HTTP que se encarga de enviar respuestas al cliente.

EL GRAN ORÁCULO

A no ser que se indique otra cosa, toda esta información va a llegarte por el puerto 80 que es el estándar y el predeterminado que se utiliza en HTTP.

¿No sabes qué es un puerto? Imagínatelo como un gran puerto marítimo en el que van llegando barcos y el número indica el muelle de descarga y el tipo de mercancía que espera recibir. En el muelle 443 un barco traerá llaves, en el muelle 22 zapatos y en el muelle 80 libros y fotos.

Pues eso son los puertos informáticos (a muuuuuy grandes rasgos)

Una vez aclarados los conceptos básicos del HTTP hay que saber que existen diferentes formas de pedir y dar esta información.

Paradigma del cliente y del servidor

Para que toda esta red funcione es necesario que haya siempre alguien escuchando lo que necesitamos y aquí es cuando entra este modelo.

Como ya hemos visto antes, tu ordenador, tablet y smartphone sois los clientes y al otro lado hay un servidor que te facilita información. A nivel técnico cada uno de los extremos finales lo denominamos Hosts.

El cliente inicia el contacto con el servidor para solicitar un servicio, una vez que le llega la petición al servidor, este hará X operaciones con esa petición y al final de todo el servidor proporcionara una respuesta con la información pedida.

Puede ser un email, una página web, una fotografía o el acceso a un servicio expuesto.

Paradigma de entre iguales

También conocido como Peer to Peer o también conocido como “mierda, el eMule no me descarga”.

Cuando antes teníamos por definición una figura que siempre pedía y otra que siempre daba, con este paradigma todas las figuras piden y dan por igual.

Es como si en lugar de ir a una cafetería tradicional fueras a otra con autoservicio.

Con este paradigma se entiende que cada host puede entrar y salir de la red en cualquier momento, por eso pasamos a convertirnos en clientes y servidores a la vez.

Una ventaja crucial de este tipo de red es la escalabilidad.

Pero el protocolo HTTP también admite uno o mas protocolos de aplicación que utilizamos constantemente y sin saberlo.

Por ejemplo, cuando enviamos un email lo hacemos a través del protocolo SMTP. Cuando llamas a tu madre a través de Skype estas utilizando el protocolo de VoIP.

Así que para que termine de quedar claro, el protocolo HTTP puede utilizar muchos otros protocolos que van a definir el tipo de mensaje y la sintaxis que van a utilizar así como la información de los resultados.

Identificando aplicaciones

Cuando el proceso de comunicación tiene que ser realizado hay dos cosas que son importantes conocer.

  1. Dirección IP: es una dirección única y númerica del ordenador que va a ejecutar el proceso.
  2. Número de puerto: por dónde va a realizar la conexión. La combinación de dirección IP y número de puerto es lo que conocemos como socket.

Así pues volviendo al ejemplo del puerto marítimo y los barcos, cuando una empresa importa mercancías y contrata a un capitán de barco, este tiene que saber a que ciudad dirigirse y en que muelle atracar para cargar los productos para después saber a que ciudad de origen volver y en que muelle descargar.

Con esto, para que una conexión HTTP salga satisfactoria es necesario conocer los siguientes 4 datos:

  1. Dirección IP del cliente
  2. Número de puerto del cliente
  3. Dirección IP del servidor
  4. Número de puerto del servidor.

El protocolo HTTP utiliza el protocolo TCP para crear una conexión fiable entre el cliente y el servidor y todos los comandos que se utilizan dentro de este protocolo se envían en texto plano a través del puerto 80 (por lo general)

Hemos dicho antes que las direcciones IP son necesarias para establecer conexiones y también hemos dicho que son direcciones numéricas. Pero ¿cómo es posible que todos los días nos conectemos a facebook sin saber ni conocer a que dirección numérica tenemos que conectarnos?

Es una pregunta razonable ya que a lo mejor nunca en tu vida has visto una dirección IP.

Pues aquí es cuando entra otro actor mas en todo este panorama y se trata de los servidores de DNS. Algo así como el abuelete del pueblo que cuando paras con el coche para preguntar por una dirección sabe guiarte a la perfección hasta tu destino.

Un servidor de DNS se ocupa de traducir un nombre de dominio, en este caso facebook.com, a una dirección IP.

Si no existieran los servidores DNS las pasaríamos puta para navegar por Internet…

Las cosas se complican. Cuando antes solo tratábamos con el servidor para pedirle la foto de la chica con la entrada de los servidores DNS el camino hacia el recurso se alarga. Ahora tenemos que hacer lo siguiente:

  1. El cliente pregunta al servidor de DNS por la dirección de un nombre de dominio (wikibooks.org)
  2. El servidor DNS traduce wikibooks.org y le devuelve al cliente el valor 91.198.174.192
  3. El cliente monta una petición con esa dirección IP y la envía al servidor
  4. El servidor procesa la petición y devuelve una respuesta al cliente.

Internamente para una petición de consulta se hace lo siguiente:

GET 91.198.174.192/wiki/Communication_Systems/HTTP_Protocol HTTP/1.1

La primera parte de la consulta, la palabra “GET” es el comando HTTP a ejecutar. La segunda parte es la dirección URL del recurso que pedimos y la última parte es la versión del protocolo que va a utilizar la petición.

Cuando el servidor recibe la petición lo primero que va a hacer es respondernos si ha recibido bien o no la petición. Por lo general esperaremos siempre lo siguiente:

HTTP/1.1 200 OK

Esto significa que ha recibido la petición bien, pero si encuentras por ejemplo uno de los siguientes códigos ya puedes echarte a temblar…

HTTP/1.1 404 Not Found
HTTP/1.1 503 Service unavailable

Al igual que con la petición, la primera parte es la versión del protocolo a utilizar y la segunda parte de la respuesta es el número del código de respuesta junto con su mensaje en formato humano.

La web

Lo que conocemos como la Web o Internet no es mas que una gigantesca red interconectada de servidores que sirven recursos. Ya hemos comentado que esos recursos pueden ser de muchos tipos diferentes pero los típicos, las páginas web, no son mas que documentos escritos en HTML a los que accedemos a través de una URL.

Esquema básico del funcionamiento de la web

Esquema básico del funcionamiento de la web

Según los diferentes paradigmas, el usuario envía una solicitud de una página a un servidor dado a través de un navegador. Cada navegador tiene una firma a la que conocemos como User Agent que da información útil al servidor sobre quién ha hecho la petición.

Así pues, el HTTP es el protocolo de la capa de aplicación del modelo OSI que funciona con la tecnología Cliente-Servidor.

El servicio de transporte HTTP/TCP utiliza sockets para transferir datos.

El cliente inicia una conexión TCP utilizando sockets en el puerto 80 del servidor. A continuación el servidor acepta la conexión desde el cliente.

Nuevamente el cliente pide los recursos necesarios, en este caso los documentos HTML, las imágenes, los estilos… Una vez que el servidor le devuelve esta información, la conexión TCP es cerrada.

Como HTTP es un protocolo sin estado, no mantiene la información del usuario sobre las solicitudes anteriores. Así pues, este protocolo es muy simple pero si como programador quieres mantener el histórico de peticiones es posible que se te complique un poco la tarea.

Conexiones HTTP

Una página web está formada por una URL y por diversos objetos. Como puede haber uno o varios objetos o URLs, el tipo de conexión HTTP determina el orden en el que se solicitan los objetos.

Dado que la tecnología avanza a ritmo vertiginoso, el protocolo HTTP no podía ser menos y constantemente evoluciona para mejorar su rendimiento.

Existen diferentes tipos de conexiones HTTP:

  • HTTP/1.0: conexiones no persistentes. Esta conexión requiere que cada objeto sea entregado por una conexión TCP individual. Suele ser habitual un retardo en las entregas.
  • HTTP/1.1: conexiones persistentes. También llamadas HTTP keep-alive o HTTP Reuse. La idea es usar una misma conexión TCP para enviar y recibir múltiples peticiones y respuestas.

La principal diferencia entre una conexión persistente y otra que no es el número de conexiones TCP que se necesitan para transmitir los objetos.

Step by step de las conexiones

Step by step de las conexiones

Pero esto aún se puede enredar mas ya que dentro de las conexiones persistentes podemos encontrar la siguiente clasificación:

  • HTTP persistente sin pipelining: en este caso cada cliente tiene que esperar que el objeto previamente solicitado sea recibido antes de emitir una nueva solicitud para otro objeto.
  • HTTP persistente con pipelining: se permite que el cliente envíe todas las solicitudes de golpe por lo que el servidor las recibirá, las encolará y e irá devolviendo las respuestas una a una. Este es el método predeterminado en HTTP/1.1

Modelando el tiempo de respuesta

En todo este mundo de las conexiones HTTP entra en juego otro concepto clave y es el RTT. El RTT, conocido como Round Trip Time, es el tiempo transcurrido al enviar un paquete a un host remoto y recibir una respuesta.

Es un tiempo que utilizamos para medir el retardo en la red en un momento dado.

Este tiempo de respuesta indica el tiempo requerido para iniciar la conexión TCP y la siguiente respuesta o petición de vuelta que le cuesta llegar a un recurso.

Fíjate en la siguiente para entenderlo mejor.

Explicación de tiempo de respuestas durante el protocolo HTTP

Explicación de tiempo de respuestas durante el protocolo HTTP

Formato de los mensajes HTTP

Recapitulemos antes de desarrollar mas el tema.

Lo que conoces como Internet está basado en diferentes protocolos que indican cómo ha de enviarse la información.

Cuando tu quieres acceder a una página web, sigamos con el ejemplo de facebook, lo primero que va a hacer tu ordenador es enviar un mensaje a unos servidores DNS para preguntarles cual es la dirección IP de la página de facebook.

Una vez conseguida esa dirección IP, lo siguiente que va a hacer tu ordenador es enviar un mensaje a esa IP preguntando si puede conectarse, en caso de que el servidor conteste que si, que puede conectarse, tu ordenador va a enviar un segundo mensaje pidiendo el recurso solicitado y el servidor devolverá otro mensaje con ese recurso.

Bien, si hasta aquí esta todo claro pasemos a ver el formato de estos mensajes.

Existen dos tipos de mensajes, los mensajes de las peticiones y los mensajes de respuesta.

Mensajes de peticiones

Un mensaje de solicitud y/o petición tiene tres partes separadas por espacios, la primera el método o acción a realizar, la segunda el recurso pedido y la tercera la versión del protocolo que se va a utilizar.

El formato de los mensajes se escribe en ASCII para que pueda ser entendido por las personas.

Por ejemplo:

GET /path/to/the/file.html HTTP/1.0

El método GET es el mas utilizado, aunque no el único. Esto le indica al servidor que quieres obtener un recurso. La parte de la URL también se denomina URL de solicitud y el protocolo ha de estar siempre en mayúsculas.

A continuación puedes ver el esquema completo de un mensaje de petición.

Esquema de mensaje de petición HTTP

Esquema de mensaje de petición HTTP

Según el esquema, las líneas de cabecera o encabezado incluyen el tipo de navegador, el host, el número de objetos y el nombre del archivo y el tipo de idioma de la página solicitada. Por ejemplo:

Cabecera de una petición

Cabecera de una petición

Llegados a este punto tal vez te preguntes para que sirven el resto de campos del esquema del mensaje de petición ¿no?

Por ejemplo, cuando enviamos información a una página, al rellenar un formulario, esa información viaja en el cuerpo del mensaje bajo el método POST.

Y es que el protocolo tiene diferentes métodos o acciones a realizar.

Mientras que HTTP 1.0 solo tiene los métodos GET, POST y HEAD, la versión HTTP 1.1 tiene los métodos GET, POST, HEAD, PUT y DELETE.

Aunque esto ya se explicará mas adelante.

Mensajes de respuesta

Al igual que con los mensajes de petición, las líneas de respuesta de los mensajes HTTP también tienen tres partes separadas por espacios; la versión HTTP, un código de estado dando el resultado de la solicitud y una frase en inglés del código de estado.

Mensaje de respuesta HTTP

Mensaje de respuesta HTTP

Esta primera línea también se llama línea de estado.

Hay muchos códigos de estado que trataremos en un artículo a parte pero a continuación te dejo un par de ellos:

  • 200 OK: la solicitud se realizó correctamente y el recurso se devuelve en el cuerpo del mensaje.
  • 404 Not Found: el recurso solicitado no se encuentra.
  • 301 Moved Permanently: el recurso se ha movido permanentemente a otra URL.
  • 302 Moved Temporarily: el recurso se ha movido temporalmente a otra URL.
  • 500 Server Error: el servidor ha petado, revisa tus logs xD

Mecanismos para identificar al usuario en el servidor

El protocolo HTTP es un protocolo sin estado así que debería existir alguna forma de poder identificar a un usuario utilizando el servidor.

Ahora os voy a contar varias técnicas:

  1. Autenticación: siempre que el cliente solicita una página web al servidor, este mismo autentica al usuario pidiendo un nombre y una contraseña. Existe la necesidad de autenticación para que el servidor pueda tener control sobre los documentos. Esta autorización se realiza en la línea del encabezado de la solicitud.
  2. Cookies: también se utilizan para identificar a un usuario. Las cookies son pequeños trozos de datos que se guardan en el cliente y así el servidor es capaz de acceder a estas cada vez que necesita consultar esa información.

Pero… ¿Cómo funcionan las cookies?

Existen miles y miles de tutoriales hablando sobre las cookies pero un ejemplo claro para que lo visualices es el mensaje de la LOPD que te aparece en ciertas páginas obligándote a aceptar el uso de estas. Si lo aceptas cuando vuelvas a la web no volverás a ver el mensaje.

Eso está hecho con cookies.

Así pues las cookies tienen cuatro componentes principales:

  1. Línea de encabezado del mensaje de la respuesta HTTP.
  2. Línea de encabezado del mensaje de solicitud HTTP.
  3. Cookie propiamente dicha. Archivo almacenado en la máquina del usuario.
  4. Referencia a la web a la que pertenece.

Con esto podemos decir que las cookies las utilizamos para que una página web guarde información en el ordenador del cliente ya puedan ser unas credenciales, un carrito de compra u opciones de configuración entre otros usos.

Cuando vemos una cookie nos la podemos encontrar de dos sabores diferenes. Estas puedes ser persistentes o no persistentes.

Creo que es la diferencia es clara pero por si hay dudas, una cookie persistente es aquella que se almacena en el ordenador tanto tiempo como haya sido programada mientras que las cookies no persistentes desaparecen una vez que se cierra la página web de origen.

Pero gracias a estos mecanismos (cada vez mas puestos en duda) las páginas web, grandes empresas y gobiernos pueden trackear completamente al usuario así como sus hábitos de consumo digital.

Uno de los sectores que tanta mala fama ha dado a las cookies es el de la publicidad. Las empresas de anunciantes las han utilizado para obtener todos los datos posibles de los usuarios y así después poder segmentar los anuncios.

Cacheando la web con proxys

El principal objetivo del servidor proxy es satisfacer la solicitud del cliente sin involucrar al servidor web original. Este proxy es un servidor que actúa como un búfer entre el navegador del cliente y el servidor web.

El servidor proxy acepta las solicitudes del usuario y devuelve la información cacheada que pide el cliente. Si no encuentra el recurso que se está solicitando es cuando entonces se lo pide al servidor web original.

Funcionamiento de un proxy caché y GET condicionales

Funcionamiento de un proxy caché y GET condicionales

Los dos propósitos principales de un servidor proxy son:

  • Mejorar el rendimiento: a medida que va guardando el resultado de las solicitudes, cuando un nuevo cliente solicita un recurso que previamente ya se ha consultado es capaz de servirlo directamente desde la memoria caché del servidor. Esto hace que la velocidad de respuesta sea baja y la petición se pueda cumplir en menos tiempo.
  • Solicitudes filtradas: también se pueden utilizar para filtrar solicitudes, es decir, mediante un proxy se pueden restringir a los usuarios al acceso de un conjunto específico de sitios web.

Pero existen otros métodos para mejorar la velocidad de respuesta de las solicitudes y uno de esos métodos es el uso de los métodos GET condicionales.

Este método es el mismo que el GET visto hasta ahora, solo se difiere al incluir un campo en el encabezado con los siguientes posibles valores:

  • If-Modified-Since
  • If-Unmodified-Since
  • If-Match
  • If-None-Match
  • If-Range

Una solicitud del método condicional GET se satisfará siempre cuando cumplan las condiciones del nuevo campo del encabezado.

Este método se utiliza para reducir el uso de la red y para que las entidades de caché se puedan utilizar para satisfacer las solicitudes de los recursos si no han sido modificados y así evitar una transferencia innecesaria de datos.

Teniendo esto en cuenta, cuando un cliente pide una página web al servidor proxy, este comprueba que tenga la página pedida en su sistema de caché, comprueba la última fecha de modificación del encabezado y sirve el recurso.

Si la página pedida es modificada o cambia en el registro de caché el servidor proxy devolverá la página desde el servidor web principal. Una vez que el cliente ha recibido esta página modificada, el servidor web actualiza al servidor proxy para que así siempre tenga la última versión disponible.

Pues nada chachos, para ir terminando os dejo un par de recursos por si queréis ampliar información y si tenéis dudas podéis utilizar los comentarios o ponerme un tweet a través del siguiente banner 😉

Recursos:

https://en.wikibooks.org/wiki/Communication_Networks/HTTP_Protocol

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

@gorkakatua #faqsGorkamu pregúntame por twitter cualquier cosa y vemos cómo lo solucionamos.

Hala a cascarla!

¿Te ha parecido este un artículo de 5 estrellas? Dame tu valoración:
Review Date
Reviewed Item
Entendiendo el funcionamiento del protocolo HTTP
Author Rating
51star1star1star1star1star

Gorka Muñoz Andrés

Me llamo Gorka Muñoz y soy un desarrollador melómano. Combino a la perfección la búsqueda de nuevos grupos con la pasión por la tecnología. Desde chiquitito me ha gustado la programación, ahora que soy mayor estoy metido en el mundo del SEO sin olvidarme del /Dev.

This Post Has 0 Comments

  1. carlos

    pues va a ser verdad!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *