Está en la página 1de 45

Dr.

Aldo Rubiales
Este material está basado en:
• El material preparado como apoyo al texto Computer
Networking: A Top Down Approach Featuring the Internet,
5rd edition. Jim Kurose, Keith Ross, Addison-Wesley, 2009.
 E-mail  Telefonía Internet (VoIP)
 Web (Skype)
 Mensajería instantánea  Conferencias de video
en tiempo real
 Login remoto
 Computación paralela
 Compartición de
masiva.
archivos P2P
 Juegos de red multi-
usuarios
 Reproducción de video
almacenados (YouTube,
Netflix)
 Aplicaciones de red
 Corren en diferentes network
data link
sistemas y se comunican physical

por la red.
 Ej. Web: Programa del
servidor Web se comunica
con el programa del
navegador
No se refiere a software
escrito para los
dispositivos en la red
interna
 Dispositivos internos de la
red (routers, switches) no
funcionan en la capa
aplicación
 Este diseño permite
desarrollos rápidos
Arquitecturas de Aplicación
 Cliente-servidor
 Peer-to-peer (P2P)
 Híbridos de cliente-servidor y P2P
Arquitectura Cliente-servidor
Servidor:
 Computador siempre on
 Dirección IP permanente
 Cluster de servidores por
escalamiento
Cliente:
 Se comunica con servidor
 Puede conectarse
intermitentemente
 Puede tener direcciones IP
dinámicas (no estática)
 No se comunican
directamente entre sí (dos
clientes puros)

Escalabilidad: es la habilidad de extender la operación


(más clientes) sin perder calidad. Ej. Radio
Arquitectura P2P Pura
 No hay servidor siempre on
 Sistemas terminales
arbitrarios se comunican
directamente
 Pares se conectan
intermitentemente y cambian
sus direcciones IP
 Ejemplo: Gnutella

Altamente escalable
Pero difícil de administrar
Napster
 Búsqueda de archivos centralizada:
• Pares registran contenidos en servidor central
• Pares consultan algún servidor central para localizar el contenido
 Transferencia de archivos P2P
Mensajería Instantánea
 Diálogo entre los usuarios es P2P (no pasa por servidor)
 Detección/localización de presencia es centralizada:
• Usuario registra su dirección IP en un servidor central cuando
ingresa al sistema
• Usuarios contactan servidor central para encontrar las direcciones
IP de sus amigos.
Procesos que se comunican
Proceso: es un programa
corriendo en un Definiciones
computador. Proceso Cliente: proceso
 Dentro de la máquina que inicia la
dos procesos se comunicación
comunican usando Proceso servidor:
comunicación entre proceso que espera ser
procesos (definida por contactado
Sistema Operativo).
 Procesos en diferentes  Nota: En aplicaciones
hosts se comunican vía con arquitectura P2P un
intercambio de mismo proceso actúa
mensajes como cliente y servidor
Similar a (Python):
Sockets f = open('workfile', 'w')
 Un proceso envía/recibe
mensajes a/desde su
socket
 socket es un punto de
comunicación entre dos
partes (análogo a una puerta)
 Proceso transmisor envía
mensajes por un socket
 Proceso transmisor confía
en la infraestructura de
transporte al otro lado de
la puerta, la cual lleva los
mensajes al socket en el
proceso receptor

 API: Interfaz de Programación de Aplicaciones


Los lenguajes ofrecen mecanismos para comunicarse
con el sistema operativo y la capa de transporte.
Direccionamiento de procesos
 Para que un proceso reciba
 El identificador de
un mensaje, éste debe tener proceso incluye la
una forma para identificarlo dirección IP y un número
(diferenciarlo) de puerto (port)
 Un terminal/host tiene al asociado con el proceso
menos una dirección IP única en el host.
de 32 bits. Este número es positivo y
 Q: ¿Es suficiente la de 16 bits.
dirección IP para identificar  Ejemplo de número de
un proceso en un host? puerto (port number):
 Respuesta: No, muchos  Servidor HTTP(web): 80
procesos pueden estar  Servidor de Mail: 25
corriendo en el mismo host
 En Linux y Windows netstat (Network
Statistic):
 netstat -t para ver conexiones TCP
 netstat -u para ver conexiones UDP

 Hasta aquí sabemos:


 Relación entre aplicación y proceso
 Necesidad de los puertos
 Mecanismo de software usado para pedir
servicios a capa transporte
 Ahora estudiaremos algunos protocolos.
 Tipos de mensajes  Protocolos de dominio
intercambiados, e.g., público:
mensajes de requerimiento y  Definidos en RFCs
respuesta
 Permite inter- operatividad
 Sintaxis de los mensajes: los
 Ej: HTTP (WEB), SMTP (email)
campos en los mensajes &
cómo éstos son delimitados.
 Semántica de los campos, Protocolos propietarios:
i.e, significado de la  Secreto industrial de una
información en los campos empresa
 Reglas para cuándo y cómo  Ej: KaZaA,
los procesos envían y  Skype
responden a mensajes
Confiabilidad en la entrega
Tasa de datos (“Bandwidth”)
(Sin pérdida de datos)
 Algunas aplicaciones  algunas aplicaciones
(e.g., transferencia de (e.g., multimedia)
archivos, telnet) requieren requieren cantidad
transferencia 100% mínima de ancho de
confiable banda para ser “efectivas”
 otras (e.g., audio) pueden  otras (“aplicaciones
tolerar pérdida elásticas”) hacen uso del
bandwidth que obtengan
Retardo
 algunas Aplicaciones
(e.g., Telefonía en
internet, juegos
interactivos) requieren
bajo retardo para ser
“efectivas”
Requerimientos de servicios de transporte de
aplicaciones comunes
Tolera
Aplicación Pérdidas? Bandwidth Sensible a Tiempo?

Transf. de archivos no variable no


e-mail no variable no
Documentos Web no variable no
audio/video sí audio: 5kbps-1Mbps si, 100’s mseg
en tiempo real video:10kbps-5Mbps
audio/video alm sí Igual al de arriba si, few segs
Juegos interactivos sí Algunos kbps si, 100’s mseg
Mensajería inst. no variable Si y no
 Servicio TCP  Servicio UDP
(Transmission Control Protocol): (User Datagram Protocol):
 Es Orientado a la conexión  Transferencia de datos no
establecer conexión (setup) confiable entre proceso Tx y
requerido entre procesos Rx.
cliente y servidor antes de  No provee: establecimiento
transferencia conexión, confiabilidad,
 Ofrece Transporte confiable control de flujo, control de
entre proceso Transmisor congestión, garantías de
(Tx) y Receptor (Rx) retardo o ancho de banda
 Tiene Control de flujo: Tx no
sobrecargará al Rx Q: ¿Por qué existe UDP?
 Tiene Control de congestión:
el Tx se frena cuando la red
está sobrecargada
 No provee: garantías de
retardo ni ancho de banda
mínimos
Aplicaciones Internet: aplicación, protocolo de
transporte
Protocolo de
Protocolo capa transporte que lo
Aplicación aplicación sustenta

e-mail SMTP [RFC 2821] TCP


remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia propietario TCP o UDP
(ej. RealNetworks)
Internet telephony propietario
(ej, Skype) typicamente UDP
Web y HTTP
 Una página Web está compuesta de objetos
 En este contexto objetos pueden ser archivos HTML,
imágenes (JPEG, GIF,...), archivos de audio, archivos
de vídeo,…
 Páginas Web consisten generalmente de un archivo
HTML base el cual incluye referencias a objetos.
 Cada objeto es direccionable por un Universal
Resource Locator (URL)
 Ejemplo URL:
http://www.elo.utfsm.cl/imgmenu/header.jpg
http://www.elo.utfsm.cl:80/imgmenu/header.jpg

Nombre de la máquina y puerto Nombre de camino (path name)


 HTTP: hypertext transfer
protocol
 Es un protocolo de la capa
aplicación usado por la Web
 Usa modelo cliente/servidor
PC running
 cliente: browser primero Explorer
requiere y luego recibe y
“despliega” objetos Web
 servidor: Servidor Web envía
objetos en respuesta a Server
requerimientos running
 HTTP 1.0: RFC 1945 (1996) Apache Web
server
 HTTP 1.1: RFC 2068 (1997)
 HTTP 1.1 Mejorado RFC 2616
Mac running
(1999) Navigator
HTTP generalidades (cont.)
Usa TCP: HTTP no guarda “estado”
1) Cliente inicia conexión TCP  El servidor no mantiene
(crea socket) al servidor, información sobre los
puerto 80 (puede ser otro!) requerimientos del clientes
2) Servidor acepta conexión
TCP del cliente
3) Mensajes HTTP (mensajes Protocolos que mantienen
del protocolo de capa “estado” son complejos!,
aplicación) son ¿Por qué?
intercambiados entre browser  Historia pasada (estado)
(cliente HTTP) y servidor Web
(servidor HTTP) debe ser mantenida
4) Se cierra la conexión TCP  Si servidor o cliente se cae,
las vistas del estado pueden
ser inconsistentes, y deben
ser sincronizadas
 HTTP No-persistente  HTTP Persistente
 A lo más un objeto es  Múltiples objetos pueden
enviado por una ser enviados por una
conexión TCP. única conexión TCP entre
Es como hacer una el cliente y servidor.
llamada por objeto.  HTTP/1.1 usa conexiones
 HTTP/1.0 usa HTTP persistentes a menos que
se indique lo contrario
no-persistente
(defaut)
HTTP request

PC running HTTP response


Server
Navegador running
Apache Web
server
Request y response por la
misma conexión
HTTP no-persistente
(contiene texto, y
Supongamos que el usuario ingresa URL referencias a 10
www.algunaEscuela.edu/algunDepto/home/index imágenes jpeg )

1a. Cliente HTTP inicia una conexión


TCP al servidor HTTP (proceso) en
www.someSchool.edu en puerto 80 1b. Servidor HTTP en host
www.someSchool.edu
esperando por conexiones TCP
en puerto 80 “acepta”
conexión, notifica al cliente
2. Cliente HTTP envía mensaje de
requerimiento (conteniendo el
URL) por el socket de la 3. El servidor HTTP recibe el
conexión TCP. El mensaje indica mensaje de requerimiento,
que el cliente quiere el objeto forma el mensaje de respuesta
someDepartment/home/index que contiene el objeto
requerido y envía el mensaje
por su socket.
tiempo
HTTP no-persistente (cont.)
4. Servidor HTTP cierra la
conexión.
5. Cliente HTTP recibe el mensaje
respuesta que contiene el
archivo html y despliega el html.
Analizando el archivo html file,
encuentra 10 referencias a
objetos jpeg

tiempo 6. Pasos 1-5 son repetidos para


cada uno de los 10 objetos
jpeg.
 Definición de RTT(round-
trip time): tiempo ocupado
desde el envío un paquete
pequeño desde el cliente al
servidor y hasta su
regreso. initiate TCP
 Tiempo de respuesta:
connection
RTT
 Un RTT para iniciar la
conexión request
file
 Un RTT por time to
requerimiento HTTP y RTT
transmit
primeros bytes de la file
respuesta file
received
 Tiempo de transmisión
del archivo
time
total = 2RTT + tiempo de
time

transmisión
 Problemas de HTTP no-persistente:
 requiere al menos 2 RTTs por objeto
 el navegador abre conexiones paralelas generalmente para traer
objetos referenciados. => OS debe trabajar y dedicar recursos
para cada conexión TCP

 Persistencia sin pipelining:


 cliente envía nuevo
HTTP Persistente requerimiento sólo cuando
el previo ha sido recibido
 servidor deja las conexiones
abiertas después de enviar la  un RTT por cada objeto
respuesta referenciado
 mensajes HTTP siguientes Persistencia con pipelining:
entre los mismos  default en HTTP/1.1
cliente/servidor son enviados  cliente envía
por la conexión requerimientos tan pronto
éste encuentra un objeto
referenciado
 tan poco como un RTT para
todas las referencias
initiate TCP
connection

Request file

time to En todos estos


transmit diagramas
File received file .html
Initiate another
suponemos que los
TCP connection objetos caben en
Estas Request file un segmento
conexiones time to
(=paquete) TCP.
podrían ser transmit
file
paralelas. File received
time time
initiate TCP initiate TCP
connection connection

Request file Request file


time to time to
transmit transmit
File received file File received file
Request file Request file
time to Request file time to
transmit transmit
file file
File received File received
Request file File received
time to
transmit time time
file
File received Con Pipeline
time
Sin Pipeline time
 Dos tipos de mensajes HTTP: requerimiento y
respuesta
 Mensaje de requerimiento HTTP:
 ASCII (es decir, formato legible)
Línea de requerimiento (request
line) (métodos GET, POST, HEAD,
PUT, Delete) GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
User-agent: Mozilla/4.0
Líneas de
Connection: close
encabezado
Accept-language:fr

Carriage return, (carriage return, line feed extra)


line feed
Indica fin de mensaje
Mensaje HTTP de requerimiento:
formato general
 Vía Método Post:
 Páginas Webs  Vía Método GET:
usualmente incluyen
 Entrada es subida en
entradas de formularios
campos URL de la línea
 Los datos son subidos de requerimiento:
al servidor en el cuerpo
del mensaje

www.somesite.com/animalsearch?monkeys&banana
 HTTP/1.0  HTTP/1.1
 GET  GET, POST, HEAD
 PUT
 POST
 Sube archivos en cuerpo
 HEAD del requerimiento en
 Pideal servidor que localización indicada por
el campo URL
deje el objeto
requerido afuera de  DELETE
 Borra archivo
la respuesta.
especificado en el campo
Respuesta incluye URL
sólo el encabezado.
Mensajes HTTP de respuesta
Línea de estatus
(código de estatus
del protocolo HTTP/1.1 200 OK
Frase de estatus) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Líneas de Last-Modified: Mon, 22 Jun 1998 …...
encabezado Content-Length: 6821
Content-Type: text/html

data, e.g., data data data data data ...


archivo
HTML solicitado
En primera línea de respuesta del servidor al cliente.
Algunos códigos de muestra:
 200 OK
 request exitoso, objeto requerido es incluido luego en
mensaje
301 Moved Permanently
 Se movió el objeto requerido, nueva ubicación es
especificada luego en el mensaje (Location:)
400 Bad Request
 Requerimiento no entendido por el servidor
404 Not Found
 Documento no encontrado en servidor
505 HTTP Version Not Supported
Probando HTTP (lado cliente)
1. Telnet a tu servidor favorito:
Telnet abre una conexión TCP
al puerto 80 (puerto servidor HTTP por
telnet profesores.elo.utfsm.cl 80 omisión) en mateo.elo.utfsm.cl.
Cualquier cosa ingresada es enviada
a puerto 80 de mateo

2. Escribir un requerimiento GET HTTP:


GET /~agv/elo322/HTTP/prueba.html HTTP/1.1
Host: profesores.elo.utfsm.cl
Tipeando esto (doble carriage
NOTA: Campo Host es obligatorio return), enviamos un GET request
en encabezado, requerido por proxy. mínimo (pero completo) al servido
HTTP

3. Observar el mensaje de respuesta enviado por el


servidor HTTP!
Ver ejemplo en Wireshark
 Muchos sitios Web importantes usan cookies
 Las cookies fueron implementadas para permitir
personalizar la información Web.
 Cookies es información generada por un Web server
y almacenada en el computador del usuario para
acceso futuro.
 Las cookies son trasportadas entre el computador
del usuario y el servidor.
 Por ejemplo, cookies son usadas para almacenar
ítems en un carro de compra mientras recorres un
mall virtual.
 Cuatro Componentes:  Ejemplo:
 1) Línea encabezado cookie  Susan accede Internet
en el mensaje respuesta siempre desde el mismo PC
HTTP  Ella visita un sitio e-
 2) Línea de encabezado commerce específico por
cookie en requerimiento primera vez.
HTTP  Cuando el requerimiento
 3) Archivo cookie es HTTP inicial llega al sitio,
almacenado en la máquina éste crea un ID único y lo
guarda en la base de datos
del usuario y administrada para ese ID.
por su navegador.
 En mensaje respuesta va
 4) Base de datos en sitio información del sitio e ID
Web (cookie)
 El navegador de Susan
almacena la cookie en
disco.
 En nuevo acceso al sitio, el
navegador incluye ID. Así
ese sitio sabrá que el
mismo usuario reaparece.
Cookies: conservando el “estado” (cont.)
cliente servidor
Cookie file
Requerimiento http Servidor crea amazon
Ebay: 8734
ID 1678
Respuesta http + para usuario
Set-cookie: 1678
Cookie file
Ebay: 8734
requerimiento http
Amazon: 1678
cookie: 1678 Acción
específica
respuesta http usual de la cookie
Una semana más:
requerimiento http
cookie: 1678 Acción
Cookie file
específica
Ebay: 8734
respuesta http usual de la cookie
Amazon: 1678
Cookies (cont.)
Cookies y privacidad:
Qué pueden transportar  Cookies permiten que el
las cookies: sitio aprenda mucho sobre
 Autorización uno.
 Shopping carts  Podríamos proveer nombre
 Sugerencias y correo al sitio.
 Estado de la sesión del  Motores de búsqueda usan
usuario (Web e-mail) redirecciones y cookies
para aprender aún más
 Compañías de avisos
obtienen información de
los sitios WEB
Web caches (también servidores proxy)
Objetivo: satisfacer el requerimiento del cliente sin
involucrar al servidor destino.

 Usuario configura el Servidor


browser: Acceso Web vía WEB
cache
Servidor
 Browser envía todos los Proxy
requerimientos HTTP al cliente
cache
 Si objeto está en cache:
cache retorna objeto
 Si no, cache requiere los
objetos desde el servidor
Web, los almacena y
retorna el objeto al
cliente. cliente
Servidor
Web
 La idea del cache es almacenar “localmente” datos ya
solicitados y así poder acceder a éstos más rápidamente
en el futuro.
 Un problema que debe atender el cache es la
obsolescencia que puede tener los datos locales.
 El cache puede usar tiempos de expiración, o consultar
a la fuente por vigencia del dato local.

 Un proxy es un servicio que consiste en realizar una


solicitud a pedido de otro.
 ¿Les ha pasado que para algunas cosas ustedes desean
pedir a otro enviar un mensaje por ustedes?
 Por ejemplo podemos usar proxy para acceder a servicios
externos de una intranet, para que desde fuera no se sepa
qué computadores hay dentro. El origen es siempre el
mismo.
 Cache actúa como Porqué Web caching?
cliente y servidor  Reduce tiempo de
respuesta a las peticiones
 Típicamente el del cliente.
cache es instalado  Reduce tráfico en el
por ISP (universidad, enlace de acceso al ISP.
compañía, ISP  Internet densa con caches
residencial) permite a proveedores de
contenido “chicos” (no $$)
entregar contenido en
forma efectiva.
Ejemplo de Cache
Suposiciones Servidores
 Tamaño promedio de objetos = web
1000.000 bits
 Tasa de requerimientos promedio Internet
desde browsers de la institución al pública
servidor WEB = 15/sec
 Retardo desde el router
institucional a cualquier servidor
web y su retorno = 2 sec 15 Mbps
Consecuencias Enlace se acceso
 utilización de la LAN = 15%
Red
 utilización del enlace de acceso = institucional
100% 100 Mbps LAN
 Retardo total = retardo Internet +
retardo de acceso + retardo LAN
= 2 sec + segundos + milisegundos
Sin Cache
institucional
Ejemplo de Cache (cont)
Servidores
Posible solución web
 Aumentar ancho de banda del
enlace a, por ejemplo, 45 Mbps Internet
pública
Consecuencias
 Utilización de la LAN = 15%
 Utilización del enlace de
acceso = 33% 45 Mbps
Enlace se acceso
 Retardo Total = Retardo
Internet + retardo de acceso + Red
institucional
retardo LAN 100 Mbps LAN
= 2 sec + msecs + msecs
 A menudo un upgrade caro.
Sin cache
institucional
Ejemplo de cache (cont)
Instalar un web Cache Servidores
 Supongamos tasa de éxito1 (acierto) Web
de 0.4
Consecuencias Internet
pública
 40% de los requerimientos serán
satisfechos en forma casi inmediata
(~10 msec) + consulta por
obsolescencia
 60% de los requerimientos
satisfechos por el servidor WEB Enlace de acceso
 Utilización del enlace de acceso es
reducido al 60%, resultando en Red
retardo bajo (digamos 10 msec) institucional
 Retardo total = Retardo Internet + 100 Mbps LAN
retardo acceso + retardo LAN =
0.6*(2.01) sec + 0.4*0.01 < 1.3 sec
40% Se debe agregar tiempo para
Cache
confirmar que dato en cache es vigente. institucional
1Tasa de éxito: Fracción de los requerimientos satisfechos por el cache.
Get Condicional
cache servidor
 Objetivo: verificar que el
cache tiene la versión HTTP request msg
actualizada de un objeto If-modified-since:
<date> object
 Cache: especifica la no
fecha de la copia en el modificado
requerimiento HTTP HTTP response
HTTP/1.0
If-modified-since: 304 Not Modified
<date>
 Servidor: responde sin el
objeto si la copia de la HTTP request msg
cache es la última. : If-modified-since:
HTTP/1.0 304 Not <date> object
Modified modificado
HTTP response
HTTP/1.0 200 OK
<data>