La capa de aplicacin

Lo siguiente es una resea al nivel de aplicacin segn CCNA 1 4.0.

3.1.1.1. Modelo OSI y TCP/IP

Recordatorio del modelo de capas.

La capa de aplicacin es la capa 7 en OSI, y la capa 5 (o 4 si capa fsica

y enlace se unen en acceso al medio) en TCP/IP.

La capa de aplicacin se utiliza para intercambiar datos entre programas

que se ejecutan en los host origen y destino.

La capa de aplicacin en TCP/IP es la capa de aplicacin + presentacin

+ sesin en OSI. Es decir, si una aplicacin requiere servicios de
presentacin y de sesin, debe implementarlos ella.

La capa de presentacin incluye cuestiones de codificiacin y conversin

de datos, compresin de datos y encriptacin.

En la prctica, en TCP/IP la presentacin se determina por estndares de la

industria. Por ej. mpg para video o jpg para imagen (que incluyen codificacin y
compresin).
La capa de sesin retoma dilogos que se interrumpieron por largos periodos.
La mayora de las aplicaciones incluyen las funcionalidades de Aplicacin,
Sesin y Presentacin, como clientes web, clientes de correo electrnico o
clientes de FTP.
Aplicaciones ms comunes son las que proporcionan intercambio de la
informacin 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 aplicacin

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

Como aplicacin: usado directamente por una persona para

comunicarse a travs de la red. Implementa la capa de aplicacin y
puede comunicarse con las capas inferiores o bien usar un servicio para
ello.

Como servicio: para ser usado por otra aplicacin para poder acceder a
las capas inferiores.

3.1.3.1. Aplicaciones de usuario, servicios y protocolos

de la capa de aplicacin.
Distinguimos entre protocolo, aplicacin y servicio:

Aplicacin: 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 mtodos adecuados
para notificacin y recuperacin de errores. Es el CMO LO HACE?

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

3.1.4.1. Funciones del protocolo de aplicacin

Los protocolos de aplicacin se usan en el origen y el destino de una
comunicacin, y deben coincidir para que sta sea exitosa.
Los protocolos establecen reglas para intercambiar datos entre las aplicaciones
y los servicios de las mquinas 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 informacin.

Existen muchos y diversos protocolos de aplicacin con diferentes finalidades

cada uno. La aplicaciones y los servicios pueden hacer uso de diferentes
protocolos de aplicacin para cumplir con su propsito.

3.2.1.1. Modelo cliente-servidor.

En el modelo cliente servidor, el dispositivo que solicita informacin 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 informacin adicional, como autenticacin
de usuario por ejemplo, o la identificacin del nombre del archivo a transferir.
Ejemplo: Un cliente de correo electrnico enva una solicitud al servidor de
correo para un mensaje no leido. El servidor enva 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
aplicacin cliente. Aunque tambin, la palabra servidor define al proceso que
escuha en un puerto y presta un servicio. Un servidor suele compartir su
informacin con muchas aplicaciones cliente, como por ejemplo un servidor
web, o de archivos.
Dependiendo del servicio que presta el servidor, habrn ms o menos
requerimientos para la conexin, pudiendo requerir diferentes grados de
autenticacin. Por ejemplo, al conectarse a un servidor FTP, puede requerirse
contrasea, y al conectarse a una pgina via https puede requerirse un
certificado electrnico.
A la aplicacin servidor tambin 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 aplicacin

Una nica aplicacin puede emplear diferentes servicios de la capa de
aplicacin. Este proceso es transparente para el usuario, y una
(aparentemente) nica solicitud puede estar compuesta de mltiples solicitudes
individuales. Adems, para cada solicitud pueden ejecutarse mltiples
procesos.

Los servidores atienden mltiples solicitudes simultneas de diferentes clientes.

Internamente, el servidor gestiona tambin las diferentes silicitudes mediante
procesos auxiliares (procesos hijo) que resuelven la solicitud.

3.2.3.2. Protocolos y servicios de la capa de Aplicacin

(actividad con PT).
Actividad 1. Empleando la topologa 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 pgina 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 trfico de red en modo simulacin, observando las siguientes

cosas:
1) La consulta DNS sobre UDP
2) El inicio de sesin TCP
3) El trfico HTTP sobre TCP
4) El cierre de sesin TCP

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

peer).
Existen otros modelos adems 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 mquina puede actuar como cliente
y como servidor. Por ejemplo, pensemos en una red domstica donde cada
mquina comparte recursos con los dems. De este modo, una mquina puede

estar accediendo a una carpeta compartida por otra, y al mismo tiempo estar
recibiendo una solicitud de impresin 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
comunicacin. Ambas pueden iniciar una comunicacin y se consideran iguales
en el proceso de comunicacin. Al iniciar una aplicacin 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 hbrido para las aplicaciones P2P, donde los recursos
compartidos siguen descentralizados, pero la informacin sobre su ubicacin
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 tambin puede ayudar a
conectar dos puntos, pero una vez conectados, la comunicacin puede llevarse
entre los dos puntos de manera autnoma.

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 informacin 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
informacin.

3.3.1.2. Protocolo y servicios DNS

El cliente DNS es llamado resolutor DNS. Aunque es el cliente DNS, en
realidad acta como un servicio para otras aplicaciones de la mquina cliente.
Un navegador web, har una consulta al resolutor, que actuar como cliente
para un servidor DNS.
Al configurar una mquina cliente, se proporciona una o ms direcciones de
servidores DNS. Esta informacin puede proporcionarla el mismo ISP o el
usuario que configura el equipo. Cuando una aplicacin 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 aplicacin 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
preguntaremos.
> www.google.com

//Ejecucin del comando indicando el servidor DNS al que

//Indicamos el nombre a resolver

Estaramos preguntando al servidor 80.58.32.33 qu ip est asociada con el

nombre www.google.com.
Se puede conocer ms sobre nslookup
en http://support.microsoft.com/kb/200525/es para Windows, o
enhttp://linux.die.net/man/1/nslookup para linux.
Nslookup es una herramienta que tiende a ser sustituida por la herramienta dig.
Prctica 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 informacin variada sobre un mismo dominio, como por
ejemplo el dominio ejemplo.com. La informacin 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 cul es el servidor de correo.
Hay diferentes tipos de registro de recurso. Algunos de ellos son:

A -> asocia un nombre con una direccin 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 informacin sobre el nombre pedido. Si
no encuentra informacin en sus registros de recurso, contacta con otros
servidores que estn ubicados en mejor posicin que l en la jerarqua DNS.
Este proceso se puede repetir en varios servidores DNS, hasta que uno sea
capaz de resolver la peticin. La respuesta llegara al servidor inicial que a su
vez respondera al cliente. Los servidores ms altos en la jerarqua 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 mquinas cliente, tambin almacenan una cach DNS con la misma
funcionalidad. Para consultar la cach DNS, en windows se puede ejectuar
"ipconfig /displaydns" y en Ubuntu tendramos que activar esta funcin (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 artculo antiguo pero

absoltamente vlido para el tema que nos
ocupa: http://multingles.net/docs/arbol.htm.
Para comprender la jerarqua DNS, tambin se puede leer el siguiente
documento:
http://lucas.hispalinux.es/Manuales-LuCAS/GARL2/garl2/x-087-2resolv.howdnsworks.html
Aqu tambin encontrars ms informacin 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 conexin con el servidor, empleando tcp para ello.
Una vez establecida la conexin, el cliente web solicita el recursos al servidor.
El servidor se los enva 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 pgina web es el siguiente:
El usuario escribe la URL de la pgina 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 direccin IP.
Una vez resuelta la direccin IP, el explorador enva una solicitud GET al
servidor, y pide el archivo index.html al servidor.
El servidor, al recibir la solicitud, enva al cliente el cdigo fuente de la pgina.

Finalmente, el navegador descifra el cdigo y da formato a la ventana del

explorador.

3.3.2.2. Servicio WWW y HTTP

HTTP forma parte de los protocolos de aplicacin de la pila TCP/IP original. Su
finalidad original era publicar y recuperar las pginas HTML. En la actualidad se
emplea para muchas otras funciones, como para sistemas de informacin
distribuidos y de colaboracin.
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 lnea 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 informacin.
POST y PUT permiten subir datos al servidor.
HTTP es un protocolo no seguro, y un usuario que intercepte la informacin
puede leerla. Por ello para una comunicacin segura se utiliza el protocolo
HTTPS que permite la autenticacin y la encriptacin para asegurar los datos
enviados.

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

El servicio de correo hace uso de ms de un protocolo. Como mnimo 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 tambin 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 reenve un correo a otro MTA en otro servidor de correo.
Finalmente, el correo llegar a un servidor que tendr el buzn 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.
Tambin se pude encargar otras tareas como anlisis de virus, filtrado de spam
y manejo de acuses de recibo.
Existen sistemas de e-mail corporativos, con funcionalidades que van ms all
del estricto envo de correo, como por ejemplo IBM Lotus Notes, Novell
Groupwise o Microsoft Exchange. Estos sistemas pueden tener su propio
formato de correo electrnico interno mediante protocolos propietarios.
Los sistemas de correo corporativo tienen un gateway a travs del cual envan
correos al exterior. Dicho gateway realiza la conversin necesaria a protocolos
estndar. 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 envo de correo entrante.
Cuando el cliente se conecta (MUA) al servidor, ste puede enviar los correos
del buzn 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 rgido de comandos y respuestas, como "inicio de
sesin", "transaccin de correo", "reenvo de correo", "verificacin de nombres
buzones", "expansin de listas de correo" y "apertura y cierre de intercambios".
Algunos de los comandos son:

HELO: Inicia la conversacin con otro servidor de correo.

EHLO: Versin ms nueva de HELO.

MAIL FROM: Indica quin envia el correo.

RCPT: Indica quin 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 conexin, se realiza otra conexin 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 asignacin 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 tamao.
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 estticas y no varien.
Puede haber servicio DHCP en redes inalmbris pblicas, privadas,
domsticas. En el caso de las redes domsticas el servidor DHCP estar en el
lado del ISP de forma que los routers tomarn una direccin 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, enva un paquete de
DESCUBRIMIENTO DHCP para identificar al servidor DHCP. El servidor
contesta con una OFERTA DHCP, ofreciendo IP, mscara de subred, DNS,
puerta de enlace y duracin de la asignacin.
En ocasiones hay ms de un servidor DHCP, en cuyo caso el cliente tendr que
elegir entre las ofertas.
Si el cliente acepta la asignacin, enva otro mensaje aceptando la oferta e
identificando el servidor DHCP del que provena la oferta.
Si el servidor est de acuerdo enva un paquete DHCP ACK confirmando la
reserva. Si no est de acuerdo, enva 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 sesin con un recurso compartido, la
sesin permanece abierta tanto tiempo como la sesin 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 tambin implementa una versin de SMB mediante el servidor SAMBA,
gracias la cual un servidor Linux puede compartir recursos en una red
Microsoft. Apple, al basarse en UNIX, tambin 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 cmo acceden a
los recursos. Todos los mensajes SMB tienen el mismo formato, con
encabezado de tamao fijo.
Los mensajes SMB pueden iniciar, autenticar y terminar sesiones, controlar el
acceso a archivos e impresoras, y permitir a una aplicacin enviar o recibir
mensajes hacia o desde otro dispositivo.
Prctica 3. En esta prctica, escuchars mediante Wireshark el trfico que
se produce (a nivel de aplicacin) al abrir una pgina web usando el
navegador. El cliente web enva un paquete HTTP al servidor, incluyendo
un comando de control GET para solicitar el recurso. Entonces el servidor
enva el recurso al cliente. Debers:
1. Abrir un navegador web y abrir la siguiente
direccin: http://192.168.10.100/web2011/index.php
2. Encontrar el comando GET donde se solicita dicha pgina
3. Encontrar la transferencia del contenido de la pgina al cliente
Podrs comprobar que finalmente se cierra la conexin TCP.
Entregar: 1. Contenido del paquete donde el cliente solicita la pgina web
(visualizar el contenido del paquete mediante Wireshark). 2. Paquete
donde se transfiere el contenido de la pgina al cliente.
Prctica 4. Para insistir un poco ms en la idea de "Protocolo de
aplicacin = juego de comandos/respuestas", vamos usar el protocolo
FTP desde la lnea de comandos. La idea de este ejercicio es que
compruebes como la interaccin 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 almacenars 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 continuacin abre un lnea 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 mquina, y aplicando el siguiente filtro: ftp.
Ahora podemos empezar la prctica. Ejecuta el comando siguiente en la
lnea de comandos:
C:\FTP> ftp 192.168.1.100

A partir de este momento, el servidor ftp iniciar un dilogo con nuestro

cliente ftp, pidiendo usuario y contrasea.
OJO! El meollo de este ejercicio es comprobar en tiempo real como
cada accin que hacemos en el cliente ftp, se traduce en un dilogo
comando-respuesta en el servidor. Por ello, debes estar viendo
Wireshark al mismo tiempo que la lnea de comandos con el cliente
ftp ejecutndose.
Una vez que introduzcas usuario y contrasea, debers 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 mquina 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 sesin con el servidor ftp).
Finalmente, puedes comprobar empleando un cliente grfico (por ejemplo
Filezilla) que el archivo ha sido subido correctamente.

ENTREGAR: Captura del cliente FTP y Wireshark capturando los paquetes

de la sesin FTP.
Bibliografa: http://www.mauriciomatamala.net/PAR/aplicacion.php