Múltiples fuentes consideran que la Web es la tercera tecnología de las comunicaciones que mas impacto social ha tenido tras el teléfono y la televisión. Desde crónicas de un informático se ha considerado interesante describir el protocolo HTTP de una forma esquemática que permita al lector profundizar en dicho protocolo.
Potencia de HTTP
La potencia de HTTP se basa en la combinación de los siguientes aspectos:
Hyptertext: Sistema que permite a documentos relacionados enlazarlos entre ellos mismos u otros documentos
Document format: Combinación de texto mas multimedia
Protocolo especial: Permite el movimiento de todo este tipo de información
Componentes de HTTP
HTML: Lenguaje de texto que define documentos de tipo hypertext. Mediante el empleo de etiquetas permite dar formato a la información así como enlazar documentos entre sí. En definitiva, define un conjunto completo de códigos de texto que describen prácticamente todos los aspectos de como un documento se muestra a un usuario. (Color, tamaño, tabulaciones…). El texto empleado es ASCII estructurado, acorde a las reglas de dicho lenguaje.
HTTP: Protocolo de la capa de aplicación TCP/IP que permite la transferencia de documentos de tipo Hypertext entre un cliente y un servidor
URI: Método de definición de etiquetas que identifica los recursos en internet de tal forma que pueden ser encontrados y referenciados.
Servidores Web: Permiten proveer documentos de hypertext a los clientes que solicitan.
Navegadores Web: Software instalado en el equipo cliente que permite el acceso a los documentos web que se encuentran en los servidores web.
URI
Surgen bajo la necesidad de que un recurso pueda ser únicamente especificado a través de una cadena compacta y simple. Pueden ser de dos categorías:
- URL (Usadas por los servidores web)
- URN (En desarrollo)
URL
Especifican el uso de HTTP para aceso a los recursos “HTTP URLs”. Permiten identificar de manera inequívoca un documento, imagen o un fichero multimedia entre otras. Pueden ser absolutos o relativos y se componen de:
- Hostname
- Path
- Nombre de archivo
El siguiente ejemplo permite comprender la estructura de una URL:
http://www.cronicasdeuninformatico.es/aaaa/objeto.html
http = sería como se transmite
cronicasdeuninformatico.es = Hostname
aaaa = Subdirectorio
objeto.html = Nombre del archivo al que se le hace referencia
La estructura de una URL absoluta es la siguiente:
(esquema) : // (usuario) : (password) @ (equipo) : (puerto) / (url-path) ; (parámetros) ? (query) #
(usuario) : (password) = Raramente se usan
(puerto) = Por ejemplo, puerto TCP 80
Lo normal es que se emplee una URL de este tipo:
http :// cronicasdeuninformatico.com / objeto.html
El URL path se suele omitir ya que se suele reconocer por defecto índex.html y default.html En caso de emplearse URL relativas, el objetivos es enlazar documentos cercanos y relacionados que pueden pertenecer a un mismo proyecto. Solo se especifica una pequeña porcion del URL Path.
URN
Tal y como se ha indicado con anterioridad, este tipo de URIs se encuentran en desarrollo. La diferencia básica con respecto a URL radica en que URN no proporciona información acerca de la ubicación del objeto final.
Descripción del protocolo HTTP
HTTP se implementa en el programa cliente y del servidor. Cliente y servidor intercambian mensajes HTTP. El protocolo HTTP define la estructura de estos mensajes así como el método de intercambio de dichos mensajes entre el cliente y servidor. Todos los navegadores y servidores implementar las versiones HTTP / 1.0 y HTTP / 1.1″Esta versión es retrocompatible con la 1.0″ Ambos emplean TCP
Glosario básico
Página Web: Conjunto de objetos. Generalmente sueles ser ficheros bases html y objetos referenciados.
Objeto: Fichero simple (HTML, GIF, JPEG, etc.)
Navegador: Se encuentra en la parte del cliente y permite mostrar las páginas web solicitadas por el cliente. Se puede parametrizar las opciones del navegador.
Servidor Web: Contiene los objetos web identificados por las URLs. Se encuentra en la parte del servidor HTTP.
HTTP Request: Se produce cuando un usuario solicita una página web. El navegador envía un HTTP request para los objetos ubicados en esa página del servidor.
HTTP Response: El servidor que recibe la solicitud responde con los objetos contenidos
Proceso de comunicación
- El cliente establece una conexión TCP con el servidor
- Se establece la conexión
- Se envía un HTTP request a su socket y a través del mismo recibe un HTTP response
- De la misma forma, el servidor recibe desde su socket HTTP request y envía HTTP response
Los mensajes están en manos del protocolo TCP el cual garantiza que lleguen intactos y que no se pierdan los paquetes. HTTP es un procotolo sin estado ya que no almacena información del estado del cliente
Tipo de conexiones
HTTP /1.0 las conexiones no son persistentes
HTTP /1.1 las conexiones son persistentes
Conexiones no persistentes: Cada conexión TCP se cierra después de que el servidor envía el objeto. Cada conexión TCP transporta exactamente un request y un response. El proceso de conexión se produce de la siguiente manera:
- Se establece la conexión
- HTTP Request
- HTTP Response
- Servidor solicita cerrar conexión
- El cliente recibe la respuesta y cierra la conexión
- Se repite el proceso por cada objeto
El usuario puede configurar el navegador para definir conexiones paralelas. Para comprender el siguiente diagrama es necesario describir el concepto de RTT. RTT es el tiempo que tarda un paquete desde el cliente al servidor y que vuelva al cliente.
Los principales problemas de este tipo de conexiones son los siguientes:
- Una conexión por cada objeto
- Se requieren 2 RTT por cada objeto “1 RTT para establecer la conexión + 1 RTT para obtener un objeto”
- Cada conexión tiene estado ya que comienza con retardo.
Conexiones persistentes: El servidor mantiene la conexión abierta después de enviar los objetos. De esta forma, las siguientes peticiones se pueden enviar por la misma conexión. Las conexiones se acaban cerrando por tiempo de inactividad. Puede ser de dos tipos:
- Sin Pipelining: El cliente realiza una nueva petición solo cuando la respuesta anterior ha sido enviada. De esta forma se produce un RTT por conexión con el servidor + 1 RTT por cada objeto. La conexión queda abierta hasta recibir todos los objetos.
- Con Pipelining: El modo configurado por defecto, realiza una petición tan rápido como encuentre un objeto. Cuando el servidor recibe la petición envía el objeto. 1RTT por cada objeto reverenciado. Se define un tamaño de ventana. Las conexiones se cuelgan durante menos tiempo. y existen menos retrasos debido a que aumenta la tasa de datos.
Ejemplo sin Pipelining “Html + 1 fotos + 1 foto fuera”
Ejemplo con Pipelining “Html + 2 fotos + 1 foto fuera”
Tipos de mensajes HTTP
HTTP Request
Escrito en texto ASCII, 5 líneas seguidas de un retorno de carro y una línea. La primera líneas es request line, las siguientes headers lines. Un ejemplo de este tipo de peticiones sería el siguiente:
Get /directorio/objeto.html HTTP /1.1 “Esta línea sería la request line”
conecction close => Indica que no se quieren conexiones persistentes
accept => Indica los objetos que acepta el navegador.
El método post se emplea para rellenar formularios y los campos viajan en el body. El método Head permite comprobar el estado. El servidor devuelve un mensaje HTTPD ok.
HTTP Response
La respuesta enviada por parte del servidor. Contiene los siguientes campos entre otros:
- Entity body: Contiene el objeto solicitado
- Status line: Versión del protocol, código de estado y mensaje. Ej: HTTP1.1 200 OK
- Header lines: Contiene información de la conexión, fecha, tipo del servidor, cuando se modifico la última vez, tamaño y el tipo de contenido.
Métodos de identificación
A veces es necesario identificar a los usuarios para restringir el acceso, servir el contenido en función del tipo de usuario. Todas estas acciones se pueden realizar empleando autenticaciones y cookies.
Autenticación
El cliente envía un request y el servidor responde que requiere autenticación “Mensaje 401″así como información de como se deberá de realizar la autenticación. El cliente posteriormente envía usuario y contraseña con cada petición de los objetos en el campo http://www.authenthicate.
Cookies
El servidor envía una cabecera set-cookie con un identificador. El cliente almacena en su equipo dicha información. Cuando el cliente vuelve a enviar una solicitud incluirá dicho cookie. Este método impide saber quien es el usuario pero se conocen las peticiones que realiza dicho usuario. Se emplea para los siguientes casos:
- Almacenar la información de un usuario y no volver a enviar la contraseña y usuario cada vez.
- Guardar las preferencias de un usuario
- Para emplear mecanismos de tipo “carrito de la compra”
Cacheo Web
Se puede emplear en el equipo cliente o en un servidor intermedio. Si se emplea en un equipo cliente, se reduce el tiempo pero se introduce un problema si un objeto ha caducado. Para estos casos se emplea el método Get Conditional “Get + if-modified-since”. Solo envía el objeto si se ha modificado posteriormente a la fecha enviada.
Por el contrario si se emplea un web cache o servidor proxy, los usuarios configurarán sus navegadores para que primero pasen por el dispositivo intermedio. Estos dispositivos de tipo cache, tienen sus propios discos duros donde almacenan los objetos solicitados recientemente. Si el dispositivo intermedio contiene el objeto se lo devuelve al cliente. En caso de no tenerlo, abre una conexión con el servidor web y solicita el objeto. Cuando lo obtiene, lo almacena y se lo devuelve al cliente. De esta forma se obtienen los siguientes beneficios:
- Reducen el tiempo de respuesta de los clientes
- Reducen el tráfico
- Distribuyen la información mas rápidamente.
- Se pueden realizar cluster de cache o web cache
Destacar que se ha creado un protocolo de nivel de aplicación denominado ICP “Internet Cache Protocol”, el cual permite a un dispositivo de tipo cache preguntarle a otro si tiene un objeto.
Calcular los retrasos
Se pueden calcular los retrasos mediante la siguiente fórmula:
(Peticiones por segundo * tamaño medio por petición) / ancho de banda de la línea
Cuanto mas se aproxime el valor resultante a 1, peor será el resultado.
Nota: Internet Delay el el tiempo que tarda un proveedor de servicios de internet o ISP en contestar.
Notas finales
La mejor forma de comprender como se comporta el protocolo HTTP consiste en analizarlo en acción. Para ello se recomienda emplear una herramienta de tipo “Sniffer” como Whireshar, y realizar peticiones HTTP. De esta forma si se filtran las peticiones HTTP se podrán apreciar los mensajes que se han descrito en este artículo.
Para comentar debe estar registrado.