La Capa de Aplicación Protocolos de Aplicación Básicos mayo de 2008 DNS DNS (RFC 1034 y 1035) Idea básica: Cada nodo tiene un nombre único asignado a una dirección IP. El Sistema de Nombres de Dominio (DNS) proporciona el servicio de búsqueda. Un nombre de dominio es una ruta desde una hoja hasta la raíz. Un dominio es un subárbol en el espacio de nombres de dominio. mayo de 2008 2 1
DNS Registros de recursos Cada dominio puede tener una serie de recursos asociados. Tipo SOA A MX NS CNAME PTR HINFO TXT Significado Start Of Authority Dirección IP de un host Mail exchange Name Server Nombre Canónico Pointer Descripción del Host Texto Valor Parámetros de zona Entero de 32-bit Prioridad y dominio que acepta correo-e Servidor de nombres de este dominio Nombre del dominio Alias de una dirección IP CPU y SO (ASCII) Texto ASCII no interpretado mayo de 2008 3 DNS Servidores de Nombres DNS (I) Es imposible tener toda esta información en un solo servidor. Se implementa una solución distribuida y jerarquizada. Idea básica: Dividir el espacio de nombres en zonas, cada una de ellas con uno o más servidores de nombres. mayo de 2008 4 2
DNS Servidores de Nombres DNS (II) Puede haber varios servidores por zona. Generalmente los servidores secundarios secondary masters obtienen la información de los primarios primary masters. Un resolvedor es un programa auxiliar que se ejecuta en la máquina de usuario y envía peticiones DNS a un servidor para obtener la información. Esta resolución puede ser iterativa: mayo de 2008 5 Servidores de Nombres DNS (y III) O recursiva: DNS Esto no funcionaría ( por qué?) si no fuese porque se supone que los emparejamientos nombre-dirección raramente cambian, por lo que pueden mantenerse en caché. Cuando un registro proviene directamente de la autoridad que administra el registro se denomina registro autorizado. mayo de 2008 6 3
DNS Protocolo DNS (RFC 1034) El protocolo DNS es muy sencillo (conceptualmente). Opera en dos modos: Búsqueda: utilizando UDP/53 (recomendado). Transferencias de zona: utilizando TCP/53 para la propagación de registros. Cabecera Pregunta Respuesta Autoridad Adicional ID, Tipo de Operación, Respuesta Autorizada, Recursión solicitada, Recursión disponible, Código de respuesta, Número de registros del resto de los campos. Nombre de dominio, tipo de recurso y clase Nombre de dominio, tipo y clase del recurso, tiempo de vida, datos. mayo de 2008 7 DNS Resolución de direcciones (petición inversa) También es posible obtener en nombre de un nodo, conociendo su dirección IP. Para ello las direcciones IP se almacenan en el dominio especial in-addr.arpa. El resolvedor toma la dirección ip: 192.31.231.80 y la convierte en 80.231.31.192.in-addr.arpa. El registro PTR contiene el nombre. mayo de 2008 8 4
FTP Protocolo de Transferencia de Archivos FTP (RFC 959) Protocolo simple (basado en texto) para la transferencia de archivos entre máquinas en Internet. Se ejecuta sobre TCP. Maneja la diversidad presente en las redes multiplataforma: Distintas convenciones en los nombres de archivos (número de caracteres, extensiones, espacios, ). Distinta codificación de los archivos (ASCII, EBCDIC, binario, ). Acceso a directorios y permisos. FTP no proporciona ningún nivel de seguridad ni cifrado: nombres de usuario, claves y contenidos pueden ser husmeados, entre otros problemas. Alternativas seguras: SFTP (FTP seguro sobre SSH-2) FTPS (FTP sobre SSL) mayo de 2008 9 FTP: Funcionamiento FTP Usuario Interfaz de usuario Intérprete protocolo Conexión de control (FTP) 21 Intérprete protocolo Sistema de archivos Transferencia de datos Conexión de datos 20 Transferencia de datos Sistema de archivos Cliente Servidor mayo de 2008 10 5
TELNET Terminal Remoto TELNET (RFC 854 y ss.) TELNET = TELetype NETwork Protocolo sencillo para acceder en modo terminal de texto a un sistema remoto. Utiliza una arquitectura cliente/servidor mediante TCP en el puerto 23. Maneja la diversidad en las capacidades del terminal que esté utilizando el usuario: manejar colores, posicionar el cursor, códigos ANSI, Envía las pulsaciones de teclado que son interpretadas por el servidor y direccionadas al proceso remoto como si fuesen locales. Las respuestas son formateadas y enviadas al cliente. No implementa ningún mecanismo de seguridad. mayo de 2008 11 TELNET TELNET: Funcionamiento Cliente Telnet Servidor Telnet login shell driver terminal TCP/IP TCP/IP driver pseudoterminal Núcleo 23 Núcleo Usuario Conexión TCP mayo de 2008 12 6
Correo electrónico El correo electrónico (RFC 821 y 822) La arquitectura es sencilla: los agentes de usuario simplemente envían el correo a un servidor (estafeta) quien se encarga de su distribución al buzón (mailbox) del destinatario en otro servidor posiblemente remoto. Agentes locales o remotos SMTP Lectores locales o remotos POP3 o IMAP SMTP mayo de 2008 13 Correo electrónico Transferencia de mensajes El agente extrae el host de destino de la dirección de correo y utiliza DNS para buscar el servidor de correo asociado, a través de los registros MX. Ejemplo: Enviamos correo a chema@isa.uniovi.es el agente busca los registros MX para isa.uniovi.es: isa.uniovi.es CNAME hecate.edv.uniovi.es 172800s (2d) hecate.edv.uniovi.es MX preference: 40 exchange: llar.net.uniovi.es hecate.edv.uniovi.es MX preference: 10 exchange: aleph.net.uniovi.es hecate.edv.uniovi.es MX preference: 10 exchange: fluid.net.uniovi.es hecate.edv.uniovi.es MX preference: 30 exchange: llar2.net.uniovi.es Ahora toma el usuario (chema) y prueba a depositar el mensaje en su buzón para cada una de esas máquinas hasta tener éxito. mayo de 2008 14 7
Correo electrónico Formato de los mensajes No se establece nada al respecto del contenido de los mensajes. Sólo se especifica la cabecera (RFC 822): Campos relacionados con el transporte de mensajes: To, CC, Bcc, From, Sender, Received y Return-Path. Campos para el agente de usuario: Subject, Date, Reply-To, etc. Campos de uso privado: comienzan con X-, de forma que es posible (como ocurrió, de hecho) agregar campos nuevos en un futuro. mayo de 2008 15 Correo electrónico Extensiones MIME (RFC 2045-2049) El correo electrónico original consistía exclusivamente en mensajes de testo ASCII. Hoy en día esto ya no es adecuado: Soporte para idiomas con acentos (español, francés o alemán) o alfabetos no latinos (ruso o hebreo) o sin alfabetos (japonés o chino). Soporte para mensajes que no contienen sólo texto (imágenes, audio o vídeo). Se propone una solución que sigue utilizando el formato RFC 822, pero agrega una estructura al cuerpo del mensaje y define reglas para codificar mensajes no ASCII: Extensiones Multipropósito de Correo de Internet o MIME. Cabecera MIME-Version Content-Description Content-Id Content-Transfer-Encoding Content-Type Significado Versión MIME Cadena indicando qué hay en el mensaje Identificador único Cómo está codificado el contenido Tipo y formato del contenido mayo de 2008 16 8
Correo electrónico Transferencia de mensajes: (E)SMTP (RFC 2821) SMTP Simple Mail Transfer Protocol. Se basa en un modelo cliente/servidor entre servidores de correo. El protocolo es ASCII y muy sencillo. Utiliza TCP y el puerto 25 para el servidor. mayo de 2008 17 Correo electrónico Lectura del correo en el buzón. POP3 (RFC 1939) Para leer el correo en un servidor se utiliza el agente de usuario quien se comunica con el servidor a través de un protocolo. POP3 es uno de ellos. mayo de 2008 18 9
Correo electrónico Lectura del correo en el buzón. IMAP (RFC 2060) POP3 supone que el correo se descarga al equipo del usuario. Para mantener y organizar el correo en el servidor se diseñó IMAP. Puerto TCP Múltiples buzones Descarga parcial Soporte Característica Dónde se almacena el correo? Cómo se lee el correo? Tiempo de conexión Bueno para usuarios móviles? Protocolo simple? 110 Off-line Poco No No No Sí Amplio POP3 PC de usuario Servidor On-line Mucho No tanto, pero aumentando mayo de 2008 19 143 Sí Sí Sí No IMAP Arquitectura de WWW El cliente (navegador) establece conexiones con el servidor para descargar cada objeto de una página web y muestra la información de modo gráfico. El texto se formatea según el lenguaje HTML. El protocolo utilizado para la transferencia es HTTP. Los enlaces son indicadores a otros recursos (posiblemente en otras máquinas). mayo de 2008 20 10
Localizadores Uniformes de Recursos URL (1738) Los recursos se especifican con un formato denominado URL (Tim Berners- Lee 1991). En 1994 se incorpora dentro del más general URI (Identificador Uniforme de Recurso), aunque se sigue usando URL ampliamente. esquema://autoridad/ruta?consulta#fragmento En HTTP se usa típicamente: protocolo://usuario:clave@dirección:puerto/ruta?parámetro=valor#enlace mayo de 2008 21 URL Ejemplos mayo de 2008 22 11
Cookies (RFC 2109) Nota: La Web es sin-estado: los servidores no siguen la actividad de los clientes. En algunos casos esto es necesario (comercio electrónico, configuración personal, ). Solución: Enviar una cookie al cliente, con la información relevante que el cliente pueda devolver cuando sea preciso. mayo de 2008 23 Páginas web dinámicas Esencia: Permitir que un servidor pueda generar una página web sobre la marcha, para incorporar elementos dinámicos, como consultas a bases de datos. mayo de 2008 24 12
Páginas web dinámicas con scripts Alternativa: Que las páginas web incluyan código que pueda ser interpretado (ejecutado). Este procesamiento puede hacerse en el cliente o en el servidor. mayo de 2008 25 Servidores Web (I) Muchos servidores tienen que procesar muchas peticiones simultáneamente mayo de 2008 26 13
Servidores Web (y II) Y si no es suficiente capacidad de proceso?: utilizar granjas de servidores mayo de 2008 27 Redes de distribución de contenido Idea: Instalar servidores a lo largo de todo Internet donde replicar los recursos más pesados. Redireccionar a los clientes a los servidores de réplicas más cercanos. mayo de 2008 28 14
Usando Proxies y Caché mayo de 2008 29 Conexiones Persistentes Observación: HTTP supone que se utiliza una conexión diferente para obtener cada recurso. Esto supone una sobrecarga importante. Idea: No se podría usar una sola conexión para manejar varias peticiones/respuestas? Esto aparece en la versión 1.1 de HTTP (RFC 2616). Se utiliza la cabecera Connection con valor close o keep-alive. Las peticiones se pueden enviar en grupos antes de esperar por las respuestas: pipelining mayo de 2008 30 15