La capa de aplicación

Lo siguiente es una reseña al nivel de aplicación según CCNA 1 4.0.

3.1.1.1. Modelo OSI y TCP/IP

Recordatorio del modelo de capas.

  • La capa de aplicación es la capa 7 en OSI, y la capa 5 (o 4 si capa física y enlace se unen en acceso al medio) en TCP/IP.
  • La capa de aplicación se utiliza para intercambiar datos entre programas que se ejecutan en los host origen y destino.
  • La capa de aplicación en TCP/IP es la capa de aplicación + presentación + sesión en OSI. Es decir, si una aplicación requiere servicios de presentación y de sesión, debe implementarlos ella.
  • La capa de presentación incluye cuestiones de codificiación y conversión de datos, compresión de datos y encriptación.

En la práctica, en TCP/IP la presentación se determina por estándares de la industria. Por ej. mpg para video o jpg para imagen (que incluyen codificación y compresión).

La capa de sesión retoma diálogos que se interrumpieron por largos periodos.

La mayoría de las aplicaciones incluyen las funcionalidades de Aplicación, Sesión y Presentación, como clientes web, clientes de correo electrónico o clientes de FTP.

Aplicaciones más comunes son las que proporcionan intercambio de la información del usuario:

  • DNS
  • HTTP
  • SMTP
  • TELNET
  • FTP

Los protocolos de TCP/IP se definen mediante RFCs.

3.1.1.1. Software de la capa de aplicación

Las aplicaciones permiten comunicarse a las personas de la red con la red de datos subyacente. Al abrir una aplicación, se carga en memoria y se ejecuta:

  • Como aplicación: usado directamente por una persona para comunicarse a través de la red. Implementa la capa de aplicación y puede comunicarse con las capas inferiores o bien usar un servicio para ello.
  • Como servicio: para ser usado por otra aplicación para poder acceder a las capas inferiores.

3.1.3.1. Aplicaciones de usuario, servicios y protocolos de la capa de aplicación.

Distinguimos entre protocolo, aplicación y servicio:

  • Aplicación: interfaz humana. Las personas interaccionan con ellas.
  • Servicios: interfaz con la red. Es el ¿QUÉ HACE?
  • Protocolos: reglas y formatos. Describen qué mensajes se intercambian entre el host origen y destino, sintaxis de los comandos de control, el tipo y formato de los datos que se transmiten y los métodos adecuados para notificación y recuperación de errores. Es el ¿CÓMO LO HACE?

Puede haber un único nombre para los tres. Ej: Telnet.

3.1.4.1. Funciones del protocolo de aplicación

Los protocolos de aplicación se usan en el origen y el destino de una comunicación, y deben coincidir para que ésta sea exitosa.

Los protocolos establecen reglas para intercambiar datos entre las aplicaciones y los servicios de las máquinas implicadas. Estas reglas definen la estructura y los tipos de mensajes intercambiados entre origen y destino. Los protocolos definen:

  • Los procesos en cada uno de los extremos.
  • Los tipos de mensajes.
  • La sintaxis de los mensajes
  • El significado de los campos de información.

Existen muchos y diversos protocolos de aplicación con diferentes finalidades cada uno. La aplicaciones y los servicios pueden hacer uso de diferentes protocolos de aplicación para cumplir con su propósito.

3.2.1.1. Modelo cliente-servidor.

En el modelo cliente servidor, el dispositivo que solicita información se denomina cliente, y el que responde la solicitud se denomina servidor. Cuando el cliente hace una solicitud, el servidor responde enviando un stream de datos, aunque en realidad puede hacer falta información adicional, como autenticación de usuario por ejemplo, o la identificación del nombre del archivo a transferir.

Ejemplo: Un cliente de correo electrónico envía una solicitud al servidor de correo para un mensaje no leido. El servidor envía el correo solicitado al cliente.

Los flujos de datos pueden ser voluminosos en ambos sentidos o incluso mayor en sentido de subida (del cliente al servidor) que de bajada (del servidor al cliente). Por ejemplo, si pensamos en un cliente FTP subiendo un fichero al servidor, el volumen de subida es mayor que el de bajada.

3.2.2.1. Servidores.

Un servidor es cualquier dispositivo que responde a una solicitud de una aplicación cliente. Aunque también, la palabra servidor define al proceso que escuha en un puerto y presta un servicio. Un servidor suele compartir su información con muchas aplicaciones cliente, como por ejemplo un servidor web, o de archivos.

Dependiendo del servicio que presta el servidor, habrán más o menos requerimientos para la conexión, pudiendo requerir diferentes grados de autenticación. Por ejemplo, al conectarse a un servidor FTP, puede requerirse contraseña, y al conectarse a una página via https puede requerirse un certificado electrónico.

A la aplicación servidor también se le conoce como demonio (o daemon). De ahí que en linux, gran parte de las aplicaciones servidor termien con la letra "d", como httpd o dhcpd.

3.2.3.1. Protocolos y servicios de la capa de aplicación

Una única aplicación puede emplear diferentes servicios de la capa de aplicación. Este proceso es transparente para el usuario, y una (aparentemente) única solicitud puede estar compuesta de múltiples solicitudes individuales. Además, para cada solicitud pueden ejecutarse múltiples procesos.

Los servidores atienden múltiples solicitudes simultáneas de diferentes clientes. Internamente, el servidor gestiona también las diferentes silicitudes mediante procesos auxiliares (procesos hijo) que resuelven la solicitud.

3.2.3.2. Protocolos y servicios de la capa de Aplicación (actividad con PT).

Actividad 1. Empleando la topología siguiente (que ya realizaste en un tema anterior) en packet tracer, introduce un servidor DNS y un servidor Web en la red 172.16.5.0/24, con el texto "¡Hola mundo!". La página web será accesible bajo el nombre www.ejemplo.com, por lo que debes crear un registro tipo A en el servidor DNS. Introduce correctamente la DNS en uno de los PCs cliente de la red 172.16.1.0/24.

Rastrea el tráfico de red en modo simulación, observando las siguientes cosas:

  • 1) La consulta DNS sobre UDP
  • 2) El inicio de sesión TCP
  • 3) El tráfico HTTP sobre TCP
  • 4) El cierre de sesión TCP

3.2.4.1. Redes y aplicaciones entre pares (P2P, peer to peer).

Existen otros modelos además del modelo cliente/servidor. El modelo punto a punto. Se trata de un modelo que responde a dos cosas diferentes: redes entre pares y aplicaciones punto a punto (P2P).

Redes entre pares: en este modelo, cada máquina puede actuar como cliente y como servidor. Por ejemplo, pensemos en una red doméstica donde cada máquina comparte recursos con los demás. De este modo, una máquina puede estar accediendo a una carpeta compartida por otra, y al mismo tiempo estar recibiendo una solicitud de impresión para una impresora que comparte.

A diferencia de en el modelo cliente/servidor, donde los servidores son dedicados, en las redes entre pares (o punto a punto) descentralizan los recursos.

Aplicaciones punto a punto: en este otro modelo, hablamos de aplicaciones que pueden actuar como cliente o como servidor dentro de la misma comunicación. Ambas pueden iniciar una comunicación y se consideran iguales en el proceso de comunicación. Al iniciar una aplicación P2P, se ejecuta por un lado la interfaz del usuario, y por otro procesos en segundo plano. Luego, las aplicaciones pueden comunicarse.

Existe un sistema híbrido para las aplicaciones P2P, donde los recursos compartidos siguen descentralizados, pero la información sobre su ubicación está almacenada en un directorio centralizado de un servidor de índice. En este sistema, si un cliente desea localizar un recurso en un servidor, primero debe consultar en el servidor de índice. El servidor de índice también puede ayudar a conectar dos puntos, pero una vez conectados, la comunicación puede llevarse entre los dos puntos de manera autónoma.

3.3.1.1. Protocolos y servicios DNS

El servicio DNS se encarga de traducir nombres de dominio a direcciones IP para no tener que recordar la IP de cada servidor que nos interesa. De este modo, el nombre www.mauriciomatamala.net se corresponde con una ip. Si decido cambiar esta IP, el usuario no percibirá cambio alguno, ya que el nombre sigue siendo el mismo.

DNS utiliza una base de datos distribuida en muchos servidores, que almacena la información sobre los dominios a resolver.

El protocolo DNS define la consultas, respuestas y formatos de datos. Las comunicaciones utilizan un formato simple llamado mensaje, que es utilizado para solicitudes, respuestas del servidor, mensajes de error y transferencia de información.

3.3.1.2. Protocolo y servicios DNS

El cliente DNS es llamado resolutor DNS. Aunque es el cliente DNS, en realidad actúa como un servicio para otras aplicaciones de la máquina cliente. Un navegador web, hará una consulta al resolutor, que actuará como cliente para un servidor DNS.

Al configurar una máquina cliente, se proporciona una o más direcciones de servidores DNS. Esta información puede proporcionarla el mismo ISP o el usuario que configura el equipo. Cuando una aplicación de usuario solicita conectarse con un dispositivo remoto empleando su nombre, el cliente DNS realiza una consulta al servidor DNS.

Existe una utilidad llamada nslookup que permita al usuario hacer consultas manualmente a un servidor DNS. Esta aplicación suelen utilizarla los administradores de red para resolver problemas con DNS.

Por ejemplo, podemos probar con lo siguiente:

En linux:

# nslookup - 80.58.32.33 //Ejecución del comando indicando el servidor DNS al que preguntaremos. > www.google.com //Indicamos el nombre a resolver

Estaríamos preguntando al servidor 80.58.32.33 qué ip está asociada con el nombre www.google.com.

Se puede conocer más sobre nslookup en http://support.microsoft.com/kb/200525/es para Windows, o en http://linux.die.net/man/1/nslookup para linux.

Nslookup es una herramienta que tiende a ser sustituida por la herramienta dig.

Práctica 2. Utiliza nslookup para consultar al servidor DNS 80.58.32.33 la IP de un ordenador llamado www.mauriciomatamala.net

3.3.1.3. Protocolos y servicios DNS.

Un servidor DNS ejecuta un demonio que en sistemas UNIX se llama named. El servidor almacena información variada sobre un mismo dominio, como por ejemplo el dominio ejemplo.com. La información se organiza en los llamados "registros de recurso". Un registro de recurso, puede indicar qué IP tiene un cierto ordenador del dominio, mientras que otro registro de recurso puede indicar cuál es el servidor de correo.

Hay diferentes tipos de registro de recurso. Algunos de ellos son:

  • A -> asocia un nombre con una dirección IP de un ordenador.
  • NS -> indica el nombre del servidor DNS "autoritativo" del dominio.
  • CNAME -> indica un alias (o segundo nombre) para un ordenador del dominio.
  • MX -> asigna un nombre de dominio a una lista de servidores de correo para el dominio.

Cuando un cliente realiza una consulta, el proceso "named" del servidor, busca en sus propios registros a ver si tiene información sobre el nombre pedido. Si no encuentra información en sus registros de recurso, contacta con otros servidores que estén ubicados en mejor posición que él en la jerarquía DNS. Este proceso se puede repetir en varios servidores DNS, hasta que uno sea capaz de resolver la petición. La respuesta llegaría al servidor inicial que a su vez respondería al cliente. Los servidores más altos en la jerarquía son los que tienen mayor carga de trabajo.

El servidor almacena temporalmete la respuesta a esta consulta en una caché de nombre. Si se le vuelve a hacer la consulta en un periodo acotado, el servidor responderá inmediatamente. Del mismo modo, los resolutores DNS en las máquinas cliente, también almacenan una caché DNS con la misma funcionalidad. Para consultar la caché DNS, en windows se puede ejectuar "ipconfig /displaydns" y en Ubuntu tendríamos que activar esta función (se puede seguir este manual http://www.guia-ubuntu.org/index.php?title=Dnsmasq,_servidor_DNS_y_DHCP).

3.3.1.4. Protocolo y servicios DNS

Para conocer la estructura DNS, se puede consultar un artículo antiguo pero absolútamente válido para el tema que nos ocupa: http://multingles.net/docs/arbol.htm.

Para comprender la jerarquía DNS, también se puede leer el siguiente documento:

http://lucas.hispalinux.es/Manuales-LuCAS/GARL2/garl2/x-087-2-resolv.howdnsworks.html

Aquí también encontrarás más información sobre DNS en linux con named.

3.3.2.1. Servicio WWW y HTTP

La URL http://www.ejemplo.com/index.html, identifica al recurso index.html que está en un servidor llamado "www" perteneciente al dominio "ejemplo.com", accesibe via el protocolo http. Los exploradores web son los clientes para el protocolo http.

Un explorador web inicia una conexión con el servidor, empleando tcp para ello. Una vez establecida la conexión, el cliente web solicita el recursos al servidor. El servidor se los envía y una vez recibidos, el navegador los presenta al usuario.

Los navegadores son capaces de mostrar por sí solos varios tipos de datos, como texto sin formato, html o javascript. Otro tipo de datos requiere de otro programa para entenderlos, como los datos flash. Estos programas son llamados plug-ins o complementos.

El proceso seguido para acceder a una página web es el siguiente:

El usuario escribe la URL de la página a descargar. En este punto, el explorador interpreta las tres partes de la URL:

  • 1. HTTP - Protocolo con el que accederá al servidor.
  • 2. www.ejemplo.com - nombre del servidor.
  • 3. index.html - nombre del archivo.

El explorador solicita a un servidor de nombres que transforme el nombre www.ejemplo.com a una dirección IP.

Una vez resuelta la dirección IP, el explorador envía una solicitud GET al servidor, y pide el archivo index.html al servidor.

El servidor, al recibir la solicitud, envía al cliente el código fuente de la página.

Finalmente, el navegador descifra el código y da formato a la ventana del explorador.

3.3.2.2. Servicio WWW y HTTP

HTTP forma parte de los protocolos de aplicación de la pila TCP/IP original. Su finalidad original era publicar y recuperar las páginas HTML. En la actualidad se emplea para muchas otras funciones, como para sistemas de información distribuidos y de colaboración.

HTTP especifica un protocolo de solicitud/respuesta. El cliente puede enviar al servidor tres tipos de solicitud (mensaje): GET, POST y PUT.

GET permite solicitar datos al servidor. A esta solicitud el servidor responde con una línea de estado, como "HTTP/1.1 200 OK", y un mensaje cuyo cuerpo puede ser el archivo solicitado, un mensaje de error o alguna otra información.

POST y PUT permiten subir datos al servidor.

HTTP es un protocolo no seguro, y un usuario que intercepte la información puede leerla. Por ello para una comunicación segura se utiliza el protocolo HTTPS que permite la autenticación y la encriptación para asegurar los datos enviados.

3.3.3.1. Servicios de e-mail y protocolos SMTP/POP

El servicio de correo hace uso de más de un protocolo. Como mínimo podemos hablar de POP (Protocolo de Oficina de Correos) y de SMTP (Protoclo de Transferencia de Correo Simple).

El cliente de correo es llamado MUA (Agente de Usuario de Correo), y permite enviar los mensajes al exterior, y también gestionar los mensajes recibidos.

Para recibir un correo desde el servidor, se utiliza POP, mientras que para enviar un correo, se utiliza SMTP.

3.3.3.2. Servicios de e-mail y protocolos SMTP/POP

El servidor de correo ejecuta dos procesos individuales:

  • -MTA (Agente de Transferencia de Correo).
  • -MDA (Agente de Entrega de Correo).

El MTA recibe un correo procedente de un MUA o de otro MTA. El MTA permite que un servidor reenvíe un correo a otro MTA en otro servidor de correo. Finalmente, el correo llegará a un servidor que tendrá el buzón de correo destino alojado en él. En tal caso, el correo es entregado por el MTA al MDA.

3.3.3.3. Sevicios de e-mail y protocolos SMTP/POP

El MDA recibe todo el correo entrante desde el MTA y lo coloca en los buzones. También se pude encargar otras tareas como análisis de virus, filtrado de spam y manejo de acuses de recibo.

Existen sistemas de e-mail corporativos, con funcionalidades que van más allá del estricto envío de correo, como por ejemplo IBM Lotus Notes, Novell Groupwise o Microsoft Exchange. Estos sistemas pueden tener su propio formato de correo electrónico interno mediante protocolos propietarios.

Los sistemas de correo corporativo tienen un gateway a través del cual envían correos al exterior. Dicho gateway realiza la conversión necesaria a protocolos estándar. Aunque los sistemas corpormicrosoft exchangeativos no tiene por qué enviar correo al exterior.

3.3.3.4. Servicios de e-mail y protocolos SMTP/POP

POP y POP3 son protocolos cliente/servidor en envío de correo entrante. Cuando el cliente se conecta (MUA) al servidor, éste puede enviar los correos del buzón al cliente empleando el protocolo POP.

Por otro lado, SMTP controla las transferencias de emails salientes, desde el MUA al servidor (en concreto al MDA), y entre servidores (mediante intercambio entre MTAs).

SMTP utiliza un conjunto rígido de comandos y respuestas, como "inicio de sesión", "transacción de correo", "reenvío de correo", "verificación de nombres buzones", "expansión de listas de correo" y "apertura y cierre de intercambios".

Algunos de los comandos son:

  • HELO: Inicia la conversación con otro servidor de correo.
  • EHLO: Versión más nueva de HELO.
  • MAIL FROM: Indica quién envia el correo.
  • RCPT: Indica quién recibe el correo.
  • DATA: Indica que se va a enviar el texto del mensaje.

3.3.4.1. FTP

FTP Permite transferir ficheros entre cliente y servidor. FTP requiere dos conexiones entre cliente y servidor: una para enviar comandos de control y otra para la transferencia de los archivos.

El cliente se conecta al puerto TCP 21 para los comandos de control. Una vez establecida la conexión, se realiza otra conexión al puerto TCP 20, para la transferencia real de archivos.

La transferencia puede producirse en ambos sentidos.

3.3.5.1. DHCP

Permite automatizar la asignación de una IP a los ordenadores de una red. Tiene sentido sobre todo en redes grandes, donde hay una alta variabilidad de usuarios, aunque puede utilizarse en redes de cualquier tamaño.

El ciente (un ordenador que inicia sin IP) solicita mediante un mensaje broadcast una IP al servidor DHCP de la red. Éste asigna una IP de un pool (manojo) de IPs y la asigna temporalmente al cliente.

Un servidor DHCP simplifica el trabajo del administrador ya que no tiene que estar pendiente de la IP de cada dispositivo. Sin embargo esto puede ser un riesgo, ya que cualquier dispositivo obtendrá una IP. En realidad esto se puede controlar.

En principio las asignaciones son temporales pero se pueden configurar para que sean estáticas y no varien.

Puede haber servicio DHCP en redes inalámbris públicas, privadas, domésticas. En el caso de las redes domésticas el servidor DHCP estará en el lado del ISP de forma que los routers tomarán una dirección del mismo. Así mismo, el usuario final, recibe una IP del servidor DHCP que incorpora el router.

3.3.5.2. DHCP

Cuando el cliente se conecta a la red, envía un paquete de DESCUBRIMIENTO DHCP para identificar al servidor DHCP. El servidor contesta con una OFERTA DHCP, ofreciendo IP, máscara de subred, DNS, puerta de enlace y duración de la asignación.

En ocasiones hay más de un servidor DHCP, en cuyo caso el cliente tendrá que elegir entre las ofertas.

Si el cliente acepta la asignación, envía otro mensaje aceptando la oferta e identificando el servidor DHCP del que provenía la oferta.

Si el servidor está de acuerdo envía un paquete DHCP ACK confirmando la reserva. Si no está de acuerdo, envía un DHCP NACK (debido a una reserva de última hora, por ejemplo) el cliente deberá empezar de nuevo descubriendo los servidores DHCP de la red.

3.3.6.1. SMB

SMB (Bloque de Mensajes del Servidor) es un protocolo para compartir archivos. Es originario de IBM aunque es el pilar de las redes Microsoft. A diferencia de FTP, una vez se inicia una sesión con un recurso compartido, la sesión permanece abierta tanto tiempo como la sesión del usuario Windows. El usuario accede al recurso como si fuera local.

Originalmente SMB utiliza el protocolo NETBEUI para acceder a la red, pero en la actualidad utiliza TCP/IP. Esto permite que se puedan compartir recursos en red via SMB en redes TCP/IP.

Linux también implementa una versión de SMB mediante el servidor SAMBA, gracias la cual un servidor Linux puede compartir recursos en una red Microsoft. Apple, al basarse en UNIX, también puede implementar SMB.

3.3.6.2. Protocolo SMB y servicios para compartir archivos

SMB describe el modo en que los usuarios hacen solicitudes y cómo acceden a los recursos. Todos los mensajes SMB tienen el mismo formato, con encabezado de tamaño fijo.

Los mensajes SMB pueden iniciar, autenticar y terminar sesiones, controlar el acceso a archivos e impresoras, y permitir a una aplicación enviar o recibir mensajes hacia o desde otro dispositivo.

Práctica 3. En esta práctica, escucharás mediante Wireshark el tráfico que se produce (a nivel de aplicación) al abrir una página web usando el navegador. El cliente web envía un paquete HTTP al servidor, incluyendo un comando de control GET para solicitar el recurso. Entonces el servidor envía el recurso al cliente. Deberás:

  1. Abrir un navegador web y abrir la siguiente dirección: http://192.168.10.100/web2011/index.php
  2. Encontrar el comando GET donde se solicita dicha página
  3. Encontrar la transferencia del contenido de la página al cliente

Podrás comprobar que finalmente se cierra la conexión TCP.

Entregar: 1. Contenido del paquete donde el cliente solicita la página web (visualizar el contenido del paquete mediante Wireshark). 2. Paquete donde se transfiere el contenido de la página al cliente.

Práctica 4. Para insistir un poco más en la idea de "Protocolo de aplicación = juego de comandos/respuestas", vamos usar el protocolo FTP desde la línea de comandos. La idea de este ejercicio es que compruebes como la interacción entre un cliente FTP y el servidor FTP, transcurre entre comandos que piden algo, y respuesta del servidor. Antes de empezar, debemos preparar el entorno:

  • Crea la carpeta C:\FTP\, donde almacenarás los archivos que deseas descargar o subir al servidor FTP (en realidad el directorio puede ser cualquier. Usaremos este por la simplicidad de la ruta).
  • En segundo lugar, crea un archivo de texto llamado "test-ftp.txt". Dentro del archivo puedes escribir lo que quieras.
  • A continuación abre un línea de comandos y cambia al directorio C:\FTP\, con el comando cd C:\FTP.
  • Abre el programa Wireshark, e inicia una escucha en la interfaz ethernet de tu máquina, y aplicando el siguiente filtro: ftp.

Ahora podemos empezar la práctica. Ejecuta el comando siguiente en la línea de comandos:

C:\FTP> ftp 192.168.1.100

A partir de este momento, el servidor ftp iniciará un diálogo con nuestro cliente ftp, pidiendo usuario y contraseña.

¡OJO! El meollo de este ejercicio es comprobar en tiempo real como cada acción que hacemos en el cliente ftp, se traduce en un diálogo comando-respuesta en el servidor. Por ello, debes estar viendo Wireshark al mismo tiempo que la línea de comandos con el cliente ftp ejecutándose.

Una vez que introduzcas usuario y contraseña, deberás introducir los siguientes comandos:

  1. pwd (nos indica el directorio en que nos encontramos en el servidor FTP).
  2. dir (nos muestra los archivos y directorios en el servidor FTP).
  3. !dir (nos muestra los archivos y directorios en la máquina local).
  4. put test-ftp.txt (sube al servidor ftp el archivo test-ftp.txt).
  5. ? (muestra los comandos que se pueden ejecutar en el cliente ftp).
  6. quit (cierra la sesión con el servidor ftp).

Finalmente, puedes comprobar empleando un cliente gráfico (por ejemplo Filezilla) que el archivo ha sido subido correctamente.

ENTREGAR: Captura del cliente FTP y Wireshark capturando los paquetes de la sesión FTP.

Saludos.