¡Descarga Tema 5, Servidores HTTP y más Apuntes en PDF de Informática solo en Docsity!
Tema 5: Servicio HTTP.
Índice de contenido
5.1. Introducción.
HTTP: Hyper text Transfer Protocol. Protocolo de la capa de aplicación que permite el acceso a hipertextos de forma remota en sistemas conectados en red TCP/IP. Sigue el modelo cliente-servidor. HTTP es la base de www (World Wide Web). www: Es un servicio de acceso a información distribuida en servidores por Internet e identificados por URLs. Estos recursos están conectados entre sí por hiperenlaces. A la hora de posicionar las distintas páginas en los buscadores se utiliza como criterio el número de enlaces que la apuntan. Ejercicio: Búsqueda en Internet y documentarse sobre: Page rank XHTML CSS www.w3.org: Buscar estándares que desarrolla / w3c de la A a la Z. www.w3c.es: Documentos y guías www.w3c.es/Divulgacion/GuiasBreves www.w3c.es/Divulgacion
5.2. Componentes del servicio HTTP.
El servicio web tiene las siguientes componentes: Recursos: Documentos, imágenes, sonidos,.. Nombres y direcciones: URL. Permiten localizar los recursos. Clientes web. Navegadores. Permiten acceder a los recursos contactando con los servidores. Servidores web. Software que gestiona los recursos para ofrecerlos a los clientes. Proxies web (directos e inversos). Intermediarios entre cliente y servidor. Pueden actuar como cortafuegos, almacenamiento temporal en caché lo que aumentaría el rendimiento del sistema,.. Protocolo HTTP. Normas que permiten la comunicación entre cliente, servidor y proxies. Utiliza TCP como protocolo de transporte. HTTP es un protocolo de la capa de aplicación (Whatsapp se ‘monta’ sobre un protocolo basado en XMPP que a su vez se encapsula sobre HTTP, con lo que podemos decir que HTTP es un protocolo de la capa de aplicación básico) Tecnología web. Basándose en la web se ha desarrollado toda una serie de tecnologías que partieron de HTML y que incluyen XHTML, CSS, XML, Ajax, jQuery, CPath, RDF,..
5.2.1 Nombres y direcciones.
URI: Universal Resource Identifier. Cadenas de caracteres que permiten identificar unívocamente los recursos en la red. El conjunto de esos recursos conectados entre sí forma la web. Para acceder a esos recursos se utilizan esquemas como : HTTP, FTP,.. URL: Universal Resource Locator, es un tipo de URI. Diferencia entre URI, URL y URN: Un URL es un URI que identifica un recurso y también proporciona los medios para localizar el recurso mediante la descripción de la forma de acceder a él URI C URL (incluye) Un URL es un URI Un URI no es necesariamente una URL Un URN sólo define un nombre, no proporciona detalles acerca de cómo obtener el recurso en una red. Puedes obtener una «cosa» a través de una URL, usted no puede conseguir cualquier cosa con un URN En general, si el URL describe tanto la ubicación y el nombre de un recurso, el término a utilizar es URI. Básicamente, un URI es igual a la suma del URL y del URN URN, ejemplo: isbn:0451450523 to identify a book by its ISBN number. Ej: http://193.28.223.87/pagina.html http://miaula.asir.es:8080/datos/practica1.html http://biblio.asir.es/buscalibro.php?curso=2ESO&tema=historia http: esquema biblio.asir.es: dominio buscalibro.php: ruta de acceso al recurso desde la raíz ?curso=2ESO&tema=historia: parámetros enviados.
5.2.2 Páginas, sitios y aplicaciones web.
Página web: documento hipermedia que suele tener enlaces a otras páginas. Están escritas en lenguajes que son interpretados por los navegadores: XHTML, CSS, Java-script, Flash,.. Su contenido puede ser estático o dinámico.
5.2.4 Cliente web.
Los clientes web o navegadores son programas que permiten acceder a recursos disponibles en la red. Pueden actuar como clientes de diversos protocolos, aunque su función principal es con HTTP. Si los recursos que recibe no los puede interpretar puede redirigirlos a una aplicación externa capaz de gestionarlo o preguntar al usuario. Se mantiene en caché las direcciones por las que se navega, recursos procesados, contraseñas,... Aunque W3C crea estándares para las tecnologías web, no todos los navegadores cumplen totalmente con ellos. Eso implica un problema para los desarrolladores de aplicaciones web. Como consecuencia una misma aplicación puede producir resultados distintos dependiendo con el navegador que se abra, e incluso según la versión. Navegadores más utilizados: Internet Explorer. Mozilla Firefox. Google Chrone. Chromium Safari Opera Navegadores en modo texto: Linx, Links,.. Existe una fuerte rivalidad entre los fabricantes de navegadores para ganar cuota de mercado, constantemente mejoran: velocidad, seguridad,.. Un cliente web, navegador o browser, tradicionalmente tiene como función primordial gestionar la transferencia hacia el cliente desde un servidor http, sin embargo en la actualidad tiene, entre muchas otras, dos funciones muy importantes: Ejecutar código en el cliente e implementar medidas de seguridad que protegen al cliente y al servidor.
5.2.5 Proxy web.
El proxy web o proxy HTTP hace de intermediario entre el cliente y el servidor web. Según el comportamiento y función puede ser directo o inverso: a) Proxy directo. Recibe una petición del cliente y la traslada al servidor web. La petición del cliente es hacia el servidor web. El proxy es intermediario o representante del cliente. Optimiza y controla el acceso a redes externas. El servicio típico obtenido es un servicio de Cache, para el cliente. Para el administrador de la red, mayor control de las acciones de los usuarios en particular y de las aplicaciones internas en general.
b) Proxy inverso (reverse proxy). Recibe la petición de un cliente y la envía a uno o varios servidores web. La solicitud del cliente es hacia el proxy, que para el cliente es un servidor web normal. Se utiliza para: Acceder a servidores que estén detrás de un cortafuegos y no son accesibles directamente. Balanceo de carga de varios servidores. Aumentar la velocidad de acceso ofreciendo una caché. Puede ofrecer acceso a diferentes servidores web, desde la misma URL. La mayoría de los proxies tienen caché donde se recogen los últimos accesos. Esto permite aumentar la velocidad de respuesta y reducen el tráfico por la red. Se puede configurar como cortafuegos: filtrar tráfico no deseado, control de acceso de usuarios, priorizar contenidos,... Otros tipos de proxy están orientados a otros servicios: FTP, SMTP,.. Ejercicio : Cloudflare. Define qué tipo de servicio presta. Ventajas de utilizarlo en tu propia aplicación web. Ejemplos de uso. Voluntario : Implementa el servicio básico en alguna web propia existente o creada al efecto. Dudas surgidas en clase (proxy transparente forticlient del Ayuntamiento) https://docs.mitmproxy.org/stable/howto-transparent/
procesada correctamente. ◦ Texto explicativo del código de estado. b) Líneas de cabecera. ◦ Conjunto de pares: nombre/valor que describen los datos y la forma de enviarlos al cliente. Ej: content-type: text/html indica que se envía código HTML que ha de interpretar el navegador. ◦ Si no hay cabecera se envía un 0. ◦ Cada cabecera 1 línea. ◦ Detrás de la última cabecera va una línea en blanco. c) Cuerpo del mensaje. Es opcional. Las imágenes no se envían directamente en el código html. Para las imágenes se utiliza la etiqueta img: Cuando el navegador recibe una etiqueta img comprueba si ya la tiene en caché y si no realiza otra petición HTTP. Esto puede ocurrir con otros elementos usados en lenguajes para crear webs y aplicaciones. Cuando el navegador recibe un recurso, puede desencadenar múltiples peticiones http a otros recursos. Los mensajes de petición y respuesta se pueden ver desde el navegador añadiéndole los plugins adecuados: Firefox: Firebug. Chrome: espia http Internet explorer: DebugBar En cualquier caso una vez en el navegador F12 (web developer tools) muestra mensajes sobre la comunicación y el documento http, php, asp,.. Buscar la ficha de “red” y “doc” Aunque también podemos preguntar a google: “herramientas para visualizar solicitud http”, para
conseguir algo más actualizado. Otra herramienta online y gratuita para ver las cabeceras y comprobar la seguridad de un sitio: SecurityHeaders. Además nos ofrece que cabeceras podríamos añadir desde nuestro servidor para mejorar la seguridad de nuestra web. Métodos de petición. Ver: https://www.ionos.es/digitalguide/hosting/cuestiones-tecnicas/http-request/ Especifican la operación que quiere realizar el cliente. HTTP 1.1 contempla 7 métodos: GET, POST, OPTIONS, HEAD, PUT, DELETE y TRACE. GET Permite descargar cualquier tipo de información/recurso del servidor. Se invoca al poner una URL en el navegador, hacer clic en un hiperenlace o enviar un formulario GET. Permite enviar parámetros al servidor en la URL: ◦ Se añaden detrás del recurso separados por “?”. ◦ Diferentes parámetros se separan por “&”. ◦ Los espacios en blanco se sustituyen por “+”. Ej: www.asir.es/datos.php?nombre=Felipe&curso= Los parámetros se incluyen en la línea inicial de petición. Las peticiones GET no envían cuerpo de mensaje. No se puede usar para subir ficheros u otras operaciones que requieran enviar gran cantidad de datos al servidor.
OPTIONS
Solicita al servidor información sobre las opciones de comunicación disponibles en un recurso determinado. Con el método OPTIONS, el cliente puede preguntar al servidor qué métodos soporta para el archivo de que se trata. OPTIONS /download.php La respuesta podría consistir en algo parecido a esto:
En el campo “allow” el servidor informa al cliente de que soporta los métodos OPTIONS, GET, HEAD y POST. En el campo “content-length”, la cifra 0 indica que no se ha enviado ningún archivo, sino solamente el encabezado. HEAD Recupera sólo las líneas de cabecera de una página web con información sobre un recurso. Similar a GET, pero el servidor solo devuelve las cabeceras. Usado para: implementar caches de navegadores, informar al usuario del tamaño de recurso antes de obtenerlo.
Cabeceras. Las cabeceras son parámetros (pares nombre/valor), que se pueden incluir en los mensajes de petición y respuesta HTTP. Definen información y meta-datos sobre: Los datos que se intercambian cliente-servidor. Los propios clientes y servidores. Las propias transferencias. Tipos de encabezados HTTP: Generales: Definen información que podrá ser usada tanto por clientes como por servidores. Se aplican a una sesión completa. Ej: Cache-Control Date Transfer-Encoding De petición: Utilizadas por los clientes para enviar información al servidor. Ej: User-Agent Navegador Host Nombre y puerto del servidor MIME Compresión, capas de caracteres, idioma del navegador Cookies De respuesta: Utilizado por el servidor para enviar información al cliente. Ej: Age Edad de la respuesta Retry-After Si un recurso no está disponible, la fecha en la que se espera que esté Server Tipo de servidor www-authenticate Si el servidor necesita identificación para responder a un recurso pedido. De entidad: Información relacionada con el recurso que se va a proporcionar al cliente. Ej: Content-Encoding Codificación Content-Language Idioma Content-Length Tamaño MIME HTTP 1.1 define 46 tipos de cabeceras. La cabecera Host es obligatoria en las peticiones. Las aplicaciones web pueden definir sus propias cabeceras para añadir información adicional a los mensajes HTTP, se utiliza el prefijo X- (para indicar que no es una cabecera estándar). Ejercicio (voluntario): Busca información sobre las cabeceras HTTP 1. De almacenamiento caché. Los servidores suelen tener información que no cambia constantemente. HTTP soporta almacenamiento en caché, de forma que no tenga que descargar algo que ha descargado recientemente. Esto afecta tanto a navegadores como a proxies. Se definen cabeceras que permiten controlar qué se almacena en caché, cuanto tiempo y qué no se puede almacenar. Ej: información que cambie constantemente: resultados de un partido de baloncesto. Es decir, si se puede o no cachear en proxy.
De compresión. Antes de enviar los recursos se pueden comprimir, con gzip por ejemplo. Esto reduce el tráfico en la red y los tiempos de respuesta. Accept-encoding: Esta cabecera, en solicitud indica la codificación que soporta el cliente. Content-encoding: El servidor indica que codificación ha utilizado. De cookies. Fragmento de información que envía el servidor en su respuesta http. El navegador puede almacenarlo para su uso futuro o no. En los siguiente accesos a esa página el navegador puede enviar la cookie al servidor. Cabeceras: cookies y set-cookies En las cookies se incluyen detalles como: Nombre de cookie. Name Texto de la cookie. Value Fecha y hora expiración. Expire Lugar donde ha de guardarse Path Dominio de procedencia Domain Cuando el navegador va a hacer una solicitud, consulta sus cookies y si tienen alguna que coincida con la ruta, dominio de la solicitud y no esté caducada, la envía. Mediante las cookies los servidores pueden identificar a los usuarios y sus conexiones y actuar en consecuencia. HTTP es un protocolo sin estado: cada transferencia de datos es independiente de las anteriores, no guarda relación entre ellas. Mediante las cookies permite: Que recuerde al usuario y contraseña de una vez para otra, o durante una sesión al cambiar de páginas. Que en determinadas páginas se muestren anuncios personalizados. El navegador se puede configurar de forma que: Permita cookies. Bloquee las cookies. Borre las cookies almacenadas. Ejercicios: Busca información sobre cookies (wikipedia). Navega por distintas webs y busca la configuración del navegador que muestre las cookies registradas. Configura el navegador para tratamiento de cookies. ¿Que es de-net-track? Normativa europea: ¿Cómo se rastrean y controla a los usuarios en Internet?
◦ Content-Transfer-Encoding ◦ Content- Type Estas cabeceras y tipos MIME los utilizará HTTP en: a) Mensajes de respuesta del servidor para que sean tratados adecuadamente por el navegador: abrirlo con la aplicación correspondiente o avisar al usuario de qué hacer. b) Mensajes de petición del cliente, avisando que tipos MIME puede aceptar. c) Encapsular uno o más recursos en un mensaje utilizando un tipo MIME especial: multipart. Ej: visitar página iana.org para buscar tipos MIME y códigos de transferencia existentes.
5.4. Seguridad.
HTTP no es seguro. El intercambio de información se hace con texto plano. Es vulnerable a análisis de tráfico de red: sniffing. La identificación Basic y Digest es débil Explicación: https://diego.com.es/autenticacion-http
ANEXO: archivo .htaccess en apache, que básicamente realiza un override (modificación posterior) a los archivos de configuración de apache (apache2.conf) No tiene sentido en todos los servidores HTTP https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/ Se utiliza para (https://computerhoy.com/noticias/internet/que-es-htaccess-que-sirve-codigos- fundamentales-76211) Redirecciones Personalizar páginas de error Bloquear usuarios/bots no desados Evitar el hotlinking SEO Ocultar extensiones de scripts Sobre todo reescribir urls (paginaweb.com?articulo=33&lang=es->paginaweb.com/es/maletin-de-herramientas->es.maletin- de-herramientas.paginaweb.com)
etcétera Proteger el acceso a archivos/directorios BASIC To password protect a directory served by Apache, you need a .htaccess file in the directory you want to protect and a .htpasswd file that can be anywhere on your system that the Apache user can access (but put it somewhere sensible and private). You most likely do not want to put .htpasswd in the same folder as .htaccess. The .htaccess file may already exist. If not, create it. Then insert: AuthType Basic AuthName "Your authorization required message." AuthUserFile /path/to/.htpasswd Require valid-user Then create a .htpasswd file using whatever username and password you want. The password should be encrypted. If you are on a Linux server, you can use the htpasswd command which will encrypt the password for you. Here is how that command can be used for this: htpasswd -b /path/to/password/file username password Nota: El fichero .htpasswd no tiene porque llamarse así, puede llamarse pepito-perez, en todo caso se coloca fuera del ámbito del directorio root del sitio web DIGEST Prácticamente igual: You do not need to do more than just change your AuthType from Basic to Digest. You need to create a new htpassword file using the htdigest tool. Ejemplos típicos de uso index.php imagen.png | includes | |conexion_bd.php |config.php admin | index.php ficheros_relacionados.php basic o digest para los subdirectorios marcados en rojo Fin de anexo
Hay tres técnicas: Alojamiento virtual basado en IPs (el quid es que una tarjeta de red puede tener varias direcciones IP, que por lo tanto una máquina puede tener varias direccciones IP). Alojamiento virtual basado en nombres. Alojamiento virtual basado en puertos. Alojamiento virtual basado en IPs. El servidor ha de disponer de una IP por cada servidor web virtual. Los usuarios verán varios servidores webs, cada uno con su propia IP. Esta configuración requiere que el servidor tenga una tarjeta de red por cada IP o que el SO permita que una tarjeta tenga más de una IP (alias o interfaces virtuales), cosa que soportan los actuales SO. Escenario típico de uso: VPS, máquinas virtuales y contenedores Ejercicios: Buscar información sobre ifconfig o sobre /etc/network/interfaces y configurar una tarjeta con dos ips en Debian. Opciones avanzadas de las propiedades de ipv4 y configurar una tarjeta con 2 ips en W7. En los servidores DNS se apuntará con cada domino a una IP diferente. Alojamiento Virtual basado en nombres. El servidor permite alojar varios dominios en una única IP. Cada servidor virtual atiende sus propias peticiones. En el servidor DNS se asocian los distintos nombres de domino de cada página a la misma IP. El usuario ve distintos servidores webs. El servidor web es capaz de diferenciar el nombre de dominio por el que se pregunta porque en el mensaje de petición HTTP del cliente se envía la cabecera Host con el nombre del dominio. Escenario: Multihosting o hosting compartido Si buscamos la dirección IP de guadalpin.es mediante (hay cientos) https://ipinfo.info/html/ip_checker.php https://dnslytics.com/reverse-ip y una vez obtenida (188.164.198.77) comprobamos si hay más webs alojadas allí mediante (hay varias) https://reverseip.domaintools.com/
y comprobamos que sí. F12 (web developer tools) y realizamos un GET a guadalpin.es y a otro dominio alojado en esa misma dirección y finalmente navegamos hacia la dirección IP ‘desnuda’ encontrada. Accediendo a guadalpin.es accediendo a algarabiaeventos.com
