Redes de ordenadores
Capítulo 2
Capa de aplicación (aplication layer)
(principios de nivel de aplicación. Servicios ofrecidos por la capa de transporte(TCP/UDP) a la capa de
aplicación. Ejemplo de aplicación. DNS)
¿Objetivos?
-
-
-
Aspectos conceptuales de implementación de los protocolos de aplicación de red.
modelos de servicio de capa de transporte
o paradigma cliente-servidor
o paradigma de igual a igual
aprenda sobre protocolos examinando protocolos populares de nivel de aplicación
o HTTP
o FTP
o SMTP / POP3 / IMAP
o DNS
programación de aplicaciones de red
o API de socket
La arquitectura de computadores, como ya tratamos diseña como son los elementos de un sistema, como funcionan
y como interactúan entre sí.
Capa de aplicación. Creación de aplicaciones de red distribuida
Contiene las aplicaciones de internet, las cuales son la razón de que exista internet, para poder ejecutarlas.
El desarrollo de una aplicación de red implica escribir programas que se ejecuten en distintos sistemas terminales
y que se comuniquen entre sí a través de la red.
Por ejemplo, en la aplicación Web se emplean dos programas diferentes que se comunican entre sí: el navegador
que se ejecuta en el host del usuario (una computadora de escritorio, un portátil, una PDA, un teléfono móvil, etc.)
y el programa del servidor web que se ejecuta en el host servidor web. Otro ejemplo sería el caso de un sistema de
compartición de archivos P2P en el que se emplea un programa en cada host que participa en la comunidad de
compartición de archivos. En este caso, los programas instalados en los distintos hosts pueden ser similares o
idénticos.
Una cuestión importante es que no es necesario escribir software que se ejecute en los dispositivos del
núcleo de la red, como por ejemplo los routers o switches de la capa de enlace. Ya que los dispositivos del núcleo
de red no ejecutan aplicaciones de red.
Este criterio funcional del diseño ha facilitado el rápido desarrollo y la implementación de una gran cantidad de
aplicaciones de red.
La comunicación de una aplicación de red tiene lugar entre sistemas terminales en la capa de aplicación.
Un caso en el que no es así es la red telefónica donde hay muy pocas aplicaciones (bloquear llamadas, buzón de
voz, mensajes de texto, redirecciones de llamadas, llamadas entre 3 personas), esto se debe a que no se puede
programar en el terminal, la aplicación debe de ser programada en la red, y por tanto cada vez que se crea una
aplicación hay que cambiar la red, lo que tiene el riesgo de estropear lo que ya hay, y por eso no se diseñan cosas
nuevas, ya que hay más riesgos.
Con internet solo tuenes que bajarte la aplicación, gracias a que las apps se ejecutan en los extremos y no es
necesario modificar los routers, explicando porque internet da lugar a la creatividad.
Arquitecturas de las aplicaciones de red (app distribuidas)
Desde la perspectiva del desarrollador de aplicaciones, la arquitectura de red es fija y proporciona un conjunto
específico de servicios a las aplicaciones, este se encarga de diseñar la arquitectura de la aplicación, que establecera
como la aplicación debe estructurarse en los distintpps sistemas terminales.
Hay fundamentalmente dos tipos de arquitecturas de aplicaciones:
- Cliente-servidor
- P2P (peer-to-peer)
Aunque también se habla de aplicaciones híbridas donde una parte de la aplicación se comporta de modo clienteservidor y la otra P2P.
Además, es necesario añadir hoy en día las arquitecturas cloud que se pueden simplificar como una arquitectura
cliente servidor donde el servidor está distribuido en la nuve.
Arquitectura cliente-servidor:
Siempre existe un host activo, denominado servidor, que da servicio a las solicitudes de muchos otros hosts, que
son los clientes. Los hosts clientes pueden estar activos siempre o de forma intermitente.
Las principales características de un servidor en esta arquitectura son:
- Está siempre activo normalmente esperando a conexiones de los clientes y por tanto tendrá una dirección IP
fija permanente y conocida, a la que esos clientes se pueden dirigir para solicitarle los servicios que ofrezca
- El principal problema de los servidores será el escalado según la demanda de los servicios, ya que el servidor
tiene que tener más recursos a medida que aumentan los clientes, porque sino se satura.
Las principales características de los clientes:
- Estos se conectan de forma intermitente con el servidor por tanto no están siempre activos pudiendo cambiar
su dirección IP (en distintas conexiones, pero cuando establecen una conexión la IP es fija) usando
direccionamiento dinámico, además los clientes no se comunican directamente entre sí.
Arquitectura P2P pura:
Donde tenemos que los hosts pueden actuar como servidores o clientes de forma simultánea, por lo que los
servidores no estarán siempre activos y los hosts clientes se podrán comunicar entre si pudiendo también cambiar
su dirección IP. De tal forma que explota la comunicación directa entre parejas de hosts conectados de forma
intermitente, conocidos como peers (pares).
Estas arquitecturas son altamente escalables, ya que son auto escalables ya que un peer es un cliente y un servidor
a la vez, ofreciendo él los recursos a la vez que va creciendo, pero muy difíciles de gestionar, y de garantizar la
calidad del servicio ya que no hay un compromiso.
Los principales problemas a los que se tienen que enfrentar son:
- Orientación al ISP: las infraestructuras de red que han desplegado los ISP están orientadas a arquitecturas
clientes servidor donde es mayor el tráfico de bajada que de subida, aunque hoy en día la fibra está permitiendo
el uso simétrico del ancho de banda.
- La seguridad, dada la naturaleza extremadamente distribuida y abierta.
- Por último, en estas hay que crear políticas con incentivos para motivar a los usuarios a ofrecer
voluntariamente recursos de ancho de banda, almacenamiento y computación.
- Las empresas, desde el punto de vista de negocio prefieren una arquitectura cliente-servidor.
Un ejemplo es BitTorrent, una plataforma de intercambio de archivos, donde hay distintos hosts y todos ellos
ofrecen y consumen servicios.
Arquitectura híbrida:
Hay arquitecturas p2p donde no todos los hosts son iguales, no son p2p puras y se les denomina híbridas. Algunas
aplicaciones tienen arquitecturas híbridas que combinan elementos cliente-servidor y P2P.
Skype
- aplicación de voz sobre IP P2P
- servidor centralizado: búsqueda de la dirección de la parte remota:
- Conexión cliente-cliente: directo (no a través del servidor)
Mensajería instantánea
- chatear entre dos usuarios es P2P
- servicio centralizado: detección de presencia del cliente / ubicación
o el usuario registra su dirección IP con el servidor central cuando se conecta
o el usuario contacta al servidor central para encontrar las direcciones IP de sus amigos
Por ejemplo, en muchas aplicaciones de mensajería instantánea los servidores se utilizan para hacer un
seguimiento de las direcciones IP de los usuarios, pero los mensajes de usuario a usuario se envían directamente
entre los hosts de dichos usuarios (sin pasar por los servidores intermedios).
Un ejemplo clásico es Skype, en ella tenemos peers o pares normales y superpeers estableciendo una jerarquía en
la red. Se tienen también un servidor centralizado del login, pero el índice que asigna los nombres de usuario a las
IPS está distribuido entre los superpeers, probablemente con DHT (tabla has distribuida). De tal forma que para
establecer la llamada el cliente solo sabe el ID, que mediante Un servicio cliente servidor, el servidor de login, te
dice donde está la persona con ese ID.
Procesos de comunicación: Comunicación entre procesos
Los programas que se ejecutan en varios sistemas terminales se comunican entre sí. En la jerga de los sistemas
operativos, realmente no son los programas sino los procesos los que se comunican. Un proceso puede
interpretarse como un programa que se
ejecuta dentro de un sistema terminal.
- Cuando los procesos se ejecutan en el mismo sistema terminal, pueden comunicarse entre sí mediante la
comunicación entre procesos aplicando las reglas gobernadas por el sistema operativo del sistema terminal.
- Los procesos de dos sistemas terminales diferentes se comunican entre ellos intercambiando mensajes a través
de la red de computadoras. Un proceso emisor crea y envía mensajes a la red; un proceso receptor recibe estos
mensajes y posiblemente responde devolviendo mensajes.
De tal forma que distinguimos dos tipos de procesos: un proceso cliente, el cual es el encargado de iniciar la
comunicación y un proceso servidor que espera hasta que alguien se le conecte.
No hay que confundir esto con la arquitectura, ya que en aplicaciones con arquitectura p2p también hay procesos
cliente y servidor en cada peer.
sockets
Los procesos enviaran los mensajes desde la capa de aplicación a la capa de transporte (es decir un proceso envía
mensajes a la red y nos recibe a través de una interfaz software denominada socket) mediante una interfaz (API)
que denominaremos sockets (puerta tras la cual la app manda la información al SO).
Un proceso es análogo a una casa y un socket es análogo a la puerta de la casa. Cuando un proceso desea enviar
un mensaje a otro proceso que se está ejecutando en otro host, envía el mensaje a través de la puerta (socket). Este
proceso emisor supone que existe una infraestructura de transporte al otro lado de la puerta que llevará el mensaje
hasta la puerta del proceso de destino. Una vez que el mensaje llega al host de destino, éste pasa a través de la
puerta (socket) del proceso receptor, actuando entonces el proceso receptor sobre el mensaje.
Como se muestra en la figura, un socket es la interfaz entre la capa de aplicación y la capa de transporte de un
host. También se conoce como Interfaz de programación de aplicaciones (API, Application Programming
Interface) que opera entre la aplicación y la red, ya que el socket es la interfaz de programación con la que se
construyen las aplicaciones de red.
El desarrollador de la aplicación tiene el control sobre todos los elementos del lado de la capa de aplicación del
socket, pero apenas tiene control sobre el lado de la capa de transporte del socket. El único control que tiene el
desarrollador de la aplicación sobre el lado de la capa de transporte es:
(1) la elección del protocolo de transporte (TCP o UDP)
(2) quizá la capacidad de fijar unos pocos parámetros de la capa de transporte, como por ejemplo los tamaños
máximos del buffer y de segmento (lo que veremos en el Capítulo 3).
Una vez que el desarrollador de la aplicación ha seleccionado un protocolo de transporte (si hay disponibles varios
entre los que elegir), la aplicación se crea utilizando los servicios de la capa de transporte proporcionados por
dicho protocolo.
Protocolos de la capa de aplicación
Recordamos que un protocolo de red define el tipo de mensaje intercambiado (solicitud, respuesta),
especificando su formato tanto la sintaxis (qué campos en los mensajes y cómo se delinean los campos) como la
semántica (significado de la información en los campos) del mensaje y las reglas para cuándo y cómo los
procesos envían y responden mensajes (su orden y las acciones que se realizaran).
Estos protocolos pueden ser:
- Protocolos de dominio público: definidos en RFCs que permiten la interoperabilidad entre sistemas como
e.g. HTTP, SMTP
- Protocolos propietarios como los empleados por Skype
¿Qué protocolos de servicio de transporte necesita una aplicación?
Bajo la capa de aplicación, está la capa de transporte que nos podrá ofrecer a las apps, determinados servicios
como: teniendo en cuenta que las distintas apps pueden ser sensibles de distintas maneras a los sistemas de
comunicación/transporte :
1. Transferencia fiable: si quieres asegurarte de que los mensajes llegan al destinatario sin errores completos y
ordenados.
2. Temporización o timing: el tiempo desde que se envía hasta que se recibe el mensaje.
3. Tasa de transferencia: velocidad a la que te va llegando el mensaje
4. La seguridad: hablando en términos de confidencialidad, integridad de datos, autenticación…
Teniendo en cuenta que las distintas apps pueden ser sensibles de distintas maneras a los sistemas de
comunicación/transporte :
Por ejemplo, teniendo en cuenta estas dos aplicaciones:
o Transferencia de archivos (A)
o Llamada de voz (B)
1.A es una app intolerante a fallos, si se pierde un bit del archivo este ya no sirve para nada
1.B la comunicación por voz es bastante robusta al ruido, apenas te das cuenta de la perdida de datos, por
tanto, es un servicio del que puede prescindir.
2.A como la trasferencia de archivos ya necesita tiempo, que haya un retardo no es muy significativo
2.B el retarde en la comunicación por voz es bastante perjudicial, ya que se superponen las distintas palabras y
no se entendería nada.
3.A se puede demorar más o menos tiempo, pero al final se logra transmitir el archivo es una “aplicación
elástica” usan la tasa de trasferencia disponible.
3.B es una “aplicación sensible al ancho de banda” y por tanto pide una tasa de transferencia mínima
garantizada para poder entender la voz.
DISTINTAS APPS TIENEN DISTINTA SENSIBILIDAD A DISTINTAS CARACTERISTICAS DE LOS
SERVICIOS DE COMUNICACIÓN
Algunos de estos servicios no los proporciona internet y tienen que añadirse en la aplicación.
Servicios de protocolos de transporte por internet
(servicios de comunicación disponibles en
internet)
La capa de transporte nos provee de dos servicios o protocolos de transporte más usados que son:
- Protocolo TCP
- Protocolo UDP
El protocolo TCP:
- Orientado a la conexión: requiere configuración entre los procesos del cliente y el servidor
- Transporte confiable entre el proceso de envío y recepción
- Control de flujo: el remitente no abrumará al receptor
- Control de congestión: acelerador del remitente cuando la red está sobrecargada
- No proporciona: tiempo, garantías de rendimiento mínimo, seguridad
El protocolo UDP:
- Transferencia de datos poco confiable entre el proceso de envío y recepción (best-efford)
- No proporciona: configuración de conexión, confiabilidad, control de flujo, control de congestión,
sincronización, garantía de rendimiento o seguridad
Sabiendo esto, ¿Quién usa UDP? Hay aplicaciones como las llamadas las cuales se pueden permitir la perdida de
datos, y usan UDP para usar menos recursos y ser más rápidas, ya que la mejora de fiabilidad que ofrece TCP
tiene un coste en tiempo ya que si algo falla se pide varias veces para comprobar el mensaje y además se
retienen el resto de los mensajes, cosa que a una llamada perjudicaría mucho.
Direccionamiento de procesos
¿Cómo indica un proceso con qué proceso desea comunicarse utilizando estos servicios? ¿Cómo especifica un
proceso que se ejecuta en un host situado en Amherst, Massachusetts, Estados Unidos, que desea comunicarse con
un determinado proceso que está ejecutándose en un host ubicado en Bangkok, ¿Tailandia? Para identificar al
proceso de recepción, tienen que especificarse dos elementos de información:
(1) el nombre o dirección del host
(2) un identificador que especifique el proceso de recepción en el host de destino.
Suponemos que tenemos un proceso cliente que se quiere comunicar con un proceso servidor en otro host a través
de internet. Quiere mandar un mensaje, pero necesita alguna forma de identificar el destino (se necesita un
elemento fundamental para establecer la comunicación), por tanto, se necesita que el cliente pueda identificar al
servidor y este necesitará saber el del cliente para ofrecerle el servicio.
La función de la capa de red era poner un encabezado al mensaje con el origen y destino de este.
En internet, la capa IP nos provee de un ID para cada elemento, una dirección IP esta dirección es una magnitud
de 32 bits que identifica de manera unívoca a un host.
Por lo tanto, en un mensaje se debe de incluir la IP del proceso servidor y la IP del proceso usuario (origen), pero
con esto no es suficiente, ya que una vez el mensaje llegue al servidor, necesita saber a qué aplicación quiere ir
Necesitas identificar también a dicha aplicación a la que va destinado el mensaje porque en cada dispositivo corren
distintas aplicaciones.
La IP identifica al dispositivo, pero dentro de él no sabes identificar los distintos procesos en ejecución, para ello
necesitamos algo más, esto son los puertos. (números de puerto)
Cada dispositivo tiene un rango de puertos que identifican las aplicaciones que se ejecutan en el dispositivo, por
tanto, en la cabecera del mensaje debe ir el par (IP, puerto) el cual identifica al socket de la aplicación y esta
combinación debe de ser única.
Para recibir mensajes, el proceso debe tener un identificador
el dispositivo host tiene una dirección IP exclusiva de 32 bits
P: ¿la dirección IP del host en el que se ejecuta el proceso es suficiente para identificar el proceso?
R: No, muchos procesos pueden ejecutarse en el mismo host
El identificador incluye tanto la dirección IP como los números de puerto asociados con el proceso en el host.
Ejemplos de números de puerto:
Servidor HTTP: 80
Servidor de correo: 25
enviar un mensaje HTTP al servidor web gaia.cs.umass.edu:
Dirección IP: 128.119.245.12
Número de puerto: 80
más brevemente ...
DNS (domain name system)
Veremos ahora el protocolo DNS, en internet las máquinas tienen direcciones IP, pero para evitar recordar esos
números empleamos nombres de dominio (alias) ¿Qué correspondencia hay entre la IP y su nombre de dominio?
El DNS es el sistema que permite almacenar las correspondencias entre direcciones IP y nombres de dominio,
también con DNS nos vamos a referir al protocolo que se empleará para consultar esa base de datos distribuida.
Por lo tanto, DNS puede referirse a:
- base de datos distribuida implementada de forma jerárquica con varios servidores de nombres
- protocolo de la capa de aplicación que permite a los hosts consultar esa base de datos distribuida.
Este protocolo ira sobre UDP y el servidor esperará conexiones en el puerto 53.
Servicios que ofrece DNS:
- El principal servicio de DNS será por tanto la traducción del nombre de dominio (del host) a dirección IP.
- Proporciona Alias para esas máquinas (hosts) y servidores de correo.
- También ayuda a la distribución de la carga haciendo corresponder un único nombre con varias direcciones
IP (con servidores web replicados, un conjunto de direcciones IP para un único nombre canónico). Siendo un
servicio transparente al usuario.
Además, se hace de forma descentralizada porque un DNS centralizado sería un único punto de fallo, tendría un
gran volumen de tráfico, problemas de distancia a la base de datos centralizada, problemas de mantenimiento y
problemas de escalado.
Por tanto, se ha desarrollado una base de datos distribuida y jerárquica:
En la que los servidores se distribuyen principalmente en tres niveles:
- servidores DNS Raíz
- servidores DNS doble del domain (.com, .es, .org …)
- servidores DNS autoritativos (Google.com, uc3m.com, youtube.com…)
Por ejemplo, si quisiésemos saber la dirección IP de www.uc3m.es, se la pedimos al servidor raíz, este devuelve
la dirección IP del servidor TLD “.es” a este le pedimos la IP del servidor autoritativo y nos devuelve la IP del
servidor autoritativo “uc3m.es” y a este servidor se la pedimos nuevamente y nos devuelve la IP de www.uc3m.es.
Los servidores raíz son 13 “servidores” (10 en EEUU uno en Japón, otro en Estocolmo y otro en Londres), no
todos son iguales, hay una raíz maestra donde se hacen las modificaciones (Washington) y los 12 restantes son los
esclavos los cuales replican al maestro (etiquetados de la A a la M) y estos están replicados (mirrors) y
configurados en clúster (por seguridad y fiabilidad) por todo el mundo.
Los servidores TLD (top-level domain): son los responsables de los dominios de nivel superior (.com, .org, .net,
.edu … y de los dominios de países (.es, .uk, .fr, .ca, .jp, …).
Los servidores DNS autoritativos: son los que tendrán los registros DNS de los hosts que están accesibles al
público como los servidores web y de correo. Estos son mantenidos por la organización o por un proveedor
externo.
Los servidores DNS locales, o servidores de nombres predeterminados, que son implementados por cada ISP
(domestico, empresa, uni…) y no pertenecen a la jerarquía.
Cuando un host pide una IP para un determinado nombre se conecta con el servidor Local (son a los que primero
pedimos una traducción a IP y son los encargados de buscarla por la jerarquía DNS).
Estos actúan como proxy: devuelve la IP si la tiene y si no envía la petición a la jerarquía de servidores DNS, esto
se debe a que tienen una caché, por lo que de cada búsqueda que hacen se quedan una copia y así si se vuelve a
pedir no tienen que volver a buscarla. Los registros DNS almacenados en estas cachés expiran al cabo de un tiempo
y hay mecanismos de actualización y notificación para tener la información al día.
Es habitual que la información sobre los servidores TLD esté cacheada en nuestro DNS local y no se hagan muchas
consultas a los servidores raíz preguntando por los TLD.
Tipos de resolución de una consulta:
La consulta DNS más habitual es la consulta iterativa en la que delegamos en nuestro DNS local, y este es el que
va buscando (ejemplo El host quiere la IP de www.uc3m.es):
1.
2.
3.
4.
5.
6.
7.
8.
mensaje de consulta al DNS local
el DNS local envía la consulta al DNS raíz
toma el sufijo .es y devuelve la IP del TLD correspondiente
ahora el DNS local consulta al TLD .es
éste toma el sufijo uc3m.es y devuelve la IP de DNS
autoritativo correspondiente
y el DNS local consulta al DNS autoritativo uc3m.es
y este devuelve al DNS local la IP de www.uc3m.es
y el DNS local finalmente devuelve la IP al host.
Otra opción para la resolución de nombre serían las
consultas recursivas donde se pregunta a un servidor
que a su vez pregunta a otro servidor, este es
desaconsejable por la carga que requieren, además de que
los DNS raíz se saturaran por tanta demanda.
Aquí el DNS local haría una consulta recursiva, en la que
pide al DNS raíz que haga toda la consulta por él y así
sucesivamente cargando en exceso a los servidores raíz y
TLD.
Registros DNS
Desde el punto de vista de DNS es una base distribuida que
almacena registros de recursos.
Los registros DNS o resource records (RR) serán los que se
almacenan en los servidores DNS y no son mas que una tupla
con un nombre, un valor, un tipo y un tiempo de vida o ttl indicando el tiempo que se debe almacenar este registro
en una caché.
Hay varios tipos de registros DNS, pero los más comunes son:
- Tipo = A: en el que el campo nombre tendremos el nombre del host y en el campo valor su dirección IP.
- Tipo = NS: en el que el campo nombre tendrá el nombre del dominio (e.g. Google.com) y en el valor, el
nombre de un DNS autoritativo para dicho dominio.
- Tipo = CNAME: en el que en el campo nombre está el alias para un host cuyo nombre canónico es el que
figura en el campo valor.
- Tipo = MX: es como el CNAME, pero para servidores de correo electrónico. Valor es el nombre canónico
del servidor de correo con alias nombre.
Si un servidor es autoritativo de un host tendrá un registro tipo A para ese host indicando su IP, si no lo es lo
podría tener en su caché o tener un registro NS con el nombre del servidor DNS que tenga el dominio del host y
otro registro tipo A con la IP de ese servidor.
Tenemos entonces que DNS es una base de datos distribuida que consultan los equipos empleando un protocolo.
¿Cómo son los mensajes de ese protocolo DNS?
Mensajes y protocolo DNS
Protocolo DNS: Tenemos solo dos tipos de mensajes para hacer las consulta y respuesta, ambos con el mismo
formato (nslookup):
Tienen una cabecera del mensaje:
- Con un número de identificación de 16 bits que identifican la consulta. (este número se inserta en la respuesta)
-
-
Una serie de indicadores (flags de1 bit) que dirán:
o si se trata de una consulta o de una respuesta
o si se desea emplear recursión
o se activa si se soporta dicha recursión
o se activa a 1 si la respuesta es de un DNS
Después vienen cuatro campos que nos van a indicar el número de consultas, el número de registros de
respuesta, el número de registros autoritativos o el número de registros adicionales que lleva ese mensaje, de
esta forma tras estos cuatro números vendrán esas consultas, respuestas, registros autoritativos o registros
adicionales que se devuelven.