Está en la página 1de 88

Capitulo 3

Funcionalidad y protocolos de
la capa de aplicación
CIS 81 Networking Fundamentals
Rick Graziani
Cabrillo College
graziani@cabrillo.edu

Last Updated: 2/23/2008

1
Aplicaciones: Interface entre las redes

2
Capa de aplicación: Modelos TCP/IP y OSI

z La capa de Aplicación, Capa siete, es la capa superior de los modelos OSI


y TCP/IP.
C /
z Proporciona la interfaz entre las aplicaciones que utilizamos para
comunicarnos y la red subyacente en la cual se transmiten los mensajes.
3

3
Email

HTTP HTTP

HTTP
(www)

z Los protocolos de capa de aplicación se utilizan para intercambiar los datos


entre los programas que se ejecutan en los hosts de origen y destino.
z Existen muchos protocolos de capa de aplicación y siempre se desarrollan
protocolos nuevos..
4

4
C
Capa d
de aplicación:
li ió M Modelos
d l TCP/IP y OSI

z La funcionalidad de los protocolos de capa de aplicación de TCP/IP se


adaptan aproximadamente a la estructura de las tres capas superiores del
modelo OSI: Capas de Aplicación, Presentación y Sesión.
z La mayoría de los protocolos de capa de aplicación de TCP/IP se
desarrollaron antes de la aparición de computadoras personales, interfaces
del usuario g
gráficas y objetos
j multimedia.
z Estos protocolos implementan muy poco de la funcionalidad que se
especifica en las capas de Sesión y Presentación del modelo OSI.
5

5
La capa de presentación

z La capa de Presentación tiene tres funciones primarias:


1. Codificación y conversión de datos de la capa de aplicación para
garantizar que los datos del dispositivo de origen puedan ser
interpretados por la aplicación adecuada en el dispositivo de destino.
2. Compresión de los datos de forma que puedan ser descomprimidos
por el dispositivo de destino.
3. Encriptación de los datos para transmisión y descifre de los datos
cuando se reciben en el destino.
z Dentro de los formatos de imagen gráfica más conocidos encontramos
Formato de intercambio gráfico (GIF), Grupo de expertos en fotografía
(JPEG) y Formato de archivo de imagen etiquetada (TIFF). 6

6
La capa de sesión

z Crea y mantiene diálogos entre las aplicaciones de origen y destino.


z Maneja el intercambio de información para iniciar los diálogos y
mantenerlos activos, y para reiniciar sesiones que se interrumpieron o
desactivaron durante un periodo de tiempo prolongado.
z La mayoría de las aplicaciones
aplicaciones, como los exploradores Web o los clientes
de correo electrónico, incorporan la funcionalidad de las capas 5, 6 y 7 del
modelo OSI. 7

7
Capa de aplicación:
Modelos TCP/IP y OSI
Nota: Usualmente un
simple servidor
fucionara como un
multiple servidor de
multiples aplicaciones

z Algunos de los protocolos TCP/IP son:


• El protocolo Servicio de nombres de dominio (DNS, Domain Name Service) se utiliza
para resolver nombres de Internet en direcciones IP.
• El protocolo de transferencia de hipertexto (HTTP,
(HTTP Hypertext Transfer Protocol) se
utiliza para transferir archivos que forman las páginas Web de la World Wide Web.
• El Protocolo simple de transferencia de correo (SMTP) se utiliza para la transferencia
de mensajes de correo y adjuntos.
• Telnet, un protocolo de emulación de terminal
Telnet terminal, se utiliza para proporcionar acceso
remoto a servidores y a dispositivos de red.
• El Protocolo de transferencia de archivos (FTP, File Transfer Protocol) se utiliza
para la tansferencia interactiva de archivos entre sistemas. 8

8
RFCs: Request For Comments

z Los protocolos de la suite TCP/IP generalmente son definidos por


Solicitudes de comentarios (RFCS). El Grupo de trabajo de ingeniería de
Internet (IETF) mantiene las RFCS como los estándares para el conjunto
TCP/IP.
C /
Encontrara algo para divertirse en:
9
- ftp://ftp.rfc-editor.org/in-notes/rfc1882.txt.

9
Software
S ft de
d lal capa
de aplicación Aplicaciones

z Dentro de la capa de Servicios


Aplicación, existen dos
formas de procesos o
programas ded software
ft que
proporcionan acceso a la Operaciones
red: aplicaciones y del sistema
servicios.

z Aplicaciones reconocidas por la red


Aplicaciones son los programas de software que utiliza la gente para
comunicarse a través de la red.
Algunas aplicaciones de usuario final son compatibles con la red, lo
cual significa que implementan los protocolos de la capa de
aplicación y pueden comunicarse directamente con las capas
inferiores del stack de protocolos. Ejemplos: Clientes de correo
10
electrónico y los exploradores Web.

10
Software
S ft de
d lal capa
de aplicación Aplicaciones

Servicios

Operaciones
del sistema

z Servicios de la capa de Aplicación


Otros programas pueden necesitar la ayuda de los servicios de la capa
de Aplicación para utilizar los recursos de la red, como transferencia de
archivos o cola de impresión en red.
Estos servicios son los programas que se comunican con la red y
preparan los datos para la transferencia..
11

11
S ft
Software de
d la
l capa d
de aplicación
li ió

z L
La capa de
d Aplicación
A li ió utiliza
tili llos protocolos
t l iimplementados
l t d d dentro
t d de llas
aplicaciones y servicios.
Las aplicaciones proporcionan a las personas una forma de crear
mensajes.
Los servicios de la capa de aplicación establecen una interfaz con la
red.
Los protocolos proporcionan las reglas y los formatos que regulan el
tratamiento de los datos
datos..
z Por ejemplo: cuando analizamos "Telnet" nos podemos referir a la
aplicación, el servicio o el protocolo. 12

12
F
Funciones
i del
d l protocolo
t l dde capa d
de aplicación
li ió

z Los protocolos de la capa de aplicación son utilizados tanto por los dispositivos de
origen como de destino durante una sesión de comunicación
comunicación..
z Deben coincidir los protocolos de capa de aplicación implementados en el host de
origen y destino..
z Protocolos: (Estos seran mas entendibles despues.)
Establecen reglas consistentes para intercambiar datos
datos.
Especifican cómo se estructuran los datos dentro de los mensajes y los tipos de
mensajes que se envían entre origen y destino..
Tipos: solicitudes de servicios, acuses de recibo, mensajes de datos,
mensajes de estado o mensajes de error
error, etc.
etc
Definen los diálogos de mensajes, asegurando que un mensaje enviado
encuentre la respuesta esperada y se invoquen los servicios correspondientes
cuando se realiza la transferencia de datos.. 13

13
Funciones del protocolo de capa de aplicación

z Las aplicaciones y los servicios también pueden utilizar múltiples protocolos


durante el curso de una comunicación simple.
El protocolo encapsula o el encapsulado de este protocolo
Invoca otros protocolos
z Usando un navegador web (HTTP):
Puede invocar:
DNS ARP,
DNS, ARP ICMP
Puede usar:
TCP, UDP, Ethernet, PPP
Usa
IP
14

14
Modelo cliente - servidor

z Cliente: dispositivo que solicita información


z Servidor: el dispositivo que responde a la solicitud.
El cliente comienza el intercambio solicitando los datos al servidor.
El servidor responde enviando uno o más streams de datos al cliente.
Además de la transferencia real de datos, este intercambio puede
requerir de información adicional , tal como:
autenticación del usuario
la identificación de un archivo de datos a transferir 15

15
Servidores

z Un servidor generalmente es una computadora que contiene información


para ser compartida
tid con muchosh sistemas
i t d
de cliente.
li t
Servidor Web server
Servidor Email server
Servidor de documentos o base de datos
Servidor de Aplicaciones
z Algunos servidores pueden requerir de autenticación de la información de
cuenta del usuario.
z Por ejemplo, si usted solicita subir datos al servidor FTP, se le puede dar
permiso para escribir su carpeta personal pero no para leer otros archivos
del sitio. 16

16
Servidores

z E
En una red d cliente-servidor,
li t id ell servidor
id ejecuta
j t un servicio
i i o proceso, a veces
denominado daemon de servidor.
z Al igual que la mayoría de los servicios, los daemons generalmente se ejecutan en
segundo plano y no se encuentran bajo control directo del usuario.
z Los daemons se describen como ser servidores
idores q
que
e "esc
"escuchan"
chan" una
na solicit
solicitud
d del
cliente.
Porque están programados para responder cada vez que el servidor recibe una
solicitud para el servicio proporcionado por el daemon.
z Cuando un daemon "escucha" una solicitud de un cliente:
Intercambia los mensajes adecuados con el cliente, según lo requerido por su
protocolo, y procede a enviar los datos solicitados al cliente en el formato
correspondiente.. 17

17
Protocolos y servicios
de la capa de aplicación

z Los servidores generalmente tienen múltiples clientes que solicitan


información al mismo tiempo.
z Por ejemplo, un servidor Telnet puede tener varios clientes que requieren
conectarse
t a él.
él
Estas solicitudes individuales del cliente pueden manejarse en forma
simultánea y separada para que la red sea exitosa..
Los servicios y procesos de capa de Aplicación dependen del soporte
de las funciones de la capa inferior para administrar en forma exitosa
las múltiples conversaciones. 18

18
Protocolos de la capa de aplicación

19
HTTP
(WWW) DHCP
Examinaremos (Resolución de
HTTP en detalle. direcciones IP)

FTP
(Transferencia DNS
de archivos) (R
(Resolución
l ió
de nombres
de dominios)
SMTP SMB
(email) (Campartir
archivos)

P2P
Telnet ((Compartir
(login remoto) archivos)

20

20
Recordatorio de encapsulación/desencapsulación
/
Data Link IP TCP HTTP Data Link
Data Trailer
Header Header Header Header

Data Link Data Link


IP Packet
H d
Header Trailer

Data Link Data Link


IP Packet
Header Trailer

Data Link Data Link


IP Packet
Header Trailer

Data Link IP TCP HTTP Data Link


Header Header Header Header
Data Trailer 21

21
Enfocarse en el encabezado de la capa de
Aplicacion y/o Datos
HTTP

HTTP

z Examinaremos como ocurre la comunicacion la aplicacion (encabezado)


y/o datos entre el cliente y el servidor
z “Después” miraremos el rol que juegan las otras capas, protocolos (TCP, 22
IP, etc.) .

22
HTTP (Protocolo de transferencia de Hipertexto)
HTTP HTTP

HTTP
HTTP
Client
Server

z HTTP – Protocolo
P t l de
d lla capa d
de aplicacion
li i usado
d por W Worldld Wid
Wide W
Web.
b
z RFC 1945 y RFC 2616
z Especifica cuales mensajes pueden enviar los clientes a los servidores y
que respuesta obtienen
z Version actual: HTTP/1.1
z La forma común en que un navegador contacta a un servidor es
estableciendo una conexion TCP con el puerto 80 (mas adelante)

23

23
HTTP (Protocolo de transferencia de Hipertexto)
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Rick Graziani, Cabrillo College</title><style type="text/css">
<!--
body {
margin-left: 0px;
El archivo HTML base hace referencia a
margin-top: 0px; otros objetos en la pagina
margin-right: 0px;
margin-bottom: 0px;

z L
Las paginas
i Web
W b (también
(t bié se llaman
ll documentos
d t html)
ht l)
z Las paginas WEB contienen objetos
Objetos (ejemplos):
Archivos HTML
Imagen JPEG
Imagen GIF
JAVA applet
Archivos de Audio
24

24
Navegador Web - Cliente
C

Cliente
HTTP

z Navegador – El agente del usuario para la Web


Web.
Muestra la pagina Web solicitada y proporciona características de
navegación y configuración.
z Navegador y cliente pueden ser usadas de forma intercambiable en esta
discusión.
z HTTP no influye en como la pagina Web es interpretada (Mostrada) por el 25
cliente (Navegador).

25
Servidor Web

Servidor
HTTP

z Servidor Web – Almacena objetos WEB, cada uno direccionable por un


URL
URL.
z Implementa el servidor de HTTP.
z Ejemplos:
A
Apache
h
Microsoft Internet Information Server
26

26
Mensaje de solicitud HTTP
GET /~rgraziani/ HTTP/1.1 Algunos datos fueron omitidos por brevedad
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET
CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.1)
Host: www.cabrillo.edu
Connection: Keep-Alive

Servidor
HTTP
Cliente
z Mensajej de solicitud HTTP
Una línea de solicitud
Los campos del encabezado de solicitud
z Texto ASCII
z Línea de solicitud: Campo del método
GET, POST y HEAD
27
La gran mayoría de solicitudes son GETs

27
Mensaje de solicitud HTTP
GET /~rgraziani/ HTTP/1.1
Accept-Language: en-us
User-Agent: Mozilla/4.0
Mozilla/4 0 (compatible; MSIE 7.0;
7 0; Windows NT 6.0;
6 0; SLCC1; .NET
NET
CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.1)
Host: www.cabrillo.edu
Connection: Keep-Alive

Línea de solicitud
GET - Navegador /cliente esta solicitando un objeto

/~rgraziani/ - Navegador esta solicitando este objeto en


este directorio (por defecto es index.html)
HTTP/1 1
HTTP/1.1 - Navegador implementa HTTP/1
HTTP/1.1 1 (1
(1.1
1 es
compatible con 1.0)

Nota: El GET HTTP también es usado por algunas aplicaciones P2P


como Gnutella y Bittorrent.
28

28
Mensaje de solicitud HTTP
GET /~rgraziani/ HTTP/1.1
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET
CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.1)
Host: www.cabrillo.edu
Connection: Keep-Alive

Líneas de solicitud
GET: - Solicita el objeto ubicado en la URL especificada.
POST: - Envía datos al programa ubicado en la URL
especificada.
- Ejemplo: palabras en un motor de búsqueda.
HEAD: - Similar
Si il a GET,
GET Solicita
S li it ell encabezado
b d ddell recurso
ubicado en la URL especificada.
PUT: - Envía datos a la URL especificada, subir objetos.
DELETE: - Borra el recurso ubicado en la URL especificada.
29

29
Mensaje de solicitud HTTP
GET /~rgraziani/ HTTP/1.1
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET
CLR 2.0.50727;
2 0 50727 Media
di Center PC 55.0;
0 .NET CLR 33.0.04506;
0 04506 InfoPath.1)
f h 1)
Host: www.cabrillo.edu
Connection: Keep-Alive

Líneas del encabezado


Accept-Language:- Idioma que el navegador espera (de forma
predeterminada, inglés)
User-Agent: - El nombre y la versión del navegador y el
sistema operativo
Host: - Host en el que reside el objeto
j
Connection: - Cliente/Navegador informa al servidor que
mantiene esta conexión TCP abierta,
conocida como una conexión persistente.
- Discutiremos esto después en TCP
(Capa de transporte) 30

30
Mensaje de solicitud HTTP
HTTP/1.1 200 OK Algunos datos son omitidos por brevedad
Date:
ate: Fri,
, 22 Feb
eb 2008
008 16:34:18
6:3 : 8 G
GMT
Server: Apache/2.0.52 (Red Hat)
Last-Modified: Thu, 15 Nov 2007 19:33:12 GMT
Content-Length: 15137
Connection: close
C t t T
Content-Type: t
text/html
t/ht l

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

HTTP
Server
HTTP Client
Cli t

31

31
Mensaje de respuesta HTTP
HTTP/1.1 200 OK
Date: Fri, 22 Feb 2008 16:34:18 GMT
S
Server: A
Apache/2.0.52
h /2 0 52 (R
(Red
d H
Hat)
t)
Last-Modified: Thu, 15 Nov 2007 19:33:12 GMT
Content-Length: 15137
Connection: close
Content-Type: text/html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

z Mensaje de respuesta:
Una línea de estados
Los campos del encabezado de respuesta
El cuerpo de la respuesta

32

32
Mensaje de respuesta HTTP
HTTP/1.1 200 OK
Date: Fri, 22 Feb 2008 16:34:18 GMT
Server: Apache/2.0.52 (Red Hat)
Last-Modified: Thu, 15 Nov 2007 19:33:12 GMT
Content-Length: 15137
Connection: close
Content-Type: text/html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Línea de estados
HTTP/1.1 – Servidor esta usando HTTP/1.1
200 OK - Código de estado
estado, solicitud exitosa y la información
es regresada en la respuesta

33

33
Mensaje de respuesta HTTP
HTTP/1.1 404

Códigos de estado
200 OK
- Código de estado
estado, solicitud exitosa y la información es regresada en la respuesta
respuesta.
301 Moved Permanently
- Los datos solicitados han sido transferidos a una nueva dirección.
400 Bad Request
- La
L sintaxis
i t i dde lla solicitud
li it d se encuentra
t fformulada
l d d
de manera errónea
ó o es iimposible
ibl dde
responder.
404 Not Found:
-Un clásico. El servidor no halló nada en la dirección especificada. Se ha abandonado sin dejar
una dirección para redireccionar
505 HTTP Version Not Supported
- La versión del protocolo HTTP solicitada no es soportada por el servidor.
34

34
Mensaje de respuesta HTTP
HTTP/1.1 200 OK
Date: Fri, 22 Feb 2008 16:34:18 GMT
Server: Apache/2.0.52 (Red Hat)
Last-Modified: Thu, 15 Nov 2007 19:33:12 GMT
Content-Length: 15137
Connection: close
Content-Type: text/html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Líneas del encabezado


Date: – Fecha en que comienza la transferencia de datos
Server: - Características del servidor que envió la
respuesta
Last-Modified: – Fecha/hora cuando fue creado o modificado el objeto
Content-Length: – Numero de bytes que contiene el objeto
Connection: – El servidor cerrera la conexión TCP después de
enviar el objeto solicitado.
Content-Type: – El cuerpo del objeto es texto HTML 35

35
Mensaje de respuesta HTTP
HTTP/1.1 200 OK
Date: Fri, 22 Feb 2008 16:34:18 GMT
Server: Apache/2.0.52 (Red Hat)
Last-Modified: Thu, 15 Nov 2007 19:33:12 GMT
Content-Length: 15137
Connection: close
Content-Type: text/html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Cuerpo del objeto

<!DOCTYPE html PUBLIC etc.:

– Texto HTML y otros objetos seran usados por los


navegadores/clientes

36

36
Mensajes de solicitud y respuesta HTTP
GET /~rgraziani/ HTTP/1.1
Accept-Language: en-us
g
User-Agent: Mozilla/4.0
/ (
(compatible;
p ; MSIE 7.0;
; Windows NT 6.0;
; SLCC1;
; .NET
CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.1)
Host: www.cabrillo.edu
Connection: Keep-Alive

HTTP

HTTP
HTTP
Server
HTTP Client
HTTP/1.1 200 OK
Date: Fri,
, 22 Feb 2008 16:34:18 GMT
Server: Apache/2.0.52 (Red Hat)
Last-Modified: Thu, 15 Nov 2007 19:33:12 GMT
Content-Length: 15137
Connection: close
Content Type: text/html
Content-Type:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 37
<html xmlns="http://www.w3.org/1999/xhtml">

37
Interacción Usuario-Servidor:
C ki
Cookies

z S
Servidores
id Web
W b son considerados
id d una entidadtid d sin
i estado–
t d ellos
ll no
mantienen informacion de estado sobre sus usuarios.
Alto rendimiento – Le permite al servidor manejar miles de conexiones
TCP de forma simltanea
simltanea. (Despues)
(Despues).
z Servidores Web usan cookies para segir la pista de los usuarios.
z Las Cookies se formalizaron en el RFC 2109

38

38
Interacción Usuario-Servidor:
Usuario Servidor: Cookies
Solicitud HTTP : GET
(first time)

HTTP Respuesta HTTP:


Server Set-cookie: ID

Servidor
S id Web
W b ahora
h puede
d Solicitud HTTP (GET) HTTP Client
seguir las actividades de ahora incluye un ID
los clientes en el sitio web.
z Servidor WEB instala cookies en el cliente cuando:
Acceda al sitio web por primera vez (Servidor WEB no conoce al cliente por su
nombre.)
y/o
El usuario proporciona información al servidor WEB. (Servidor Web conoce
ahora al cliente por su nombre.)
z HTTP en el Servidor Web responde con un Set-cookie: encabezado con un ID.
Este ID es almacenado en la computadora cliente
cliente.
z Cada vez que el cliente/navegador acceda al sitio web. El GET incluye un Cookie: o
ID de usuario o similar con el ID.
39

39
Mensajes
j de solicitud y respuesta
p HTTP
GET /jpeg/cap81/cam0.36705623.rgb888.enc HTTP/1.1
<information omitted>
Cookie: SLSPOTNAME5=Cowells; SLSPOTNAME4=Waimea%20Bay;
SLSPOTNAME3=Pipeline; SLSPOTNAME2=38th%20Ave%2E; SLSPOTNAME1=Cowells;
SLSPOTID5=4189; SLSPOTID4=4755; SLSPOTID3=4750; SLSPOTID2=4191;
SLSPOTID1=4189; OAX=R8bfwEbcU08ABCBu; USER_ID=5551212 <not my actual
user-id>; <rest of informaton omitted for brevity>

HTTP: Incluye Cookie 5551212

Servidor
Datos HTTP personalizados
HTTP
para Rick Graziani
Cliente
HTTP/1.1 200 OK HTTP
Date: Fri, 22 Feb 2008 19:00:15 GMT
Server: Apache/1.3.34 (Unix)
Last-Modified: Fri, 22 Feb 2008 18:51:47 GMT
ETag: "760a31-18ce-47bf19c3"
Accept-Ranges:
Accept Ranges: bytes
Content-Length: 6350
Keep-Alive: timeout=15, max=257
Connection: Keep-Alive 40
Content-Type: text/plain <information omitted>

40
Web Caching Web
Cache or HTTP Cli t
Client
HTTP Request
Request
Proxy
Origin Server
Server HTTP Response

HTTP Response
HTTP
HTTP Request
Request
Orgin HTTP Response
Server HTTP Response
Client

z W
Webb cache
h o Servidor
S id proxy – Web W b cacheh satisface
ti f las
l solicitudes
li it d HTTP
en el nombre del servidor Web de origen.
Almacena en su propio disco
Mantiene copias de los objetos solicitados recientemente
recientemente.
z Típicamente se instalan en el ISP o en grandes instituciones
z Ventajas:
Red ce el tiempo de resp
Reduce respuesta
esta de las solicit
solicitudes
des los clientes
clientes,
especialmente si hay cuellos de botella en la red.
Reduce el trafico en el enlace de la institución al ISP (Internet). 41

41
Web Caching Web
Cache or HTTP Cli t
Client
HTTP Request
Request
Proxy
Origin Server
Server HTTP Response

HTTP Response
HTTP
HTTP Request
Request
Origin HTTP Response
Server HTTP Response
Client

1.Clientes/Navegadores
1 Cli t /N d envían
í solicitudes
li it d HTTP all WebW b cache
h (Proxy
(P server).
)
2. Web cache revisa si tiene una copia local del objeto.
2a. Copia Local: Web cache envía el objeto al navegador del cliente.
2b No hay copia Local : Web cache envía la solicitud HTTP al servidor
2b.
de origen.
3. El servidor de Origen envía el objeto solicitado a la Web cache.
4. Web cache almacena una copia local del objeto.
5. Web cache envía una copia del objeto al navegador del cliente.
Nota: Las conexiones TCP son también creadas entre el Cliente y el Web
Cache; el Web cache y el servidor de Origen (después). 42

42
Web Caching (Extra)

z Problemas – cache desfasada


j
El objeto p
pudo haber sido modificado en el servidor de origen
g desde
que la copia fue hecha por la Web cache.
z Solución – Conditional GET
Método de solicitud: GET
Incluye encabezado: If-Modified-Since:
z Web cache envía el Conditional GET al servidor de origen para ver si hay
una nueva versión del objeto.
No hay versión nueva: se envía el objeto local presente
Hay versión nueva: Se reemplaza la el objeto presente y se envía la
nueva versión. 43

43
Pasos - Web Cache (Extra)
1. Clientes/Navegadores envían solicitudes HTTP al Web cache (Proxy server).
2. Web cache revisa si tiene una copia local del objeto.
No hay copia local
3. Web cache envía la solicitud HTTP al servidor de origen.
4. El servidor de Origen envía una respuesta HTTP con el objeto solicitado.
5. Web cache almacena una copia local del objeto con la ultima fecha de
modificación..
6. Web cache envía una el objeto al cliente/navegador

1. Web cache recibe otra solicitud para este objeto HTTP.


2. Web cache envía un Conditional GET al servidor web de origen, con If-
modified-since: en el encabezado.
3. El servidor web de origen devuelve:
No hay cambios: Mensaje HTTP de respuesta 304 Not Modified.
Web cache envía el objeto local.
Hay cambios: HTTP Responde 200 OK, con el objeto.
Web cache reemplaza el objeto y envía el objeto actualizado.
44

44
HTTPS

z HTTPS (Hypertext
(H t t Transfer
T f Protocol
P t l Secure)
S ) es una combinación
bi ió ddell
protocolo HTTP y protocolos criptográficos tales como el: Protocolo de
Capa de Conexión Segura (SSL) o Seguridad de la Capa de Transporte
(TLS).
z Se emplea para lograr conexiones más seguras en la WWW, generalmente
para transacciones de pagos o cada vez que se intercambie información
sensible (por ejemplo, claves) en internet

45

45
FTP (Protocolo de transferencia de archivos)
Cliente Servidor
FTP FTP

z FTP fue desarrollado para permitir la transferencia de archivos entre un cliente y


un servidor.
z Usado para cargar y descargar archivos desde un servidor que ejecuta el daemon
FTP (FTPd).
z Usa comandos get y put.
46
z RFC 959

46
FTP (Protocolo de transferencia de archivos)
Conexion de control TCP puerto 21
Username y password
Cambie de directorio en el servidor

Conexion de datos TCP puerto 20


Copie el archivo desde el cliente al servidor – Conexion cerrada

Conexion de datos TCP puerto 20


Copie el archivo desde el cliente al servidor – Conexion cerrada

Conexion de control TCP puerto 21


Salir de la aplicacion FTP – Conexion cerrada
z El cliente inicia una conexión de control TCP con el servidor FTP usando puerto 21.
Esta conexión permanece abierta hasta que el usuario sale de la aplicación FTP.
Conexión TCP a través del puerto 21 incluye:
Username y password que se envían a través del puerto 21 de TCPTCP.
Cambio de directorio remoto
Esta información de estado reduce el numero total de sesiones ene el servidor
z Para cada archivo transferido, TCP abre y cierra una Conexión de datos TCP con el
puerto 20.

47

47
SMTP – Protocolo simple de transferencia de correo

z Email – Es una de las aplicaciones asesinas de la internet.

48

48
SMTP – Protocolo simple de transferencia de correo

Agente de usuario Servidor de correo Servidor de correo Agente de usuario


SMTP SMTP

POP3
IMAP

z El correo a través de Internet involucra:


Agente de usuario
Permite a los usuarios leer, responder, redactar, enviar, salvar, etc., mensajes de
correo
Agentes de usuarios con GUI: Outlook, Eudora, Messenger
Agentes de usuarios de Texto: mail, pine, elm
Servidor de e-mail
Almacena el buzón del usuario, comunica los agentes de usuarios locales con
otros servidores de e-mail.
SMTP
Principal protocolo de la capa de aplicación para el correo a través de Internet
Envía sobre TCP
Protocolos de acceso al correo : POP3, IMAP, HTTP 49

49
SMTP – Protocolo simple de transferencia de correo

Agente de usuario Servidor de correo Servidor de correo Agente de usuario


SMTP SMTP

POP3
IMAP

z SMTP
RFC 2821
Transfiere mensajes desde un servidor de correo emisor al recipiente
de un servidor de correo.
correo
Protocolo de empuje, no protocolo de extraer
Empuja (desde el cliente al servidor o de servidor a servidor)
Extrae (desde el servidor hacia el cliente)
z Recuperar
Rec perar email
Históricamente, los usuarios debían de ingresar a un servidor local de
correo para leer sus correos.
Desde los inicios de los 90’s, los clientes usan protocolos de acceso al
correo:
POP3
IMAP
50
HTTP

50
SMTP – Protocolo simple de transferencia de correo
Agente de Servidor de Servidor Agente de
usuario correo de correo usuario
SMTP SMTP
POP3
IMAP
z POP3 (Protocolo de oficina de correos v.3)
RFC 1939
Funcionalidad limitada
Usa el puerto TCP 110
Modo descarga y borra
Recupera los mensajes desde el servidor y los almacena localmente
Borra los mensajesj del servidor
Modo descarga y mantiene
No borra los mensajes del servidor cuando los recupera.
Problemas
Difícil acceso al correo desde múltiples computadoras – el trabajo y la
casa.
Algunos emails pueden haber sido descargados en otra computadora
(el trabajo) – descargados y borrados.
Para leer desde otra computadora,
p , debe cambiar en el servidor –
descargar y mantener
No facilita al usuario crear carpetas remotas en el servidor de correo.
51

51
SMTP – Protocolo simple de transferencia de correo

Agente de usuario Servidor de correo Servidor de correo Agente de usuario


SMTP SMTP

POP3
IMAP

z IMAP (Protocolo de acceso a mensajes de internet)


RFC 2060
Los email no se descargan
descargan, permanecen en el servidor
servidor.
Recibe email asociados con el casillero de correo entrante del usuario
El usuario puede crear y manejar carpetas remotas
El usuario puede recuperar partes del email:
E
Encabezado
b d ddell mensaje:
j lílínea d
de asunto y remitente.
i

z Web-based email
Introducido con Hotmail a mediados de los 90´s
90 s
Comunica con un buzón de mensajes usando HTTP
HTTP es usado para poner (cliente hacia el servidor) y extraer el
correo (servidor hacia el cliente) 52

52
SMTP

MTA
z Recibe mensajes desde el
MUA u otro MTA en otro
servidor de e-mail.
z Pasa el correo MDA para
su entrega final
fi l
z Usa SMTP para enrutar el
email entre servidores

Procesos del servidor de e-mail: MTA y MDA


z Agente de transferencia de correo (MTA, Mail Transfer Agent) – Software
cliente de correo.
z Agente de entrega de correo (MDA, Mail Delivery Agent). – Software que
gobierna la transferencia de correos entre servidores
Incluye
y UNIX sendmail, Microsoft Exchange g Server, Postfix, y Exim
z Agente de entrega de correo (MDA, Mail Delivery Agent). – Software que
gobierna la transferencia de correos entre un servidor de correo y un cliente.
53
En sistemas Unix, procmail y maildrop son los mas populares MDAs.

53
Telnet
Telnet Telnet

Servidor

z Telnet proporciona un método estándar de emulación de dispositivos de


t
terminal
i lb basados
d en ttexto
t en lla red
ddde d
datos.
t
z Una conexión que utiliza Telnet se llama Sesión o conexión de terminal
virtual (VTY). 54

54
Telnet Telnet Telnet

Servidor

z Permite a un usuario acceso remotamente a otro dispositivo (host, router,


switch).
z Telnet utiliza software para crear un dispositivo virtual que proporciona las
mismas funciones que una sesión terminal con acceso a la Interfaz de línea
de comandos (CLI) del servidor.
z Clientes Telnet:
Putty
Teraterm
Hyperterm
55

55
Telnet

z T
Telnet
l t admite
d it autenticación
t ti ió d
de usuario,
i pero no admite
d it ell ttransporte
t dde
datos encriptados..
z Todos los datos intercambiados durante una sesión Telnet se transportan
como texto sin formato por la red
red.
z El protocolo Shell seguro (SSH) ofrece un método seguro y alternativo
para acceder al servidor. SSH proporciona la estructura para un inicio de
sesión remoto seguro
g y otros servicios de red seguros.
g Además
proporciona mayor autenticación que Telnet y admite el transporte de
datos de sesión utilizando cifrado.
56

56
DHCP – Protocolo de configuración dinámica de host

z Los dispositivos de una red pueden obtener direcciones IP y demás


información de forma:
Estáticamente
Dinámicamente (DHCP) 57

57
DHCP

z La informacion DHCP puede incluir:


direcciones IP,
IP
máscaras de subred,
Gateways,
Servidor DNS
y otros parámetros de redes IP.
z Los servidores DHCP pueden ser:
S id en una LAN
Servidor
Un router
Servidor en un ISP 58

58
DHCP

z Discutiremos mas sobre DHCP


cuando estudiemos IPV4

59

59
DNS – Sistema de nombres de dominio

z DNS permite a los usuarios (software) usar nombres de dominios en vez de


direcciones IP.

60

60
Resolución de nombres

Necesita una dirección IP

Resolvedor
z Programa
P cliente
li t DNS usadod para bbuscar iinformación
f ió d
de un nombre
b en un
DNS.
Resolución de nombres
z Los dos tipos de solicitudes que un programa cliente (ya sea un cliente
DNS o otro
t servidor
id DNS) pueden
d h hacer a un servidor
id DNS son llos
siguientes:
Solicitudes recursivas
z Solicitudes realizadas por un Host a un servidor DNS local.
Solicitudes iterativas
z Solicitudes realizadas un servidor DNS local a otros servidores
61

61
DNS Name Resolution

z El usuario escribe http://www.example.com

Paso 1.
z El resolvedor DNS en el cliente DNS envía una solicitud recursiva a su
servidor DNS local configurado.
z Solicita una dirección IP para "www.example.com".
z El servidor DNS para ese cliente es responsable para la resolución del
nombre
No puede referir al cliente DNS a otro servidor DNS.

62

62
Resolución de 2
3
2

nombres DNS

Paso 2.
z El servidor local DNS envía la solicitud a un servidor DNS de raiz.

Paso 3.
z El servidor DNS de raíz
Toma nota del sufijo .com
Devuelve una lista de direcciones IP para un TLD (Top Level Domain
Servers – Servidores de dominio de nivel superior) responsable de
.com.
com

63

63
Resolución de nombres DNS

z Servidor DNS de raíz


Hay 13 servidores DNS de raíz (etiquetados desde la A hasta la M)
z Servidores de dominio de nivel superior
p (TLD)
( )
Son responsables para dominios tales como: .com, edu, org, .net, .uk,
jp, fr
Soluciones de red mantiene servidores TLD . com
P
Para educación
d ió se mantiene
ti servidores
id TLD .edu
d
Hay servidores redundantes alrededor del mundo.
64

64
Resolución de
nombres DNS 4
4

Paso 4.
z El servidor local DNS envía la solicitud para www
www.example.com
example com a un
servidor de dominio de nivel superior (TLD).

Paso 5
5.
z El servidor de dominio de nivel superior (TLD).
Toma nota de example.com
Devuelve direcciones IP de un servidor autorizado de example
example.com
com (tal
como un servidor dns.example.com)
65

65
Resolución de
nombres DNS
6

6
7

Paso 6.
z El servidor local DNS envía la solicitud p
para www.example.com
p
directamente a un servidor DNS de example.com

Paso 7.
z El servidor DNS de example.com responde con su dirección IP de
www.example.com

66

66
Resolución de
nombres DNS
8

Paso 8.
P 8
z El servidor local DNS envía la dirección IP de www.example.com al
cliente DNS.

DNS Caching
z Cuando el servidor DNS recibe una respuesta DNS (establecer
equivalencias entre un hostname y una dirección IP) esta copia de
información se hace en su memoria local.
z Los servidores DNS descartan la información copiada después de un
periodo de tiempo (usualmente 2 días)
z Un servidor local DNS puede copiar direcciones de servidores TLD,
omitiendo a los servidores de raíz en la secuencia de búsqueda.
67

67
Resolución de
nombres DNS
z En el peor de los casos, conseguimos
una ventana diciendo que el nombre
del dominio no existe.
existe
z Esto pasa porque el servidor
autorizado es lento respondiendo al
primero y su PC se cansa de esperar,
p p ,
entonces descarta la conexion o el
nombre del dominio no existe.
z Pero si se intenta nuevamente, hay
probabilidades
b bilid d d de ttener exito,
it porque
el servidor autorizado a tenido
suficiente tiempo para responder, y su
servidor de nombres ha almacenado la
informacion en la cache.

68

68
nslookup

nslookup
z Muestra el servidor DNS por defecto de su host
z Puede ser usado para solicitar un nombre de dominio y obtener la dirección
IP 69

69
Resolución de
nombres
b DNS

z ipconfig /displaydns
p
Después de cierto tiempo
p especificada
p en el tiempo
p de vida ((Time to
Live - TTL) asociada con el registro de recursos DNS, el resolvedor
descarta los registros de la cache.
z ipconfig /flushdns – Borra manualmente la entradas
z El TTL por defecto para respuestas positivas es de 86,400 segundos (1
día).
z El TTL por defecto para respuestas negativas es de 300 segundos. 70

70
(Mi i
(Missing I f ) DNS:
Info) DNS 204.127.199.8
204 127 199 8

71

71
72

72
73

73
74

74
SMB – Protocolo Bloque de mensajes del servidor

z El Bloque de mensajes del servidor (SMB) es un protocolo cliente-servidor


para compartir archivos. IBM desarrolló el Bloque de mensajes del servidor
(SMB) a fines de la década del '80
80 para describir la estructura de recursos
de red compartidos, como directorios, archivos, impresoras y puertos
seriales..
75

75
SMB

z Protocolo de solicitud y respuesta.


z A diferencia de FTP, los clientes establecen una conexión por un largo
periodo de tiempo con los servidores.
z Los clientes p
pueden acceder a los recursos en los servidores como a a los
recursos en los host de los clientes.
z SMB es enviado sobre TCP
Anteriormente Windows 2000 usaba un protocolo propietario
(NETBIOS) para enviar SMB.
z Linux/UNIX tienen un protocolo similar: SAMBA
76

76
SMB

z Los mensajes SMB pueden:


Iniciar, autenticar y terminar sesiones
C t l ell acceso a archivos
Controlar hi e iimpresoras
Permitir a una aplicación enviar o recibir mensajes hacia o desde otro
dispositivo

77

77
Redes Punto a Punto(P2P) y aplicaciones

z En adición al modelo de redes cliente/servidor, también existe el modelo


punto a punto.
z Son dos o mas computadoras que están conectadas vía una red y pueden
compartir recursos (tale como impresoras o archivos) sin tener un servidor
dedicado.
z Los dispositivos terminales (puntos) pueden funcionar como cliente o
servidor 78

78
Compartiendo archivo
P2P

z Las cuentas para compartir archivos P2P (Punto a punto) generan la mayor
cantidad de trafico en internet que cualquier otra aplicación (2004).
z Los puntos (hosts) actúan como clientes y servidores.
z No existe un servidor de archivos centralizado.
79
z El HTTP GET y respuestas se usan comúnmente.

79
Directorio centralizado P2P Punto

Punto
Servidor con Punto
directorio
1 – Informar y actualizar 3 – Transferencia de archivo
centralizado
Punto

La transferencia de archivos es
Napster descentralizada pero la localización de
contenido (archivos) es altamente
centralizado
t li d

z Desafíos con P2P – localizar contenidos a través de centenares o miles de


puntos
puntos.
z Una solución – Directorio centralizado
Estrategia hecha por Napster
z Problemas legales con música (Copyright infringement)
Punto individual de falla
Cuello de botella a la capacidad (performance) 80

80
Directorio centralizado P2P Punto

Punto
Servidor con Punto
directorio
1 – Informar y actualizar 3 – Transferencia de archivo
centralizado
Punto

1. El punto A inicia la aplicación P2P


2. Informa al directorio centralizado de esto:
Dirección IP
Nombre del objeto que ponen a disposición para compartir (MP3, videos, etc.)
3. El servidor con directorio recoge información de cada punto que se activa.
Base de datos dinámica
Mapas de las direcciones IP con el nombre de los objetos
4. Punto A solicita al servidor de directorio por la dirección IP de otro punto con el
contenido especifico
El servidor
id ded directorio
di t i reenvía í la
l dirección
di ió IP para ese puntot (Punto
(P t B)
5. El punto A establece una conexión TCP y descarga el archivo (ej. HTTP GET) desde el
otro punto, Punto B.
6. El servidor de directorio remueve el p punto de la base de datos cuando el p punto cierra la
aplicación o se desconecta de internet (mensajes periódicos– pings – desde el
servidor).
81

81
Query

Query hit
Punto B Punto C
Inundación de
Query
preguntas (Query Query
flooding): Gnutella Punto A Punto D Punto E

Punto F

Gnutella Query – Mensaje de pregunta


Query hit – Resultado positivo
• Completamente distribuido
– sin servidor central
• Protocolo de dominio público
• Muchos clientes Gnutella implementan el protocolo
• Hay enlace entre puntos A y B si hay una conexión TCP
• Todos los puntos activos y sus enlaces forman la red sobrepuesta (overlay net)
• Cada enlace no es un enlace físico sino conceptual
• Un punto típicamente va a estar conectado a < 10 vecinos en su red
sobrepuesta 82

82
Query
Query hit
Punto B Punto C

IInundación
d ió ded Query
Query
preguntas (Query Punto A Punto D Punto E
flooding):
g)
Gnutella
Punto F
Query – Mensaje de pregunta
Punto A busca un archivo Query hit – Resultado positivo
1. Punto A envía un query a todos los puntos vecinos.
2. Si un punto vecino no tiene el archivo, envía la query a todos sus puntos vecinos
3. Si un punto tiene el archivo en un mensaje query hit.
4. El punto A selecciona un punto , Punto C, para recuperar el archivo (HTTP GET)
5. Se hace una conexión directa TCP con el punto seleccionado, Punto C.
6. HTTP responde enviando el archivo.

Query Flooding (Inundación de preguntas)


z Gnutella modifica la inundación de mensajes
mensajes, es decir
decir, envía solo a una
cantidad limitada de puntos el query, usualmente 7 a 10 (similar al TTL, mas
adelante) reduciendo la cantidad de trafico significativo en internet.
83

83
Query
Query hit
Punto B Punto C

Query
Inundación de Query
preguntas (Query Punto A Punto D Punto E
flooding):
Gnutella
Punto F
Query – Mensaje de pregunta
Como se une y deja j un punto
p la red Gnutella Query hit – Resultado positivo
1. Encontrando puntos:
Bootstrap program: El el cliente mantiene una lista de direcciones IP de los
puntos que usualmente estan activo
G t ll usa lista
Gnutella: li t de
d pares candidatos
did t
2. Los clientes intentan hacer contactos con los pares (Conexión TCP mas adelante)
3. El cliente Gnutella envía un mensaje ping a su par (punto).
Gnutella envía mensajes ping a otros puntos, quienes a su vez reenvían los
mensajes ping a los otros puntos.
4. Cada punto responde con un mensaje Gnutella pong, incluyendo:
Su dirección IP
Numero de archivos que comparte
Tamaño Total de los archivos
84

84
P2P - Combinación

Kazaa

z Kazaa combina ideas de Napster y Gnutella


z Protocolo propietario
z Cada nodo es un líder de grupo o asignado a un líder de grupo
– Conexión TCP entre nodo y líder de g
grupo
p
– Conexiones TCP entre pares de lideres de grupo
z Líder de grupo sabe los contenidos (archivos) de todos sus hijos 85

85
P2P - Combinación
Group
Leader
Group
Leader

Group
Leader

KaZaA: Búsquedas
z Cada archivo tiene un hash y un descriptor (incluye el nombre del archivo y descripción
en texto del objeto)
z Cliente manda una pregunta usando palabras claves a su líder de grupo (él busca en el
descriptor)
z Líder de grupo responde con aciertos:
Para cada acierto: metadatos, hash, direccion IP
z Si un líder de grupo reenvía la búsqueda a otros lideres de grupo, esos lideres contestan
con aciertos (usando ruta inversa red sobrepuesta)
z Cliente selecciona archivos para bajar
Mensajes HTTP usando hash como identificador son mandados a pares que 86
contienen archivo deseado

86
P2P - Combinación
Group
Leader
Group
Leader

Group
Leader

Trucos KaZaA
z Limitación para subidas (uploads) (y downloads?) simultaneas
z Encolamiento de peticiones
z Prioridades basadas en incentivos a mejores usuarios (los que suben más archivos
a la red)
z Bajada de datos para un archivo en paralelo (puede usar múltiples conexiones HTTP
a diferentes pares para el mismo archivo)

87

87
Fin

Gracias!!!!!

88

88