Capitulo 05 Capa de Aplicacion

Teleinformtica y comunicaciones
Capitulo 5
Capa de Aplicacin
La capa de aplicacin es aquella en la que se definen los protocolos, que se traducen en una
utilidad especfica para el usuario final, o que definen una estructura de servicios para aplicaciones
de ms alto nivel Es el nivel mas alto, los usuarios llaman a una aplicacin que acceda servicios
disponibles a travs de la red de redes TCP/IP. Una aplicacin interacta con uno de los protocolos
de nivel de transporte para enviar o recibir datos. Cada programa de aplicacin selecciona el tipo
de transporte necesario, el cual puede ser una secuencia de mensajes individuales o un flujo
continuo de octetos. El programa de aplicacin pasa los datos en la forma requerida hacia el nivel
de transporte para su entrega Contiene toda la lgica necesaria para llevar a cabo las aplicaciones
de usuario. Para cada tipo especfico de aplicacin, como es por ejemplo la transferencia de un
archivo, se necesitar un mdulo particular dentro de esta capa.
Invoca programas que acceden servicios en la red. Interactan con uno o ms protocolos de
transporte para enviar o recibir datos, en forma de mensajes o bien en forma de flujos de bytes.
Mdulos de la capa de Aplicacin

1- Bootp
2- TFTP
3- Dhcp
4- NFS
5- DNS
6- SMTP
7- Telnet
8- POPx
9- Rlogin
10- MIME
11- FTP
12- SNMP
Los protocolos de mximo nivel se denominan protocolos de aplicacin. Se comunican con

aplicaciones en otros hosts de internet y constituyen la interfaz de usuario con la pila de protocolos
TCP/IP.
Caractersticas de las aplicaciones

Todos los protocolos de alto nivel tienen algunas caractersticas en comn:
Pueden ser aplicaciones escritas por el usuario o aplicaciones estandarizadas y
distribuidas con un producto TCP/IP. De hecho, la pila TCP/IP incluye protocolos de
aplicacin tales como:
o TELNET para el acceso interactivo de una terminal a un host remoto.
o FTP ("File Transfer Protocol") para transferencias de alta velocidad de un disco a
otro.
o SMTP ("simple mail transfer protocol") como sistema de correo de Internet.
Ing. Jorge Colombo
Pag: 1
Estas son las aplicaciones implementadas ms ampliamente, pero existen muchas

otras. Cada imp TCP/IP particular incluye un conjunto ms o menos restringido de
protocolos de aplicacin.
Usan UDP o TCP como mecanismo de transporte. Recordar que UDP no es fiable ni ofrece
control de flujo, por lo que en este caso la aplicacin ha de proporcionar sus propia rutinas
de recuperacin de errores y de control de flujo. Suele ser ms fcil desarrollar
aplicaciones sobre TCP, un protocolo fiable, orientado a conexin. La mayora de los
protocolos de aplicacin utilizan TCP, pero algunas aplicaciones se construyen sobre UDP
para proporcionar un mejor rendimiento reduciendo la carga del sistema que genera el
protocolo.
La mayora de ellas usa el modelo de interaccin cliente/servidor.
Modelo cliente/servidor
TCP es un protocolo orientado a conexin. No hay relaciones maestro/esclavo. Las aplicaciones,
sin embargo, utilizan un modelo cliente/servidor en las comunicaciones.
Un servidor es una aplicacin que ofrece un servicio a usuarios de Internet; un cliente es el que
pide ese servicio. Una aplicacin consta de una parte de servidor y una de cliente, que se pueden
ejecutar en el mismo o en diferentes sistemas.
Los usuarios invocan la parte cliente de la aplicacin, que construye una solicitud para ese servicio
y se la enva al servidor de la aplicacin que usa TCP/IP como transporte.
El servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los
resultados en forma de una respuesta. Generalmente un servidor puede tratar mltiples
peticiones(mltiples clientes) al mismo tiempo.
Figura: El modelo de aplicacin cliente/servidor

Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes
saben a que zcalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para
comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien
conocido tienen otro mecanismo para saber a qu puerto dirigirse..
Protocolo BOOTstrap - BOOTP

En lugar de utilizar el protocolo ARP, una maquina que acaba de ponerse en funcionamiento por
primera vez, puede utilizar el protocolo bootstrap para obtener la direccion IP y informacin sobre
su sector de arranque. Este metodo tiene algunas ventajas respecto al del protocolo ARP.
BOOTP es un borrador de protocolo de Internet.. Las especificaciones de BOOTP se pueden
encontrar en los RFC 951 - Bootstrap y RFC 1497 - Extensiones de la informacin de los
distribuidores de BOOTP.
Ing. Jorge Colombo
Pag: 2
Adems hay actualizaciones de BOOTP que lo permiten interoperar con DHCP. Estas se describen
en el RFC 1542 - Aclaraciones y extensiones para el protocolo Bootstrap que actualiza a los RFC
951 y RFC 1533 - Opciones y extensiones de DHCPs, que desfasa al RFC 1497.
Las LANs hacen posible usar host sin disco como estaciones de trabajo, "routers" concentradores
de terminales, etc. Los host sin disco requieren de algn mecanismo para el arranque remoto sobre
una red. El protocolo BOOTP se utiliza para efectuar arranques remotos en redes IP. Permite que
una pila de IP mnima sin informacin de configuracin, tpicamente almacenada en la ROM,
obtenga informacin suficiente para comenzar el proceso de descargar el cdigo de arranque
necesario. BOOTP no define como se realiza esta descarga, pero habitualmente se emplea TFTP
El proceso BOOTP implica los siguientes pasos:
1. El cliente determina su propia direccin hardware; esta suele estar en una ROM del
hardware.
2. El cliente BOOTP enva su direccin hardware en un datagrama UDP al servidor. Si el
cliente conoce su direccin IP y/o la direccin del servidor, debera usarlas, pero en general
los clientes BOOTP carecen de configuracin IP en absoluto. Si el cliente desconoce su
direccin IP, emplea la 0.0.0.0. Si desconoce la direccin IP del servidor, utiliza la direccin
de broadcast limitado(255.255.255.255). El nmero del puerto UDP es el 67.
3. El servidor recibe el datagrama y busca la direccin hardware del cliente en su archivo de
configuracin, que contiene la direccin IP del cliente. El servidor rellena los campos
restantes del datagrama UDP y se lo devuelve al cliente usando el puerto 68. Hay tres
mtodos posibles para hacer esto:
1- Si el cliente conoce su propia direccin IP(incluida en la solicitud BOOTP),
entonces el servidor devuelve directamente el datagrama a esa direccin. Es
probable que la cach de ARP en la pila de protocolos del servidor desconozca la
direccin hardware correspondiente a esa direccin IP. Se har uso de ARP para
determinarla del modo habitual.
2- Si el cliente desconoce su propia direccin IP(0.0.0.0 la solicitud BOOTP),
entonces el servidor se ocupa de averiguarla con su propia cach de ARP. El
servidor no puede usar ARP para resolver la direccin hardware del cliente porque
el cliente no sabe su direccin IP y por lo tanto no puede responder a una peticin
ARP. Es el problema de la pescadilla que se muerde la cola. Hay dos soluciones
posibles:
1. Si el servidor tiene un mecanismo para actualizar directamente su propia
cach ARP sin usar ARP, lo utiliza y enva directamente el datagrama.
2. Si el servidor no puede actualizar su propia cach, debe enviar una
respuesta en forma de broadcast.
3- Cuando reciba la respuesta, el cliente BOOTP grabar su direccin IP(permitindole
responder a peticiones ARP) y comenzar el proceso de arranque.
Ing. Jorge Colombo
Pag: 3
Figura: Formato de mensaje de BOOTP

code
Indica una solicitud o una respuesta
1
Request
2
Reply
HWtype
El tipo de hardware, por ejemplo:
1
Ethernet
6
IEEE 802 Networks
length
Longitud en bytes de la direccin hardware. Ethernet y las redes en anillo usan 6, por
ejemplo.
hops
El cliente lo pone a 0. Cada "router" que retransmite la solicitud a otro servidor lo
incrementa, con el fin de detectar bucles. El RFC 951 sugiere que un valor de 3 indica un
bucle.
Transaction ID
Nmero aleatorio usado para comparar la solicitud con la respuesta que genera.
Seconds
Fijado por el cliente. Es el tiempo transcurrido en segundos desde que el cliente inici el
proceso de arranque.
Flags Field
El bit ms significante de este campo se usa como flag de broadcast. Todos los dems bits
deben estar a 0; estn reservados para usos futuros. Normalmente, los servidores BOOTP
tratan de entregar los mensajes BOOTREPLY directamente al cliente usando unicast. La
Ing. Jorge Colombo
Pag: 4
direccin de destino en la cabecera IP se pone al valor de la direccin IP fijada por el
servidor BOOTP, y la direccin MAC a la direccin hardware del cliente BOOTP. Si un host
no puede recibir un datagrama IP en unicast hasta saber su propia direccin IP, el bit de
broadcast se debe poner a 1 para indicar al servidor que el mensaje BOOTREPLY se debe
enviar como un broadcast en IP y MAC. De otro modo, este bit debe ponerse a cero.
Client IP adress
Fijada por el cliente. O bien es su direccin IP real , o 0.0.0.0.
Your IP Address
Fijada por el servidor si el valor del campo anterior es 0.0.0.0
Server IP address
Fijada por el servidor.
Router IP address
Fijada por el "router" retransmisor si se usa retransmisin BOOTP.
Client hardware address
Fijada por el cliente y usada por el servidor para identificar cul de los clientes registrados
est arrancando.
Server host name
Nombre opcional del host servidor acabado en X'00'.
Boot file name
El cliente deja este campo vaco o especifica un nombre genrico, tal como "router",
indicando el tipo de archivo de arranque a usar. El servidor devuelve el nombre completo
del archivo o bien el de un archivo de arranque adecuado para el cliente. Su valor tiene
como terminador a la secuencia X'00.
Vendor-specific area
rea especfica del distribuidor(opcional). Se recomienda que el cliente llene siempre los
cuatro primeros bytes con un "magic cookie" o galleta mgica. Si el cookie especfica de un
distribuidor no se usa, el cliente debera utilizar 99.130.83.99 seguido de una marca de
fin(255) y fijar los bis restantes a cero. Remitirse al RFC 1533 para ms detalles.
Una restriccin a este esquema es el uso del broadcast limitado para las solicitudes
BOOTP; requiere que el servidor est en la misma subred que el cliente. La retransmisin
BOOTP es un mecanismo para que los "routers" transmitan solicitudes BOOTP. Es una
opcin de configuracin disponible en algunos "routers".
Una vez que el cliente BOOTP ha procesado la respuesta, puede proceder con la
transferencia del archivo de arranque y ejecutar el proceso de arranque completo. El
proceso de arranque completo reemplaza la pila mnima de IP usada por BOOTP y TFTP
por una pila IP normal transferida como parte del archivo de arranque, que contiene la
configuracin correcta para el cliente.
DHCP("Dynamic Host Configuration Protocol")

DHCP proporciona un entorno de trabajo para pasar informacin de configuracin a hosts en una
red TCP/IP. DHCP se basa en el protocolo BOOTP, aadiendo la capacidad de asignar
automticamente direcciones de red reutilizables y opciones de configuracin adicionales. Los
elementos participantes en DHCP pueden interoperar con los de BOOTP(RFC 1534).
DHCP consta de dos componentes:
1. Un protocolo que entrega parmetros de configuracin especficos de un host de un
servidor DHCP al host.
2. Un mecanismo para reservar direcciones de red para los hosts.
IP requiere la configuracin de muchos parmetros dentro del software de implementacin del
protocolo. Debido a que IP utilizar en muchas clases distintas de hardware de red, no se puede
suponer o adivinar que los valores de esos parmetros tienen valores correctos por defecto. El uso
de un sistema de asignacin de direcciones distribuidas basado en un mecanismo de
consulta/defensa, para descubrir direcciones de red que ya estn en uso, no garantiza direcciones
de red unvocas porque puede que los host no sean siempre capaces de defender sus direcciones
de red.
Ing. Jorge Colombo
Pag: 5
DHCP soporta tres mecanismos para la asignacin de direcciones IP:
1. Asignacin automtica
DHCP asigna al host una direccin IP permanente.
2. Asignacin dinmica
DHCP asigna una direccin IP por un periodo de tiempo limitado. Una red as se denomina
arrendamiento. Este es el nico mecanismo que permite la reutilizacin automtica de
direcciones que ya no son necesitadas por los hosts a los que estaban asignadas.
3. Asignacin manual
La direccin del host es asignada por el administrador de red
Figure: Formato del mensaje DHCP

code
Indica solicitud o respuesta
1
Request
2
Reply
HWtype
El tipo de hardware, por ejemplo:
1
Ethernet
6
IEEE 802 Networks
length
Ing. Jorge Colombo
Pag: 6
Longitud en bytes de la direccin hardware. Ethernet y las redes en anillo usan 6, por
ejemplo.
hops
El cliente lo pone a 0. Cada "router" que retransmite la solicitud a otro servidor lo
incrementa, con el fin de detectar bucles. El RFC 951 sugiere que un valor de 3 indica un
bucle.
Transaction ID
Nmero aleatorio usado para comparar la solicitud con la respuesta que genera.
Seconds
Fijado por el cliente. Es el tiempo transcurrido en segundos desde que el cliente inici el
proceso de arranque.
Flags Field
El bit ms significante de este campo se usa como flag de broadcast. Todos los dems bits
deben estar a 0; estn reservados para usos futuros. Normalmente, los servidores DHCP
tratan de entregar los mensajes DHCPREPLY directamente al cliente usando unicast. La
direccin de destino en la cabecera IP se pone al valor de la direccin IP fijada por el
servidor DHCP, y la direccin MAC a la direccin hardware del cliente DHCP. Si un host no
puede recibir un datagrama IP en unicast hasta saber su propia direccin IP, el bit de
broadcast se debe poner a 1 para indicar al servidor que el mensaje DHCPREPLY se debe
enviar como un broadcast en IP y MAC. De otro modo, este bit debe ponerse a cero.
Client IP adress
Fijada por el cliente. O bien es su direccin IP real , o 0.0.0.0.
Your IP Address
Fijada por el servidor si el valor del campo anterior es 0.0.0.0
Server IP address
Fijada por el servidor.
Router IP address
Fijada por el "router" retransmisor si se usa retransmisin BOOTP.
Client hardware address
Fijada por el cliente y usada por el servidor para identificar cul de los clientes registrados
est arrancando.
Server host name
Nombre opcional del host servidor acabado en X'00'.
Nombre del archivo de arranque
El cliente o bien deja este campo vaco o especifica un nombre genrico, como "router"
indicando el tipo de archivo de arranque a usar. En la solicitud de DHCPDISCOVER se
pone al valor nulo. El servidor devuelve el la ruta de acceso completa del archivo en una
respuesta DHCPOFFER. El valor termina en X'00'.
Options
Los primeros cuatro bytes del campo de opciones del mensaje DHCP contienen el
cookie(99.130.83.99). El resto del campo de opciones consiste en parmetros marcados
llamados opciones. Remitirse al RFC 1533 para ms detalles.
Almacn de parmetros de configuracin

DHCP permite un almacenamiento persistente de los parmetros de red de los clientes. El modelo
de almacenamiento persistente en DHCP consiste en que el servicio DHCP almacena una entrada
con un valor y una clave para cada cliente, donde la clave es un identificador nico, por ejemplo un
nmero IP de subred y un identificador nico dentro de la subred, y el valor contiene los
parmetros de configuracin del cliente.
Asignando un nueva direccin de red

Esta seccin describe la interaccin del cliente servidor cuando el cliente no conoce su direccin de
red. Se asume que el servidor DHCP tiene un bloque de direcciones de red con el que puede
Ing. Jorge Colombo
Pag: 7
satisfacer peticiones de nuevas direcciones. Cada servidor mantiene adems una base de datos
local y permanente de las direcciones asignadas y de los arrendamientos.
1. El cliente hace un broadcast de un mensaje DHCPDISCOVER en su subred fsica. El
mensaje DHCPDISCOVER puede incluir algunas opciones como sugerencias de la
direccin de red, duracin del arrendamiento, etc.
2. Cada servidor puede responder con un mensaje DHCPOFFER que incluye una direccin
de red disponible y otras opciones de configuracin.
3. El cliente recibe uno o ms mensaje DHCPOFFER de uno o ms servidores. Elige uno
basndose en los parmetros de configuracin ofertados y hace un broadcast de un
mensaje DHCPREQUEST que incluye la opcin identificadora del servidor para indicar qu
mensaje ha seleccionado.
4. Los servidores reciben el broadcast de DHCPREQUEST del cliente. Los servidores no
seleccionados utilizan el mensaje como notificacin e que el cliente ha declinado su oferta.
El servidor seleccionado vincula al cliente al almacenamiento persistente y responde con
un mensaje DHCPACK que contiene los parmetros de configuracin para el cliente. La
combinacin de las direcciones hardware y asignada del cliente constituyen un
identificador nico de su arrendamiento y las usan tanto el cliente como el servidor para
identificar cualquier arrendamiento al que se haga referencia en un mensaje DHCP. El
campo "your IP address" en los mensaje DHCPACK se rellena con la direccin de red
seleccionada.
5. El cliente recibe el mensaje DHCPACK con parmetro de configuracin. Realiza un
chequeo final de estos parmetros, por ejemplo con ARP para la direccin de red
asignada, y registra la duracin del arrendamiento y el cookie de identificacin de ste
especificado en el mensaje DHCPACK. En este punto, el cliente est configurado. Si el
cliente detecta un problema con los parmetros en el mensaje DHCPACK, enva un
mensaje DHCPDECLINE al servidor y reinicia el proceso de configuracin. El cliente
debera esperar un mnimo de diez segundos antes de reiniciar este proceso para evitar un
exceso de trfico en la red en caso de que se produzca algn bucle.
Si el cliente recibe un mensaje, reinicia el proceso de configuracin.
6. Puede elegir renunciar a su arrendamiento enviando un mensaje DHCPRELEASE al
servidor. El cliente especifica el arrendamiento al que renuncia incluyendo sus direcciones
hardware y de red
Reutilizando una direccin de red previamente asignada

Si el cliente recuerda y desea usar una direccin de red previamente asignada se llevan a cabo
los siguientes pasos:
1. El cliente hace un broadcast de un mensaje DHCPREQUEST en su subred. Este mensaje
incluye la direccin de red del cliente.
2. Los servidores que conozcan los parmetros de configuracin del cliente le responden con
un mensaje DHCPACK.
3. El cliente recibe el mensaje DHCPACK con parmetros de configuracin. Efecta un ltimo
chequeo de estos y registra la duracin del arrendamiento y el cookie de identificacin de
este, especificado en el DHCPACK. En este punto, el cliente est configurado.
Si el cliente detecta algn problema con los parmetros en el DHCPACK, enva un
mensaje DHCPDECLINE al servidor y reinicia el proceso de configuracin solicitando
una nueva direccin de red. Si el cliente recibe un mensaje DHCPNAK, no puede
reutilizar la direccin que solicit. En vez de eso debe pedir una nueva direccin
reiniciando el proceso de configuracin descrito en Asignando una nueva direccin de
red. El cliente puede elegir renunciar a su arrendamiento de la direccin de red al
enviar un mensaje DHCPRELEASE al servidor. Identifica el arrendamiento al que
renuncia con el cookie de identificacin.
Ing. Jorge Colombo
Pag: 8
Nota: Un host debera usar DHCP para readquirir o verificar su direccin IP y sus parmetros de
configuracin siempre que cambien los parmetros de su red local, por ejemplo en el arranque del
sistema o despus de una desconexin de la red local, ya que la configuracin de esta puede
haber cambiado sin que lo sepa el host o el usuario.
DNS (Domain Name System)
Figura: El DNS
En los orgenes de Internet, cuando slo haba unos cientos de computadores conectados, la tabla
con los nombres de dominio y direcciones IP se encontraba almacenada en un nico computador
con el nombre de HOSTS.TXT. El resto de computadores deban consultarle a ste cada vez que
tenan que resolver un nombre. Este archivo contena una estructura plana de nombres, tal como
hemos visto en el ejemplo anterior y funcionaba bien ya que la lista slo se actualizaba una o dos
veces por semana.
Sin embargo, a medida que se fueron conectando ms computadores a la red comenzaron los
problemas: el archivo HOSTS.TXT comenz a ser demasiado extenso, el mantenimiento se hizo
difcil ya que requera ms de una actualizacin diaria y el trfico de la red hacia este computador
lleg a saturarla.
Es por ello que fue necesario disear un nuevo sistema de resolucin de nombres que distribuyese
el trabajo entre distintos servidores. Se ide un sistema jerrquico de resolucin conocido como
DNS (Domain Name System, sistema de resolucin de nombres).
[RFC1034] [RFC1035] es el responsable, fundamentalmente, de realizar la traduccin entre un
nombre jerquico y una serie de "identificadores" asociados. Dichos identificadores pueden
constituir cualquier informacin de inters prctico.
Tradicionalmente estos sistemas se han utilizado para la obtencin de la direccin IP de una
mquina dado su nombre jerrquico, as como para identificar la mquina o mquinas
responsables de un dominio de correo. No sera exagerado decir que el DNS constituye el
verdadero ncleo aglutinador de una red de las caractersticas de "Internet", ya que es lo que
proporciona al usuario una visin homogenea y organizada de las mquinas y servicios
disponibles.
El servidor de denominacin de dominio (DNS) es un dispositivo ubicado en una red. Responde a
las peticiones que realizan los clientes para traducir un nombre de dominio a la direccin IP
asociada. El sistema DNS se basa en una jerarqua que crea distintos niveles de servidores DNS.
Si un DNS local puede traducir un nombre de dominio a su direccin IP asociada, lo hace y
devuelve el resultado al cliente. Si no logra traducir la direccin, transfiere la peticin al siguiente
servidor DNS de nivel superior del sistema, que intenta entonces traducir la direccin. Si el DNS de
este nivel puede traducir el nombre de dominio a su direccin IP asociada, lo hace y devuelve el
resultado al cliente De no ser as, enva la solicitud al siguiente nivel superior. Este proceso se
vuelve a repetir hasta que el nombre de dominio se haya traducido o que se haya alcanzado el
nivel DNS ms elevado. Si no se puede encontrar el nombre de dominio en el nivel DNS superior,
se considera como error y se devuelve el mensaje de error correspondiente.
Ing. Jorge Colombo
Pag: 9
Cualquier tipo de aplicacin que utiliza nombres de dominio para representar direcciones IP utiliza
DNS para traducir ese nombre a la direccin IP correspondiente
Siempre que un cliente de correo electrnico enva cartas, solicita a un servidor DNS, conectado a
la red, que traduzca los nombres de dominio a sus direcciones IP asociadas. Si DNS puede
traducir los nombres, devuelve la direccin IP a los clientes, permitiendo de esta manera la
segmentacin y el encapsulamiento correcto en la capa de transporte. Si DNS no puede traducir
los nombres, las solicitudes se transfieren hasta que los nombres se hayan traducido.
La parte de la direccin de correo electrnico que contiene el nombre del destinatario (receptor)
cobra importancia en este punto. El servidor lo extrae del mensaje de correo electrnico y verifica
que la persona sea un usuario de la oficina de correos. Si el destinatario es un usuario, guarda el
mensaje en su buzn hasta que alguien lo recupere. Si el destinatario no es un usuario, la oficina
de correos genera un mensaje de error y enva el mensaje de vuelta al remitente.
La segunda parte del proceso de correo electrnico es el proceso de recepcin. Los destinatarios
de mensajes de correo electrnico deben utilizar el software cliente de correo electrnico en sus
computadoras para realizar peticiones a las oficinas postales de correo electrnico. Cuando el
destinatario del mensaje hace clic en los botones "Recibir correo" o "Recuperar correo" en el
programa de correo electrnico, generalmente se le solicita que ingrese una contrasea. Una vez
que han ingresado la contrasea y han hecho clic en "Aceptar", el software de correo electrnico
crea una peticin para los servidores de la oficina de correos. Luego extrae las direcciones de la
oficina de correos de los datos de configuracin que se escribieron cuando se configur el software
de correo electrnico. El proceso usa luego otra verificacin DNS para buscar las direcciones IP de
los servidores. Finalmente, las peticiones son segmentadas y secuenciadas por la capa de
transporte.
Los paquetes de datos se transportan a travs de las capas restantes del modelo OSI (es decir, de
red, de enlace de datos y fsica) y se retransmiten a travs de Internet a la oficina de correo
electrnico destino. Una vez que llegan a la oficina de correos, los paquetes se reensamblan en la
secuencia correcta y se verifica si se ha producido algn error de transmisin de datos.
En la oficina de correo, se examinan las peticiones y se verifican los nombres de usuario y las
contraseas. Si todo est en orden, el servidor de la oficina de correos transmite todos los
mensajes de correo electrnico a los computadoras, donde los mensajes se vuelven a segmentar,
secuenciar y encapsular como tramas de datos, para ser enviados al computador del cliente o del
destinatario del correo electrnico.
Despus de que los mensajes de correo electrnico llegan al computador, se pueden abrir y leer. Si
hace clic en el botn "Responder" o "Reenviar", para enviar una respuesta a los mensajes, se
vuelve a iniciar todo el proceso. Los mensajes de correo electrnico se envan normalmente como
texto ASCII, pero los archivos que se adjuntan a ellos pueden ser de audio, vdeo, grficos o de
cualquier otro tipo de datos. Para enviar y recibir correctamente los archivos adjuntados, los
esquemas de codificacin deben ser los mismos en el computador emisor y receptor. Los dos
formatos ms comunes para los archivos adjuntos de correo electrnico son Extensin de Correo
Multipropsito para Internet (MIME) y UUencode (una utilidad Unix).
Nota: Aunque los dominios dentro del espacio de nombres se mapean con frecuencia a redes y
subredes con el mecanismo de direccionamiento IP, este no es un requisito del DNS. Considerar
un "router" entre dos subredes: tiene dos direcciones IP, una por cada adaptador, pero
normalmente no tiene por qu poseer dos nombres simblicos.
Componentes del DNS

Ing. Jorge Colombo
Pag: 10
Para su funcionamiento, el DNS utiliza tres componentes principales:
Clientes DNS (resolvers). Los clientes DNS envan las peticiones de resolucin de
nombres a un servidor DNS. Las peticiones de nombres son preguntas de la forma: Qu
direccin IP le corresponde al nombre nombre.dominio?
Servidores DNS (name servers). Los servidores DNS contestan a las peticiones de los
clientes consultando su base de datos. Si no disponen de la direccin solicitada pueden
reenviar la peticin a otro servidor.
Espacio de nombres de dominio (domain name space). Se trata de una base de datos
distribuida entre distintos servidores.
Espacio de nombres de dominio

El espacio de nombres de dominio es una estructura jerrquica con forma de rbol que clasifica los
distintos dominios en niveles. A continuacin se muestra una pequea parte del espacio de
nombres de dominio de Internet:
El punto ms alto de la jerarqua es el dominio raz. Los dominios de primer nivel (es, edu, com...)
parten del dominio raz y los dominios de segundo nivel (upm, ucm, novell..), de un dominio de
primer nivel; y as sucesivamente. Cada uno de los dominios puede contener tanto hosts como ms
subdominios.
Un nombre de dominio es una secuencia de nombres separados por el carcter delimitador punto.
Por ejemplo, www.vaneduc.edu.ar.
Los dominios de primer nivel (Top-Level Domains) han sido clasificados tanto en funcin de su
estructura organizativa como geogrficamente. Ejemplos:
En funcin de su estructura organizativa:

Nombre de dominio Significado
com
organizaciones comerciales
net
redes
org
otras organizaciones
instituciones
educativas
edu
universidades
Ing. Jorge Colombo
Pag: 11
gov
mil
organizaciones gubernamentales
organizaciones militares
Geogrficamente:
Nombre de dominio
es
tw
fr
tv
ar
Significado
Espaa
Taiwn
Francia
Tuvalu
Argentina
Zonas de autoridad
Una zona de autoridad es la porcin del espacio de nombres de dominio de la que es responsable
un determinado servidor DNS. La zona de autoridad de estos servidores abarca al menos un
dominio y tambin pueden incluir subdominios; aunque generalmente los servidores de un dominio
delegan sus subdominios en otros servidores.
Tipos de servidores DNS

Dependiendo de la configuracin del servidor, ste puede desempear distintos papeles:
Servidores primarios (primary name servers). Estos servidores almacenan la informacin

de su zona en una base de datos local. Son los responsables de mantener la informacin
actualizada y cualquier cambio debe ser notificado a este servidor .
Servidores secundarios (secundary name servers). Son aquellos que obtienen los datos de
su zona desde otro servidor que tenga autoridad para esa zona. El proceso de copia de la
informacin se denomina transferencia de zona.
Servidores maestros (master name servers). Los servidores maestros son los que
transfieren las zonas a los servidores secundarios. Cuando un servidor secundario arranca
busca un servidor maestro y realiza la transferencia de zona. Un servidor maestro para una
zona puede ser a la vez un servidor primario o secundario de esa zona. Estos servidores
extraen la informacin desde el servidor primario de la zona. As se evita que los servidores
secundarios sobrecargen al servidor primario con transferencias de zonas.
Servidores locales (caching-only servers). Los servidores locales no tienen autoridad sobre
ningn dominio: se limitan a contactar con otros servidores para resolver las peticiones de
los clientes DNS. Estos servidores mantienen una memoria cach con las ltimas
preguntas contestadas. Cada vez que un cliente DNS le formula una pregunta, primero
consulta en su memoria cach. Si encuentra la direccin IP solicitada, se la devuelve al
cliente; si no, consulta a otros servidores, apunta la respuesta en su memoria cach y le
comunica la respuesta al cliente.
Los servidores secundarios son importantes por varios motivos. En primer lugar, por seguridad
debido a que la informacin se mantiene de forma redundante en varios servidores a la vez. Si un
Ing. Jorge Colombo
Pag: 12
servidor tiene problemas, la informacin se podr recuperar desde otro. Y en segundo lugar, por
velocidad porque evita la sobrecarga del servidor principal distribuyendo el trabajo entre distintos
servidores situados estratgicamente (por zonas geogrficas, por ejemplo).
Resolucin de nombres de dominio

La resolucin de un nombre de dominio es la traduccin del nombre a su correspondiente direccin
IP. Para este proceso de traduccin los resolvers pueden formular dos tipos de preguntas
(recursivas e iterativas).
Preguntas recursivas. Si un cliente formula una pregunta recursiva a un servidor DNS,

ste debe intentar por todos los medios resolverla aunque para ello tenga que preguntar a
otros servidores.
Preguntas iterativas. Si, en cambio, el cliente formula una pregunta iterativa a un servidor
DNS, este servidor devolver o bien la direccin IP si la conoce o si no, la direccin de otro
servidor que sea capaz de resolver el nombre.
Veamos un ejemplo: Estamos trabajando con Internet Explorer y escribimos en la barra de

direccin: www.ibm.com. En primer lugar, el navegador tiene que resolver el nombre de dominio a
una direccin IP. Despus podr comunicarse con la correspondiente direccin IP, abrir una
conexin TCP con el servidor y mostrar en pantalla la pgina principal de IBM. La siguiente grfica
muestra el esquema de resolucin:
1. Nuestra computadora (cliente DNS) formula una pregunta recursiva a nuestro servidor
DNS local (generalmente el proveedor de Internet).
2. El servidor local es el responsable de resolver la pregunta, aunque para ello tenga que
reenviar la pregunta a otros servidores. Suponemos que no conoce la direccin IP
asociada a www.ibm.com; entonces formular una pregunta iterativa al servidor del
dominio raz.
3. El servidor del dominio raz no conoce la direccin IP solicitada, pero devuelve la direccin
del servidor del dominio com.
4. El servidor local reenva la pregunta iterativa al servidor del dominio com.
Ing. Jorge Colombo
Pag: 13
5. El servidor del dominio com tampoco conoce la direccin IP preguntada, aunque s conoce
la direccin del servidor del dominio ibm.com, por lo que devuelve esta direccin.
6. El servidor local vuelve a reenvar la pregunta iterativa al servidor del dominio ibm.com.
7. El servidor del dominio ibm.com conoce la direccin IP de www.ibm.com y devuelve esta
direccin al servidor local.
8. El servidor local por fin ha encontrado la respuesta y se la reenva a nuestra computadora.
Preguntas inversas
Los clientes DNS tambin pueden formular preguntas inversas, esto es, conocer el nombre de
dominio dada una direccin IP. Para evitar una bsqueda exhaustiva por todo el espacio de
nombres de dominio, se ha creado un dominio especial llamado in-addr.arpa. Cuando un cliente
DNS desea conocer el nombre de dominio asociado a la direccin IP a.b.c.d, formula una pregunta
inversa a d.c.b.a.in-addr.arpa. La inversin de los bytes es necesaria debido a que los nombres de
dominio son ms genricos por la derecha, al contrario que ocurre con las direcciones.
SMTP (Simple Mail Transfer Protocol)
Fi
gura: SMTP("Simple Mail Transfer Protocol")
El correo electrnico (E-mail) es probablemente la aplicacin TCP/IP ms usada. Los protocolos de
correo bsicos de correo proporcionan intercambio de correo y mensajes entre hosts TCP/IP hosts;
se han aadido servicios para la transmisin de datos que no se pueden representar con texto
ASCII de 7 bits.
Hay tres protocolos estndares que se aplican a este tipo de correo. Todos son recomendados. El
trmino SMTP se emplea con frecuencia para referirse a la combinacin de los tres protocolos, por
su estrecha interrelacin, pero estrictamente hablando, SMTP es slo uno de los tres.
Normalmente, el contexto hace evidente de cul de los tres se est hablando. Cuando haya
ambigedad, se emplearn los nmeros STD o RFC. Los tres estndares son:
Un estndar para el intercambio de correo entre dos computadoras(STD 10/RFC 821), que
especifica el protocolo usado para enviar correo entre hosts TCP/IP. Este estndar es
SMTP.
Un estndar(STD 11) para el formato de los mensajes de correo, contenido en dos RFCs.
El RFC 822 describe la sintaxis de las cabeceras y su interpretacin. El RFC 1049 describe
como un conjunto de documentos de tipos diferentes del texto ASCII plano se pueden usar
en el cuerpo del correo(los mismos documentos estn en ASCII de 7 bits con informacin
Ing. Jorge Colombo
Pag: 14
de formato embebida: Postscript, Scribe, SGML, TEX, TROFF y DVI aparecen en el
estndar).
El nombre oficial del protocolo para este estndar es MAIL.

Un estndar para el encaminamiento de correo usando el DNS, descrito en el RFC 974. El
nombre oficial del protocolo para este estndar es DNS-MX.
El STD 10/RFC 821 establece que los datos enviados por SMTP son ASCII de 7-bis, con el bit de
orden superior a cero. Esto es adecuado para mensajes en ingls, pero no para otros lenguajes o
datos que no sean texto. Hay dos estrategias para superar estas limitaciones:
MIME ("Multipurpose Internet Mail Extensions"), definido en los RFCs 1521 y 1522, que
especifica un mecanismo para codificar texto y datos binarios en ASCII de 7 bits en el
mensaje RFC 822
SMTPSE ("SMTP Service Extensions"), que define un mecanismo para extender las
posibilidades de SMTP ms all de las limitaciones impuestas por RFC 821.
Cmo funciona SMTP

SMTP est basado en la entrega punto-a-punto; un cliente SMTP contactar con el servidor SMTP
del host de destino directamente para entregar el correo. Guardar el correo hasta que se haya
copiado con xito en el receptor. Esto difiere del principio de retransmisin comn a muchos
sistemas de correo en las que el correo atraviesa un nmero de host intermedios de la misma red y
donde una transmisin con xito implica slo que el correo ha alcanzado el host correspondiente al
siguiente salto.
En varias implementaciones, existe la posibilidad de intercambiar correo entre los sistemas de
correo locales y SMTP. Estas aplicaciones se denominan pasarelas o puentes de correo. Enviar
correo a travs de una pasarela puede alterar la entrega punto-a-punto, ya que SMTP slo
garantiza la entrega fiable a la pasarela, no al host de destino, ms all de la red local. La
transmisin punto SMTP en estos casos es host-pasarela, pasarela-host o pasarela-pasarela;
SMTP no define lo que ocurre ms all de la pasarela. CSNET proporciona un interesante ejemplo
de servicio de pasarela de correo. Diseada en principio como un servicio barato para interconectar
centros cientficos y de investigacin, CSNET opera una pasarela que permite a sus suscriptores
enviar y recibir correo en Internet con slo un mdem con dial. La pasarela sondea a los
suscriptores a intervalos regulares, les entrega su correo y recoge el correo de salida. A pesar de
no ser una entrega punto-a-punto, ha demostrado ser un sistema muy til.
Cada mensaje tiene:
Una cabecera, o sobre, con estructura RFC 822. La cabecera termina con
una lnea nula(una lnea con slo la secuencia <CRLF>).

Contents
Todo lo que hay tras la lnea nula es el cuerpo del mensaje, una secuencia de
lneas con caracteres ASCII(aquellos con valor menor del 128 decimal).
Intercambio de correo
El diseo de SMTP se basa en el modelo de comunicacin mostrado en la siguiente figura. Como
resultado de la solicitud de correo de un usuario, el emisor SMTP establece una conexin en los
dos sentidos con el receptor SMTP. El receptor puede ser el destinatario final o un
intermediario(pasarela de correo). El emisor generar comandos a los que replicar el receptor.
Ing. Jorge Colombo
Pag: 15
Figura: Modelo para SMTP
Flujo de transaccin de correo de SMTP:

Aunque los comandos y rplicas de correo estn definidas rgidamente, el intercambio se puede
seguir en la figura - Flujo de datos normal de SMTP
Todos los comandos, rplicas o datos intercambiados son lneas de texto, delimitadas por un
<CRLF>. Todas las rplicas tienen un cdigo numrico el comienzo de la lnea.
1. El emisor SMTP establece una conexin TCP con el SMTP de destino y espera a que el
servidor enve un mensaje "220 Service ready" o "421 Service not available" cuando el
destinatario es temporalmente incapaz de responder.
2. Se enva un HELO (abreviatura de "hello"), con el que el receptor se identificar
devolviendo su nombre de dominio. El SMTP emisor puede usarlo para verificar si contact
con el SMTP de destino correcto.
Si el emisor SMTP soporta las extensiones de SMTP definidas en el RFC 1651, puede
sustituir el comando HELO por EHLO. Un receptor SMTP que no soporte las extensiones
responder con un mensaje "500 Syntax error, command unrecognized". El emisor SMTP
debera intentarlo de nuevo con HELO, o si no puede retransmitir el mensaje sin
extensiones, enviar un mensaje QUIT.
Si un receptor SMTP soporta las extensiones de servicio, responde con un mensaje multilnea 250 OK que incluye una lista de las extensiones de servicio que soporta.
3. El emisor inicia ahora una transaccin enviando el comando MAIL al servidor. Este
comando contiene la ruta de vuelta al emisor que se puede emplear para informar de
errores. Ntese que una ruta puede ser ms que el par buzb@nombre de dominio del
host. Adems, puede contener una lista de los hosts de encaminamiento. Si se acepta, el
receptor replica con un "250 OK".
4. El segundo paso del intercambio real de correo consiste en darle al servidor SMTP el
destino del mensaje(puede haber ms de un receptor). Esto se hace enviando uno o ms
comandos RCPT TO:<forward-path>. Cada uno de ellos recibir una respuesta "250 OK" si
el servidor conoce el destino, o un "550 No such user here" si no.
5. Cuando se envan todos los comandos rcpt, el emisor enva un comando DATA para
notificar al receptor que a continuacin se envan los contenidos del mensaje. El servidor
replica con "354 Start mail input, end with <CRLF>.<CRLF>". Ntese que se trata de la
secuencia de terminacin que el emisor debera usar para terminar los datos del mensaje.
6. El cliente enva los datos lnea a lnea, acabando con la lnea <CRLF>. <CRLF> que el
servidor reconoce con "250 OK" o el mensaje de error apropiado si cualquier cosa fue mal.
7. Ahora hay varias acciones posibles:
o
o
El emisor no tiene ms mensajes que enviar; cerrar la conexin con un comando

QUIT, que ser respondido con "221 Service closing transmission channel".
El emisor no tiene ms mensajes que enviar, pero est preparado para recibir
mensajes(si los hay) del otro extremo. Mandar el comando TURN. Los dos
SMTPs intercambian sus papelees y el emisor que era antes receptor puede enviar
ahora mensajes empezando por el paso 3 de arriba.
Ing. Jorge Colombo
Pag: 16
o
El emisor tiene otro mensaje que enviar, y simplemente vuelve al paso 3 para
enviar un nuevo MAIL.
Figura: Flujo de datos normal de SMTP - Se entrega un correo al buzn de destino.
Servidores de correo POP("Post Office Protocol")

Debido a que un receptor de correo SMTP es un servidor, y SMTP es una aplicacin punto-a-punto
ms que de retransmisin, es necesario que el servidor est disponible cuando un cliente desea
enviarle correo. Si el servidor SMTP reside en una estacin de trabajo o en un PC, ese host debe
estar ejecutando el cuando el cliente quiera transmitir. Esto no suele ser un problema en sistemas
multiusuario porque estn disponibles la mayor parte del tiempo. En sistemas monousuario, sin
embargo, este no es el caso, y se requiere un mtodo para asegurar que el usuario tiene un buzn
disponible en otro servidor. Hay varias razones por las que es deseable descargar a la estacin de
trabajo de las funciones del servidor de correo, entre ellas la falta de recursos en estaciones de
trabajo pequeas, la falta o encarecimiento de la conectividad TCP, etc.
La estrategia ms simple es, por supuesto, usar un sistema multiusuario para las funciones de
correo, pero esto no suele ser deseable -- quiz el usuario no lo va a usar para nada ms, o quiere
tener acceso a Alternativamente, el usuario final puede ejecutar un cliente que comunique con un
programa servidor en un host. Este servidor acta tanto como emisor como receptor. Recibe y
enva el correo del usuario.
Un mtodo intermedio es descargar la funcin de servidor SMTP de la estacin de trabajo del
usuario final, pero no la funcin de cliente. Es decir, el usuario enva correo directamente desde la
estacin, pero tiene un buzn en un servidor. El usuario debe conectar con el servidor para recoger
su correo.
El POP describe cmo un programa que se ejecuta en una estacin de trabajo final puede recibir
correo almacenado en sistema servidor de correo. POP usa el trmino "maildrop" para referirse a
un buzn gestionado por un servidor POP. POP 3 es un borrador y su status es elective. Las
versin es un protocolo histrico con status no recomendado
Ing. Jorge Colombo
Pag: 17
MIME (Multipurpose Internet Mail Extensions)
Fi
gura: MIME("Multipurpose Internet Mail Extensions")
Acrnimo de Multipurpose Internet Mail Extensions, es una especificacin para dar formato a
mensajes no-ASCII, para que puedan ser enviados por Internet.
Muchos clientes de correo soportan MIME, el cual les permite enviar y recibir archivos de
imgenes, de audio y de video a travs del sistema de correo de Internet. Adems, MIME, soporta
mensajes en juegos de caracteres diferentes al ASCII.
Hay muchos tipos MIME predefinidos, como GIFs, JPEGs, MOVs y archivos PostScript. tambin es
posible definir tipos MIME propios.
Adems de las aplicaciones e-mail, los navegadores (browsers) tambin soportan varios tipos
MIME. Esto habilita al navegador a desplegar o interpretar archivos que no estn en formato
HTML.
MIME fue definido en 1992 por el Internet Engineering Task Force (IETF). Hay una versin nueva
llamada S/MIME, la cual soporta mensajes encriptados
MIME es un estndar que incluye mecanismos para resolver estos problemas en una forma con un
alto grado de compatibilidad con los estndares RFC 822. Debido a que los mensajes de correo
suelen enviarse a travs de pasarelas de correo, a un cliente SMTP no le es posible distinguir entre
un servidor que gestiona el buzn del receptor y uno que acta como pasarela a otra red. Como el
correo que atraviesa una pasarela se puede dirigir a otras pasarela, que pueden usar distintos
protocolos de mensajera, en el caso general al emisor no le es posible determinar el mnimo
comn denominador de las capacidades de cada una de las etapas que atraviesa el mensaje. Por
este motivo, MIME asume el peor caso: transporte ASCII de 7 bits que puede no seguir
estrictamente el RFC 821. No define ninguna extensin al RFC 821, sino que se limita slo a las
extensiones incluidas en el RFC 822. De esta forma, un mensaje MIME puede ser enrutado a
travs de cualquier nmero de redes capaces de transmitir mensajes RFC 821. Se describe en dos
partes:
Protocolos para incluir objetos distintos de los mensajes de correo US ASCII. dentro de
mensajes RFC 822. El RFC 1521 los describe.
Un protocolo para codificar texto no US ASCII en los campos de cabecera segn el RFC
822. El RFC 1522 lo describe.
**** NOTA: **** MIME no requiere que los objetos de correo estn codificados -- la decisin se deja
al usuario y/o programa de correo. Para datos binarios, transmitidos a travs de SMTP de 7 bits, la
codificacin es necesaria invariablemente, pero para datos que son texto en su mayora, puede
que no haga falta. El mecanismo preferido de codificacin para datos "de texto en su mayora" es
tal que, como mnimo, es , es fiable para cualquier agente SMTP en un sistema ASCII, y como
Ing. Jorge Colombo
Pag: 18
mximo, es fiable con todas las pasarelas y MTAs conocidos. La razn por la que MIME no
requiere codificacin total es que la codificacin dificulta la legibilidad cuando MIME el correo se
transmite a sistemas no MIME
El protocolo TFTP
Propsito
TFTP es un protocolo para transferir archivos entre distintas mquinas conectadas a travs de una
red de comunicaciones. Se implementa sobre un servicio de comunicaciones no fiable y no
orientado a conexin. Consiste fundamentalmente en la lectura o escritura por parte de un cliente
de/a un archivo de un servidor.
Caractersticas fundamentales
Cualquier transferencia de archivos comienza con una solicitud de lectura o escritura de un archivo
por parte de un cliente. Si el servidor acepta dicha solicitud el archivo se transmite dividido en
trozos de un tamao fijo de 512 bytes. Cada paquete de datos contiene uno de esos trozos. Los
paquetes de datos deben ser asentidos, de forma que en ausencia de fallos de las mquinas, el
archivo acabe siendo transferido correctamente. Para ello se podr utilizar indistintamente un
protocolo de parada y espera o uno de envo contnuo. En cualquiera de los casos se utilizarn
paquetes de asentimiento. Un paquete de datos de menos de 512 bytes indica el fin de la
transferencia. Cada paquete de datos lleva consigo un nmero de trozo, comenzando la
transferencia por el trozo 1. Cada paquete de asentimiento lleva consigo un nmero de trozo. En el
caso de utilizar un protocolo de envo contnuo el nmero de trozo indicar el ltimo paquete que
se asiente (los anteriores a ste quedan asentidos implcitamente) y en caso de utilizar un
protocolo de parada y espera, el nmero de trozo identifica al paquete concreto que se est
asintiendo.
Si un paquete se pierde en la comunicacin, a su destinatario le vencer un plazo y deber
retransmitir el ltimo paquete transmitido (de datos o de asentimiento), lo que causar que el
emisor del paquete perdido retransmita dicho paquete. Ntese que utilizan los plazos tanto el
cliente como el servidor.
Tres tipos de situaciones causan un error:
cuando no es posible aceptar una solicitud de transferencia (archivo inexistente, violacin
de permisos)
cuando se recibe un paquete con formato incorrecto
cuando se pierde el acceso a un recurso (se llena el disco) en mitad de la transferencia
Los errores causarn la terminacin de la transferencia. Un error se indicar enviando un paquete
de error. Este paquete ni se asiente ni se retransmite, as que el otro extremo de la comunicacin
puede no recibirlo nunca.
Inicio de la transferencia
Una transferencia se inicia con el envo por parte de un cliente de una solicitud (WRQ para solicitar
una escritura o RRQ para solicitar una lectura) y la recepcin en dicho cliente de una respuesta
afirmativa por parte del servidor. Dicha respuesta afirmativa ser un paquete de asentimiento --para
las escrituras-- o el primer paquete de datos --para las lecturas--. El paquete de asentimiento para
las escrituras lleva nmero de trozo 0, como caso especial, y ha de ser enviado siempre, tanto si se
utiliza envo contnuo como si se utiliza parada y espera. Si la respuesta a la solicitud es un
paquete de error, la solicitud ha sido denegada.
Tipos de paquetes
TFTP utiliza cinco tipos de paquetes:
Ing. Jorge Colombo
Pag: 19
Tipo acrnimo operacin
1
RRQ
Solicitud de lectura
WRQ
Solicitud de escritura
DATA
Paquete de datos
ACK
Paquete de asentimiento
ERR
Paquete de error
Paquetes RRQ y WRQ

Tipo Nombre de archivo
Tipo:
Para RRQ un 1, para WRQ un 2
Nombre de archivo:
String de longitud arbitraria
Paquetes DATA
Tipo Nmero de trozo Datos
Tipo:
3
Nmero de trozo:
Un 1 para el primer trozo, y se incrementa progresivamente hasta llegar a 65535, para
volver a empezar
Datos:
De 0 a 512 bytes con un trozo del archivo que se lee o escribe. Si tiene justo 512 bytes,
NO es el ltimo paquete de datos. Si tiene de 0 a 512 bytes, indica el final de la
transferencia.
Paquetes ACK
Tipo Nmero de trozo
Tipo:
4
Nmero de trozo:
Indica el nmero del trozo que se asiente (en caso de utilizar envo contnuo indica el
ltimo nmero de trozo que se asiente, e implicitamente el asentimiento de los anteriores).
Si es cero, es un asentimiento a una solicitud de escritura.
Todos los paquetes que no son de ERR deben ser asentidos. Enviar un paquete de datos es un
asentimiento del ACK del trozo anterior.
As, Los paquetes WRQ o DATA se asienten con paquetes ACK o ERR, mientras que los paquetes
RRQ o ACK se asienten con paquetes DATA o ERR.
Paquetes ERR
Tipo Cdigo de error Mensaje
Tipo:
5
Cdigo de error:
Ing. Jorge Colombo
Pag: 20
Indica la naturaleza del error. Valores:
Valor Significado
0
No definido
Archivo no encontrado
Violacin de permisos
Disco lleno
4
Operacin ilegal de TFTP
Mensaje:
String de longitud indeterminada para ampliar informacin sobre el error, si es
necesario.
Terminacin normal
El final de una transferencia se indica con un paquete DATA de 0 a 511 bytes. Este paquete debe
ser asentido con un ACK (como todos los DATA).
La mquina que asiente el ltimo paquete DATA puede cerrar su lado de la comunicacin despus
de enviar el ACK, pero normalmente espera un rato para retransmitir el ltimo ACK si se perdiera,
circunstancia que detectar si recibe el ltimo paquete DATA otra vez.
La mquina que enva el ltimo paquete DATA debe esperar hasta recibir el ACK o desistir despus
de un determinado plazo de tiempo. Si desiste, terminar su lado de la comunicacin sin saber si
se complet o no la transferencia (depende de si se perdi el ltimo ACK o el ltimo DATA,
respectivamente).
Terminacin prematura
Si una solicitud no puede ser aceptada, o si se produce un error en mitad de una transferencia, se
enva un paquete de error y se termina la comunicacin. Este paquete no ser asentido ni
retransmitido, por lo que podra suceder que nunca llegara a su destino.
Extensiones a TFTP
Mediante un mecanismo de negociacin de opciones, pueden hacerse extensiones al protocolo
TFTP manteniendo compatibilidad hacia atrs. La idea es permitir la negociacin entre cliente y
servidor de ciertas opciones de la transferencia de datos.
Negociacin de opciones
El mecanismo de negociacin de opciones es de propsito general, de forma que pueden
negociarse con l distintos tipos de opciones.
Las opciones se aaden a los paquetes de solicitud RRQ y WRQ. Adems se crea un nuevo tipo
de paquete, paquete OACK, para asentir una solicitud con negociacin de opciones. Se crea as
mismo un nuevo cdigo de error, el 8, para indicar que la transferencia debe abortarse debido a la
negociacin de opciones.
Las opciones se aaden a los RRQ o WRQ de la siguiente forma:
Tipo Nombre de archivo Nmero de opciones opcin_1 valor_1 ... opcin_n valor_n
Tipo:
Para RRQ un 1, para WRQ un 2
Nmero de opciones:
Indica el nmero de parejas (opcin,valor) que vienen a continuacin.
opcin_i:
La opcin i-sima. Es un string de tamao indeterminado.
valor_i:
Ing. Jorge Colombo
Pag: 21
El valor asociado a la opcin_i. Es un string de tamao indeterminado.
El cliente aade opciones al final de su solicitud. Puede especificarse cualquier nmero de
opciones, aunque cada opcin slo puede especificarse una vez. El orden en que se especifican
las opciones no es significativo. Un paquete de solicitud nunca puede tener ms de 512 bytes.
El paquete de OACK tiene el siguiente formato:

Tipo Nmero de opciones opcin_1 valor_1 ... opcin_n valor_n
Tipo:
6
Nmero de opciones:
Indica el nmero de parejas (opcin,valor) que siguen. La presencia de una de estas
parejas indica que se asiente dicha opcin.
opcin_i:
La opcin i-sima. Es un string de tamao indeterminado, copiado del paquete de solicitud.
valor_i:
El valor numrico asociado a la opcin_i. Depender de la opcin concreta de que se trate
el hecho de que este valor pueda o no diferir del que se present en el paquete de
solicitud.
Si el servidor soporta la negociacin de opciones, y reconoce una o ms de las opciones presentes
en un paquete de solicitud recibido, responde con un paquete de OACK. Cada opcin que
reconozca y el valor aceptado para dicha opcin, son incluidos en el paquete de OACK. El servidor
no puede incluir en el OACK ninguna opcin que no le fuera presentada en la solicitud. Las
opciones que no acepte el servidor son omitidas del OACK, sin que se genere un paquete de error.
Si el valor especificado para una opcin es invlido, el servidor tiene la opcin de omitir dicha
opcin del OACK, de incluirla en el OACK con un valor vlido, o de enviar un paquete ERR con
cdigo de error 8 para abortar la transferencia.
Una opcin solicitada por un cliente y no asentida por un servidor debe ser ignorada por el cliente,
como si nunca la hubiera presentado. Si un cliente recibe en el OACK una opcin que no solicit,
debe enviar un paquete ERR con cdigo de error 8 y terminar la transferencia.
Cuando el cliente aade opciones a una solicitud RRQ, pueden darse tres posibles respuestas del
servidor:
OACK: asentimiento del RRQ y de una o ms de las opciones. En este caso el cliente debe
asentir el OACK con un ACK con nmero de trozo 0.
DATA: asentimiento del RRQ pero no de ninguna de las opciones
ERR: solicitud denegada.
Cuando el cliente aade opciones a una solicitud WRQ, pueden darse tres posibles respuestas del
servidor:
OACK: asentimiento del WRQ y de una o ms de las opciones. Este OACK es asentido
directamente con el primer paquete DATA por el cliente.
ACK: asentimiento del WRQ pero no de ninguna de las opciones
ERR: solicitud denegada.
Este mecanismo permite que un cliente que presente opciones pueda ser atendido por un servidor
que no tenga implementada la negociacin de opciones.
Opcin de tamao de parte
El protocolo TFTP establece el tamao de cada parte de archivo transferido en un paquete DATA
como de 512 bytes. Sin embargo, con el mecanismo de negociacin de opciones descrito, el
cliente puede proponer otro valor.
En este caso, el cliente aadir a su solicitud de WRQ o de RRQ una opcin de nombre "blksize", y
de valor el nmero de bytes propuesto como tamao de trozo, entre 8 y 4096.
Ing. Jorge Colombo
Pag: 22
Si el servidor acepta dicha opcin, enviar un OACK incluyndola, y con un valor igual o menor al
propuesto. El cliente entonces dar por bueno dicho valor, o abortar la transferencia enviando un
paquete ERR con cdigo de error 8.
Las reglas para terminar la transferencia normalmente son las mismas que en el caso de tamao
512 bytes: el paquete DATA con menos bytes de los negociados como tamao de trozo se
considera el ltimo.
Opcin de plazo de espera
El protocolo TFTP no establece el plazo que cada mquina debe esperar para recibir el
asentimiento de un paquete. Sin embargo, con el mecanismo de negociacin de opciones descrito,
el cliente puede proponer un valor a emplear durante la subsiguiente transferencia.
En este caso, el cliente aadir a su solicitud de WRQ o de RRQ una opcin de nombre "timeout",
y de valor el nmero de milisegundos propuesto como plazo de espera, entre 100 y 255000.
Si el servidor acepta dicha opcin, enviar un OACK incluyndola, y con un valor igual al
propuesto.
FTP, File Transfer Protocol
FTP (File Transfer Protocol) surgi de la necesidad de intercambiar archivos entre anfitriones,
especialmente de plataformas dismiles. Debemos recordar que en Unix, la plataforma de hardware
no es homognea como en el mundo de la PC, el rango de hardware va desde una PC 386
corriendo LINUX o una Macintosh corriendo A/UX, pasando por estaciones de trabajo RISC como
las Sun, Silicon Graphics, Hewlett-Packard; hasta mainframes Digital o Hewlett-Packard; o
supercomputadoras Cray, por nombrar algunos. Por lo tanto una forma de transferencia de
archivos independiente de la plataforma fue necesaria desde los comienzos de TCP/IP. FTP fue
diseado con ese objetivo y es tan flexible que hasta nos permite traer archivos de mainframes o
minicomputadoras IBM codificadas en EBCDIC (dichos anfitriones IBM utilizan esta codificacin en
lugar de ASCII).
FTP presenta, como Telnet, una interface de comandos que permite controlar la conexin u
desconexin del anfitrin remoto, la autentificacin de entrada, y la transferencia en s. FTP puede
ser invocado, al igual que telnet como ftp anfitrin o simplemente ftp, esta ltima variante nos deja
en la interface de comandos. Para efectuar un FTP a un anfitrin remoto, es necesario tener una
cuenta en l. Lo primero que nos pide al ingresar al otro equipo es nuestro nombre de usuario y
clave. Existe una excepcin a ello y es el denominado "FTP annimo". En los sitios donde se
permite este tipo de conexin se ingresa como usuario "anonymous" y como clave nuestra
direccin de email. En realidad, la clave puede ser cualquier cosa pero, como una de las tantas
reglas no escritas de cortesa en Internet, nos obliga a identificarnos de esa manera.
Entre los comandos mas usuales de FTP tenemos: open, abre una conexin al anfitrin; close, la
cierra; user, enva el nombre de nuestro usuario; passwd, enva nuestra clave; cd, cambia el
Ing. Jorge Colombo
Pag: 23
directorio remoto; lcd, (local cd) cambia el directorio local; dir, lista el contenido del directorio
remoto; get, trae un archivo remoto a nuestro disco; mget, trae mltiples archivos; put y mput,
tienen el efecto inverso; ascii, pone al FTP en modo de transferencia ASCII y binary, en modo
binario. Estos ltimos comandos merecen una explicacin mas profunda.
Los distintos sistemas operativos suelen guardar los archivos de texto en forma dismil. Por
ejemplo, el ms-dos agrega en cada final de lnea dos caracteres de control: un retorno de carro
(CR, carriage return) y un avance de lnea (LF, line feed). Unix, por otra parte, solo coloca un
avance de lnea. Al poner al FTP en modo ASCII, este agrega en cada final de lnea los caracteres
que necesite. En modo binario, el archivo se trasmite tal cual es y se utiliza para pasar programas
ejecutables, planillas de clculo, archivos multimediales, etc.; es decir todo archivo que no sea de
texto puro.
Modelo de Proceso FTP

Un proceso cliente FTP (probablemente uno deseoso de transferir un archivo) establece una
conexin de control a un servidor de FTP, esperando (escuchando) en el puerto estndar FTP 21.
Esta conexin lleva todos los comandos de FTP y las contestaciones.
Cuando un archivo sea transferido, el proceso del cliente abrir una nueva conexin al servidor al
puerto 20, el puerto de transferencia de datos de FTP. Esta conexin de datos se usa para llevar
los datos actuales al archivo. En sistemas como Unix, esto se logra normalmente "horquillando" un
proceso "nio" a cada extremo de la conexin, as:
Un aspecto interesante de FTP es que la conexin de comando se lleva a cabo usando un

subconjunto del protocolo de TELNET, usando el TELNET NVT.
FTP en Funcionamiento
Ing. Jorge Colombo
Pag: 24
Un servidor FTP normalmente les exige a los clientes que se autentiquen proporcionando un
username vlidos y contrasea antes de permitirles realizar transferencia de archivo. Los usuarios
ordinarios encuentran as en FTP una manera conveniente de transferir archivos entre sistemas.
Muchos sistemas proporcionan un servicio FTP especial por lo cual el username

"anonymous" permite acceso a una rea de archivos pblica.
NFS("Network File System")
Figure: NFS("Network File System")

El protocolo NFS("Network File System") de permite compartir sistemas de archivos en una red. El
protocolo NFS est diseado para ser independiente de la mquina, el sistema operativo y el
protocolo de transporte. Esto es posible porque se implementa sobre RPC ("Remote Procedure
Call"). RPC establece la independencia de la mquina usando XDR("External Data
Representation").
SUN-NFS es un protocolo propuesto como estndar. Su status es electivo. La especificacin actual
del NFS de Sun se puede encontrar en el RFC 1094 - especificacin de NFS:. Este RFC
documenta la versin 2 de NFS. Aunque el RFC menciona a la versin 3 de NFS, nadie ha enviado
an un nuevo RFC ni un borrador discutiendo una posible especificacin de la versin 3.
Concepto
NFS permite a los usuarios autorizado acceder a archivos localizados en sistemas remotos como si
fueran locales. Dos protocolos sirven a este propsito:
1. El protocolo de montaje Mount para especificar el host remoto y el sistema de

archivos al que se va a acceder as como dnde localizarlo en la jerarqua local de
archivos.
2. El protocolo NFS para efectuar la autntica E/S de archivos sobre el sistema remoto
de archivos.
Tanto el protocolo Mount como el NFS son aplicaciones de RPC(concepto de llamador/servidor) y
son transportados por UDP.
Ing. Jorge Colombo
Pag: 25
Protocolo
El protocolo Mount es una aplicacin de RPC integrada con NFS. Su nmero de programa es el
100005. El protocolo Mount es transportado por UDP. Mount es un servidor RPC y proporciona un
total de seis procedimientos:
NULL
No hace nada, es til para testear las respuestas del servidor
MOUNT
Funcin Mount, devuelve un descriptor de archivo apuntando al directorio
DUMP
Devuelve la lista de todos los sistemas de archivos montados
UMOUNT
Elimina una entrada de la lista de sistemas de archivos montados
UNMTALL
Elimina todas de las entradas de la lista de sistemas de archivos montados para el
cliente
EXPORT
Devuelve informacin sobre los sistemas de archivos disponibles

La llamada a MOUNT devuelve un descriptor de archivo que apunta al directorio. Este descriptor es
un campo de 32 bytes, que el cliente usar posteriormente para acceder a los archivos. Los
descriptores son una parte fundamental de NFS ya que a travs de ellos se referenciar cada
archivo y directorio. Algunas implementaciones encriptan los descriptores por razones de
seguridad(por ejemplo, el NFS de VM puede usar opcionalmente programas de encriptacin para
esto).
El comando MOUNT aporta la interfaz a esta aplicacin de RPC. El usuario ejecuta el comando
MOUNT para localizar el sistema de archivos remoto en su propia jerarqua de archivos.
Protocolo NFS
NFS es la aplicacin de RPC que suministra funciones de E/S sobre archivos en un host remoto,
una vez que ha sido solicitado mediante el comando MOUNT. Tiene el nmero de programa
100003 y a veces usa el puerto IP 2049. Como este no es un nmero de puerto asignado
oficialmente, y ya existen diversas versiones de NFS(y de MOUNT) lo nmeros de puerto pueden
cambiar. Es aconsejable dirigirse al Portmap(nmero de puerto 111) para obtener los nmeros de
puerto para MOUNT y NFS. El protocolo NFS es transportado por UDP.
Sistema de archivos NFS

NFS asume un sistema de archivos jerrquico(directorios). Los archivos son secuencias de bytes
sin estructura y carentes de significado inherente: es decir, todos lo archivos se ven como una
secuencia contigua de bytes, sin ninguna estructura de registros.
Con NFS, todas las operaciones sobre archivos son sncronas. Esto significa que la operacin slo
retorna cuando el servidor ha completado todo el trabajo asociado para esa operacin. En caso de
una solicitud de escritura, el servidor escribir fsicamente los datos en el disco, y si es necesario,
actualizar a estructura de directorios, antes de devolver una respuesta al cliente. Esto garantiza la
integridad de los archivos.
NFS tambin especifica que los servidores no deberan estar asociados a un cliente determinado.
Es decir, un servidor no necesita mantener informacin extra de ninguno de sus clientes para
funcionar correctamente. En caso de un fallo del servidor, los clientes slo tienen que reintentar la
solicitud hasta que el servidor responda, sin tener que repetir la operacin de mount
Ing. Jorge Colombo
Pag: 26
El protocolo HTTP
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo
cliente-servidor que articula los intercambios de informacin entre los clientes Web y los servidores
HTTP. La especificacin completa del protocolo HTTP 1/0 est recogida en el RFC 1945. Fue
propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribucin
de informacin como el World Wide Web.
Desde el punto de vista de las comunicaciones, est soportado sobre los servicios de conexin
TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX:
un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera
las solicitudes de conexin de los clientes Web. Una vez que se establece la conexin, el protocolo
TCP se encarga de mantener la comunicacin y garantizar un intercambio de datos libre de
errores.
HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexin
con un servidor y enva un mensaje con los datos de la solicitud. El servidor responde con un
mensaje similar, que contiene el estado de la operacin y su posible resultado. Todas las
operaciones pueden adjuntar un objeto o recurso sobre el que actan; cada objeto Web
(documento HTML, archivo multimedia o aplicacin CGI) es conocido por su URL.
NOTA
Los recursos u objetos que actan como entrada o salida de un comando HTTP estn clasificados
por su descripcin MIME. De esta forma, el protocolo puede intercambiar cualquier tipo de dato, sin
preocuparse de su contenido. La transferencia se realiza en modo binario, byte a byte, y la
identificacin MIME permitir que el receptor trate adecuadamente los datos.
Las principales caractersticas del protocolo HTTP son:
Toda la comunicacin entre los clientes y servidores se realiza a partir de caracteres de 8 bits. De esta
forma, se puede transmitir cualquier tipo de documento: texto, binario, etc., respetando su formato
original.
Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado est
identificado por su clasificacin MIME.
Existen tres verbos bsicos (hay ms, pero por lo general no se utilizan) que un cliente puede utilizar
para dialogar con el servidor: GET, para recoger un objeto, POST, para enviar informacin al
servidor y HEAD, para solicitar las caractersticas de un objeto (por ejemplo, la fecha de
modificacin de un documento HTML).
Cada operacin HTTP implica una conexin con el servidor, que es liberada al trmino de la misma.
Es decir, en una operacin se puede recoger un nico objeto.
No mantiene estado. Cada peticin de un cliente a un servidor no es influida por las transacciones
anteriores. El servidor trata cada peticin como una operacin totalmente independiente del resto.
Cada objeto al que se aplican los verbos del protocolo est identificado a travs de la informacin de
situacin del final de la URL.
NOTA
HTTP se dise especficamente para el World Wide Web: es un protocolo rpido y
sencillo que permite la transferencia de mltiples tipos de informacin de forma eficiente y
rpida. Se puede comparar, por ejemplo, con FTP, que es tambin un protocolo de
transferencia de archivos, pero tiene un conjunto muy amplio de comandos, y no se integra
demasiado bien en las transferencias multimedia.
Etapas de una transaccin HTTP

Para profundizar ms en el funcionamiento de HTTP, veremos primero un caso particular de una
transaccin HTTP; en los siguientes apartados se analizarn las diferentes partes de este proceso.
Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los siguientes pasos:
1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o
introducindola directamente en el campo Location del cliente Web.
Ing. Jorge Colombo
Pag: 27
2. El cliente Web descodifica la URL, separando sus diferentes partes. As identifica el
protocolo de acceso, la direccin DNS o IP del servidor, el posible puerto opcional (el valor
por defecto es 80) y el objeto requerido del servidor.
3. Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP correspondiente.
4. Se realiza la peticin. Para ello, se enva el comando necesario (GET, POST, HEAD,), la
direccin del objeto requerido (el contenido de la URL que sigue a la direccin del
servidor), la versin del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto
variable de informacin, que incluye datos sobre las capacidades del browser, datos
opcionales para el servidor,
5. El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el tipo de
dato MIME de la informacin de retorno, seguido de la propia informacin.
6. Se cierra la conexin TCP.
Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un documento
HTML en cuyo interior estn insertadas cuatro imgenes, el proceso anterior se repite cinco veces,
una para el documento HTML y cuatro para las imgenes.
NOTA
En la actualidad se ha mejorado este procedimiento, permitiendo que una misma conexin se
mantenga activa durante un cierto periodo de tiempo, de forma que sea utilizada en sucesivas
transacciones. Este mecanismo, denominado HTTP Keep Alive, es empleado por la mayora de los
clientes y servidores modernos. Esta mejora es imprescindible en una Internet saturada, en la que
el establecimiento de cada nueva conexin es un proceso lento y costoso
Estructura de los mensajes HTTP

El dilogo con los servidores HTTP se establece a travs de mensajes formados por lneas de
texto, cada una de las cuales contiene los diferentes comandos y opciones del protocolo. Slo
existen dos tipos de mensajes, uno para realizar peticiones y otro para devolver la correspondiente
respuesta. La estructura general de los dos tipos de mensajes se puede ver en el siguiente
esquema:
Mensaje de solicitud
Mensaje de respuesta
Comando HTTP + parmetros
Resultado de la solicitud
Cabeceras del
requerimiento
Cabeceras de la respuesta
(lnea en blanco)
(lnea en blanco)
Informacin opcional
Informacin opcional
La primera lnea del mensaje de solicitud contiene el comando que se solicita al servidor HTTP,
mientras que en la respuesta contiene el resultado de la operacin, un cdigo numrico que
permite conocer el xito o fracaso de la operacin. Despus aparece, para ambos tipos de
mensajes, un conjunto de cabeceras (unas obligatorias y otras opcionales), que condicionan y
matizan el funcionamiento del protocolo.
La separacin entre cada lnea del mensaje se realiza con un par CR-LF (retorno de carro ms
nueva lnea). El final de las cabeceras se indica con una lnea en blanco, tras la cual se pueden
incluir los datos transportados por el protocolo, por ejemplo, el documento HTML que devuelve un
servidor o el contenido de un formulario que enva un cliente .
Los siguientes apartados describen con ms detalle el contenido de cada una de las secciones de
los mensajes. El conocimiento y empleo de los mensajes HTTP es necesario en las siguientes
situaciones:
Para disear mdulos CGI, ya que es preciso construir una respuesta similar a la que el
servidor HTTP proporciona al cliente.
Ing. Jorge Colombo
Pag: 28
Para disear aplicaciones independientes que soliciten informacin a un servidor (automatizar la
recuperacin de documentos o construir robots de bsqueda) se debe construir una cabecera
HTTP con la informacin de la peticin al servidor
Comandos del protocolo

Los comandos o verbos de HTTP representan las diferentes operaciones que se pueden solicitar a
un servidor HTTP. El formato general de un comando es:
Nombre del
comando
Objeto sobre el
que se aplica
Versin de HTTP
utilizada
Cada comando acta sobre un objeto del servidor, normalmente un archivo o aplicacin, que se
toma de la URL de activacin. La ltima parte de esta URL, que representa la direccin de un
objeto dentro de un servidor HTTP, es el parmetro sobre el que se aplica el comando. Se
compone de una serie de nombres de directorios y archivos, adems de parmetros opcionales
para las aplicaciones CGI (ver Ejecucin de programas en un servidor HTTP en la pgina *).
El estndar HTTP/1.0 recoge nicamente tres comandos, que representan las operaciones de
recepcin y envo de informacin y chequeo de estado:
GET Se utiliza para recoger cualquier tipo de informacin del servidor. Se utiliza siempre
que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el
servidor HTTP enva el documento correspondiente a la URL seleccionada, o bien activa
un mdulo CGI, que generar a su vez la informacin de retorno.
HEAD Solicita informacin sobre un objeto (archivo): tamao, tipo, fecha de modificacin
Es utilizado por los gestores de cachs de pginas o los servidores proxy, para conocer
cundo es necesario actualizar la copia que se mantiene de un archivo.
POST Sirve para enviar informacin al servidor, por ejemplo los datos contenidos en un
formulario. El servidor pasar esta informacin a un proceso encargado de su tratamiento
(generalmente una aplicacin CGI). La operacin que se realiza con la informacin
proporcionada depende de la URL utilizada. Se utiliza, sobre todo, en los formularios.
Un cliente Web selecciona automticamente los comandos HTTP necesarios para recoger la
informacin requerida por el usuario. As, ante la activacin de un enlace, siempre se ejecuta una
operacin GET para recoger el documento correspondiente. El envo del contenido de un
formulario utiliza GET o POST, en funcin del atributo de <FORM METHOD="...">. Adems, si el
cliente Web tiene un cach de pginas recientemente visitadas, puede utilizar HEAD para
comprobar la ltima fecha de modificacin de un archivo, antes de traer una nueva copia del
mismo.
Posteriormente se han definido algunos comandos adicionales, que slo estn disponibles en
determinadas versiones de servidores HTTP, con motivos eminentemente experimentales. La
ltima versin de HTTP, denominada 1.1, recoge estas y otras novedades, que se pueden utilizar,
por ejemplo, para editar las pginas de un servidor Web trabajando en remoto.
PUT Actualiza informacin sobre un objeto del servidor. Es similar a POST, pero en este
caso, la informacin enviada al servidor debe ser almacenada en la URL que acompaa al
comando. As se puede actualizar el contenido de un documento.
DELETE Elimina el documento especificado del servidor.
LINK Crea una relacin entre documentos.
UNLINK Elimina una relacin existente entre documentos del servidor.
Ing. Jorge Colombo
Pag: 29
Las cabeceras
Son un conjunto de variables que se incluyen en los mensajes HTTP, para modificar su
comportamiento o incluir informacin de inters. En funcin de su nombre, pueden aparecer en los
requerimientos de un cliente, en las respuestas del servidor o en ambos tipos de mensajes. El
formato general de una cabecera es:
Nombre de la variable
Cadena ASCII con su valor
Los nombres de variables se pueden escribir con cualquier combinacin de maysculas y

minsculas. Adems, se debe incluir un espacio en blanco entre el signo : y su valor. En caso de
que el valor de una variable ocupe varias lneas, stas debern comenzar, al menos, con un
espacio en blanco o un tabulador.
Cabeceras comunes para peticiones y respuestas
Content-Type: descripcin MIME de la informacin contenida en este mensaje. Es la

referencia que utilizan las aplicaciones Web para dar el correcto tratamiento a los datos
que reciben.
Content-Length: longitud en bytes de los datos enviados, expresado en base decimal.
Content-Encoding: formato de codificacin de los datos enviados en este mensaje. Sirve,
por ejemplo, para enviar datos comprimidos (x-gzip o x-compress) o encriptados.
Date: fecha local de la operacin. Las fechas deben incluir la zona horaria en que reside el
sistema que genera la operacin. Por ejemplo: Sunday, 12-Dec-96 12:21:22 GMT+01. No
existe un formato nico en las fechas; incluso es posible encontrar casos en los que no se
dispone de la zona horaria correspondiente, con los problemas de sincronizacin que esto
produce. Los formatos de fecha a emplear estn recogidos en los RFC 1036 y 1123.
Pragma: permite incluir informacin variada relacionada con el protocolo HTTP en el
requerimiento o respuesta que se est realizando. Por ejemplo, un cliente enva un
Pragma: no-cache para informar de que desea una copia nueva del recurso especificado.
Cabeceras slo para peticiones del cliente

Accept: campo opcional que contiene una lista de tipos MIME aceptados por el cliente. Se
pueden utilizar * para indicar rangos de tipos de datos; tipo/* indica todos los subtipos de
un determinado medio, mientras que */* representa a cualquier tipo de dato disponible.
Authorization: clave de acceso que enva un cliente para acceder a un recurso de uso
protegido o limitado. La informacin incluye el formato de autorizacin empleado, seguido
de la clave de acceso propiamente dicha. La explicacin se incluye ms adelante.
From: campo opcional que contiene la direccin de correo electrnico del usuario del
cliente Web que realiza el acceso.
If-Modified-Since: permite realizar operaciones GET condicionales, en funcin de si la
fecha de modificacin del objeto requerido es anterior o posterior a la fecha proporcionada.
Puede ser utilizada por los sistemas de almacenamiento temporal de pginas. Es
equivalente a realizar un HEAD seguido de un GET normal.
Referer: contiene la URL del documento desde donde se ha activado este enlace. De esta
forma, un servidor puede informar al creador de ese documento de cambios o
actualizaciones en los enlaces que contiene. No todos los clientes lo envan.
User-agent: cadena que identifica el tipo y versin del cliente que realiza la peticin. Por
ejemplo, los browsers de Netscape envan cadenas del tipo User-Agent: Mozilla/3.0
(WinNT; I)
Cabeceras slo para respuestas del servidor HTTP

Allow: informa de los comandos HTTP opcionales que se pueden aplicar sobre el
objeto al que se refiere esta respuesta. Por ejemplo, Allow: GET, POST.
Ing. Jorge Colombo
Pag: 30
Expires: fecha de expiracin del objeto enviado. Los sistemas de cache deben
descartar las posibles copias del objeto pasada esta fecha. Por ejemplo, Expires:
Thu, 12 Jan 97 00:00:00 GMT+1. No todos los sistemas lo envan. Puede cambiarse
utilizando un <META EXPIRES> en el encabezado de cada documento.
Last-modified: fecha local de modificacin del objeto devuelto. Se puede
corresponder con la fecha de modificacin de un archivo en disco, o, para
informacin generada dinmicamente desde una base de datos, con la fecha de
modificacin del registro de datos correspondiente.
Location: informa sobre la direccin exacta del recurso al que se ha accedido.
Cuando el servidor proporciona un cdigo de respuesta de la serie 3xx, este
parmetro contiene la URL necesaria para accesos posteriores a este recurso.
Server: cadena que identifica el tipo y versin del servidor HTTP. Por ejemplo,
Server: NCSA 1.4.
WWW-Autenticate: cuando se accede a un recurso protegido o de acceso
restringido, el servidor devuelve un cdigo de estado 401, y utiliza este campo para
informar de los modelos de autentificacin vlidos para acceder a este recurso.
Cdigos de estado del servidor

Ante cada transaccin con un servidor HTTP, ste devuelve un cdigo numrico que informa sobre
el resultado de la operacin, como primera lnea del mensaje de respuesta. Estos cdigos
aparecen en algunos casos en la pantalla del cliente, cuando se produce un error. El formato de la
lnea de estado es:
Versin de protocolo
HTTP utilizada
Cdigo numrico de
estado (tres dgitos)
Descripcin del cdigo

numrico
NOTA
Dependiendo del servidor, es posible que se proporcione un mensaje de error ms
elaborado, en forma de documento HTML, en el que se explican las causas del error y su
posible solucin.
Existen cinco categoras de mensajes de estado, organizadas por el primer dgito del cdigo
numrico de la respuesta:
1xx : mensajes informativos. Por ahora (en HTTP/1.0) no se utilizan, y estn reservados
para un futuro uso.
2xx : mensajes asociados con operaciones realizadas correctamente.
3xx : mensajes de redireccin, que informan de operaciones complementarias que se
deben realizar para finalizar la operacin.
4xx : errores del cliente; el requerimiento contiene algn error, o no puede ser realizado.
5xx : errores del servidor, que no ha podido llevar a cabo una solicitud.
Los ms comunes se recogen en la siguiente tabla:
Cdigo Comentario
Descripcin
200
Operacin realizada satisfactoriamente.
Ing. Jorge Colombo
OK
Pag: 31
201
Created
La operacin ha sido realizada correctamente, y

como resultado se ha creado un nuevo objeto,
cuya URL de acceso se proporciona en el
cuerpo de la respuesta. Este nuevo objeto ya
est disponible. Puede ser utilizado en sistemas
de edicin de documentos.
202
Accepted
La operacin ha sido realizada correctamente, y

como resultado se ha creado un nuevo objeto,
cuya URL de acceso se proporciona en el
cuerpo de la respuesta. El nuevo objeto no est
disponible por el momento. En el cuerpo de la
respuesta se debe informar sobre la
disponibilidad de la informacin.
204
No Content
La operacin ha sido aceptada, pero no ha

producido ningn resultado de inters. El cliente
no deber modificar el documento que est
mostrando en este momento.
301
Moved
Permanently
El objeto al que se accede ha sido movido a otro

lugar de forma permanente. El servidor
proporciona, adems, la nueva URL en la
variable Location de la respuesta. Algunos
browsers acceden automticamente a la nueva
URL. En caso de tener capacidad, el cliente
puede actualizar la URL incorrecta, por ejemplo,
en la agenda de bookmarks.
302
Moved
Temporarily
El objeto al que se accede ha sido movido a otro

lugar de forma temporal. El servidor proporciona,
adems, la nueva URL en la variable Location de
la respuesta. Algunos browsers acceden
automticamente a la nueva URL. El cliente no
debe modificar ninguna de las referencias a la
URL errnea.
304
Not Modified
Cuando se hace un GET condicional, y el

documento no ha sido modificado, se devuelve
este cdigo de estado.
400
Bad Request
La peticin tiene un error de sintaxis y no es

entendida por el servidor.
401
Unauthorized La peticin requiere una autorizacin especial,

que normalmente consiste en un nombre y clave
que el servidor verificar. El campo WWW-
Ing. Jorge Colombo
Pag: 32
Autenticate informa de los protocolos de

autentificacin aceptados para este recurso.
403
Forbidden
Est prohibido el acceso a este recurso. No es

posible utilizar una clave para modificar la
proteccin.
404
Not Found
La URL solicitada no existe.
500
Internal
Server Error
El servidor ha tenido un error interno, y no puede

continuar con el procesamiento.
501
Not
Implemented
El servidor no tiene capacidad, por su diseo

interno, para llevar a cabo el requerimiento del
cliente.
502
Bad Gateway El servidor, que est actuando como proxy o

pasarela, ha encontrado un error al acceder al
recurso que haba solicitado el cliente.
503
Service
Unavailable
El servidor est actualmente deshabilitado, y no

es capaz de atender el requerimiento.
Cachs de pginas y servidores proxy

Muchos clientes Web utilizan un sistema para reducir el nmero de accesos y transferencias de
informacin a travs de Internet, y as agilizar la presentacin de documentos previamente
visitados. Para ello, almacenan en el disco del cliente una copia de las ltimas pginas a las que se
ha accedido. Este mecanismo, denominado "cach de pginas", mantiene la fecha de acceso a un
documento y comprueba, a travs de un comando HEAD, la fecha actual de modificacin del
mismo. En caso de que se detecte un cambio o actualizacin, el cliente acceder, ahora a travs
de un GET, a recoger la nueva versin del archivo. En caso contrario, se proceder a utilizar la
copia local.
NOTA
Un sistema parecido, pero con ms funciones es el denominado "servidor proxy". Este tipo de
servidor, una mezcla entre servidor HTTP y cliente Web, realiza las funciones de cache de pginas
para un gran nmero de clientes. Todos los clientes conectados a un proxy dejan que ste sea el
encargado de recoger las URLs solicitadas. De esta forma, en caso de que varios clientes accedan
a la misma pgina, el servidor proxy la podr proporcionar con un nico acceso a la informacin
original.
La principal ventaja de ambos sistemas es la drstica reduccin de conexiones a Internet
necesarias, en caso de que los clientes accedan a un conjunto similar de pginas, como suele
ocurrir con mucha frecuencia. Adems, determinadas organizaciones limitan, por motivos de
seguridad, los accesos desde su organizacin al exterior y viceversa. Para ello, se dispone de
sistemas denominados "cortafuegos" (firewalls), que son los nicos habilitados para conectarse
con el exterior. En este caso, el uso de un servidor proxy se vuelve indispensable.
En determinadas situaciones, el almacenamiento de pginas en un cach o en un proxy puede
hacer que se mantengan copias no actualizadas de la informacin, como por ejemplo en el caso de
trabajar con documentos generados dinmicamente. Para estas situaciones, los servidores HTTP
Ing. Jorge Colombo
Pag: 33
pueden informar a los clientes de la expiracin del documento, o de la imposibilidad de ser
almacenado en un cach, utilizando la variable Expires en la respuesta del servidor.
Ing. Jorge Colombo
Pag: 34

Capitulo 05 Capa de Aplicacion

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Capitulo 05 Capa de Aplicacion

Caricato da

Copyright:

Formati disponibili

Teleinformtica y comunicaciones

Mdulos de la capa de Aplicacin

Los protocolos de mximo nivel se denominan protocolos de aplicacin. Se comunican con

Caractersticas de las aplicaciones

Ing. Jorge Colombo

Estas son las aplicaciones implementadas ms ampliamente, pero existen muchas

Figura: El modelo de aplicacin cliente/servidor

Protocolo BOOTstrap - BOOTP

Ing. Jorge Colombo

Ing. Jorge Colombo

Figura: Formato de mensaje de BOOTP

Ing. Jorge Colombo

DHCP("Dynamic Host Configuration Protocol")

Ing. Jorge Colombo

Figure: Formato del mensaje DHCP

Ing. Jorge Colombo

Almacn de parmetros de configuracin

Asignando un nueva direccin de red

Ing. Jorge Colombo

Reutilizando una direccin de red previamente asignada

Ing. Jorge Colombo

DNS (Domain Name System)

Ing. Jorge Colombo

Componentes del DNS

Espacio de nombres de dominio

En funcin de su estructura organizativa:

Tipos de servidores DNS

Servidores primarios (primary name servers). Estos servidores almacenan la informacin

Ing. Jorge Colombo

Resolucin de nombres de dominio

Preguntas recursivas. Si un cliente formula una pregunta recursiva a un servidor DNS,

Veamos un ejemplo: Estamos trabajando con Internet Explorer y escribimos en la barra de

Ing. Jorge Colombo

SMTP (Simple Mail Transfer Protocol)

Ing. Jorge Colombo

El nombre oficial del protocolo para este estndar es MAIL.

Cmo funciona SMTP

una lnea nula(una lnea con slo la secuencia <CRLF>).

Ing. Jorge Colombo

Figura: Modelo para SMTP

Flujo de transaccin de correo de SMTP:

El emisor no tiene ms mensajes que enviar; cerrar la conexin con un comando

Ing. Jorge Colombo

Figura: Flujo de datos normal de SMTP - Se entrega un correo al buzn de destino.

Servidores de correo POP("Post Office Protocol")

Ing. Jorge Colombo

MIME (Multipurpose Internet Mail Extensions)

Ing. Jorge Colombo

Ing. Jorge Colombo

Paquetes RRQ y WRQ

Ing. Jorge Colombo

El paquete de OACK tiene el siguiente formato:

Ing. Jorge Colombo

FTP, File Transfer Protocol

Ing. Jorge Colombo

Modelo de Proceso FTP

Un aspecto interesante de FTP es que la conexin de comando se lleva a cabo usando un

Ing. Jorge Colombo

Muchos sistemas proporcionan un servicio FTP especial por lo cual el username

NFS("Network File System")

Figure: NFS("Network File System")

1. El protocolo de montaje Mount para especificar el host remoto y el sistema de

Ing. Jorge Colombo

Devuelve informacin sobre los sistemas de archivos disponibles