15/03/2024

FUNDAMENTOS DE REDES DE DATOS

UNIVERSIDAD NACIONAL DEL SUR
Andres Llinas

LO VISTO HASTA AHORA (UNIDAD 1)

¿Que es Internet? Historia
Red Periférica y Red Central
Red de acceso y medio físico
Estructura de Internet e ISP
Capas de Protocolos, Modelos de servicio

1
 15/03/2024

ALGUNAS APLICACIONES DE RED

E-mail Telefonía Internet
Web Conferencias de video en tiempo real
Mensajería instantánea Computación paralela masiva.
Login remoto ……
Compartición de archivos P2P …….
Juegos de red multiusuarios
Reproducción de clips de video
almacenados

CREACIÓN DE UNA APLICACIÓN DE RED application

transport
network
data link
physical

Escribe un programa que

 Corra en diferentes sistemas y
 Se comunique por la red.
 e.g., Web: Programa del servidor Web se
comunica con el programa del navegador
No se refiere al software escrito para los application
transport
dispositivos en la red interna network
data link application
transport
 Dispositivos internos de la red (routers, switch) no
physical
network
data link
physical
funcionan en la capa aplicación
 Este diseño permite desarrollos rápidos

2
 15/03/2024

QUE SON LAS RFC (REQUEST FOR COMENTE)

UNIDAD 2: LA CAPA DE APLICACIÓN

Principios de las aplicaciones de red
World Whide Web Protocolo HTTP
SSL TSL Protocolo HTTPS
Correo Electrónico Protocolo POP3 SMTP IMAP
DNS

3
 15/03/2024

PRINCIPIOS DE LAS APLICACIONES DE RED

Híbridos de cliente-servidor y P2P

7

ARQUITECTURA CLIENTE-SERVIDOR
servidor:
 Computador siempre on
 Dirección IP permanente
 Granja de servidores por escalamiento
cliente:
client/server  Se comunica con servidor
 Puede ser conectado intermitentemente
 Puede tener direcciones IP dinámicas
 No se comunican directamente entre sí
(dos clientes puros)

4
 15/03/2024

ARQUITECTURA P2P PURA peer-peer

 No hay servidor siempre on

 Sistemas terminales arbitrarios se
comunican directamente
 Pares se conectan
intermitentemente y cambias sus
direcciones IP
 ejemplo: Gnutella
Altamente escalable
Pero difícil de administrar

HÍBRIDOS DE CLIENTE-SERVIDOR Y P2P

Mensajería Instantánea Napster
 Diálogo es entre los
 Transferencia de archivos
usuarios es P2P
 Detección/localización de P2P
presencia es centralizada:  Búsqueda de archivos
 Usuario registra su centralizada:
dirección IP en un  Pares registran
servidor central cuando contenidos en servidor
ingresa al sistema
central
 Usuarios contactan
servidor central para  Pares consultan algún
encontrar las servidor central para
direcciones IP de sus localizar el contenido
amigos.
10

5
 15/03/2024

PROCESOS QUE SE COMUNICAN

Proceso: programa que Proceso Cliente: proceso
corre en un computador. que inicia la comunicación
 dentro de la máquina Proceso servidor: proceso
dos procesos se que espera a ser
comunican usando contactado
comunicación entre
procesos (definida por
Sistema Operativo).
 Nota: Aplicaciones con
 procesos en diferentes
arquitectura P2P tienen
hosts se comunican vía
procesos clientes y
intercambio de
procesos servidores
mensajes
11

SOCKETS O PUERTOS
 Un proceso envía/recibe mensajes a/desde su socket
 socket es análogo a una puerta
 Proceso transmisor saca mensajes por la puerta
 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: (1) debemos elegir el protocolo de transporte; (2) podemos definir algunos
parámetros (volveremos más adelante)
application application
socket controlled by
process process app developer

transport transport

network network controlled

link by OS
link Internet
physical physical

12

6
 15/03/2024

DIRECCIONAMIENTO DE PROCESOS
 Para que un proceso reciba un mensaje, éste debe tener un
identificador
 Un terminal/host tiene una dirección IP única de 32 bits.
 Q: ¿Es suficiente la dirección IP para identificar un proceso en un host?
 Respuesta: No, muchos procesos pueden estar corriendo en el mismo
host.
 El identificador incluye la dirección IP y un número de puerto (port)
asociado con el proceso en el host.
 Ejemplo de números de puerto (port number):
 Servidor HTTP: 80
 Servidor de Mail: 25

13

PROTOCOLOS DE CAPA APLICACIÓN DEFINEN

 Tipos de mensajes intercambiados, e.g., mensajes de requerimiento y
respuesta
 Sintaxis de los tipos de mensajes: los campos en los mensajes & cómo
éstos son delimitados.
 Semántica de los campos, i.e, significado de la información en los campos
 Reglas para cuándo y cómo los procesos envían y responden a mensajes
Protocolos de dominio público:
 Definidos en RFCs
 Permite interoperatividad
 eg, HTTP, SMTP
Protocolos propietarios:
 eg, Skype
14

7
 15/03/2024

¿QUÉ SERVICIOS DE TRANSPORTE NECESITA UNA

APLICACIÓN?
Pérdida de datos
 algunas aplicaciones (e.g., audio) pueden tolerar pérdida
 otras (e.g., transferencia de archivos, telnet) requieren transferencia 100%
confiable
Retardo
 algunas Aplicaciones (e.g., Telefonía en internet, juegos interactivos)
requieren bajo retardo para ser “efectivas”
Ancho banda (Bandwidth)
 algunas aplicaciones (e.g., multimedia) requieren cantidad mínima de ancho
de banda para ser “efectivas”
 otras (“aplicaciones elásticas”) hacen uso del bandwidth que obtengan
15

REQUERIMIENTOS DE SERVICIOS DE TRANSPORTE

DE APLICACIONES COMUNES

16

8
 15/03/2024

SERVICIOS DE LOS PROTOCOLOS DE TRANSPORTE

EN INTERNET
Servicio TCP: Servicio UDP:
 Orientado a la conexión establecer conexión  Transferencia de datos no confiable entre
(setup) requerido entre procesos cliente y proceso Tx y Rx.
servidor antes de transferencia  No provee:
 Transporte confiable entre proceso Transmisorestablecimiento
(Tx) y Receptor (Rx) coneccion, confiabilidad,
 Control de flujo: Tx no sobrecargará al Rx control de flujo, control
 Control de congestión: frena al Tx cuando la de congestión, garantías
red está sobrecargada de retardo o ancho de banda
 No provee: garantías de retardo ni ancho de Q: ¿Por qué existe UDP?
banda mínimos

17

APLICACIONES INTERNET: APLICACIÓN,

PROTOCOLO DE TRANSPORTE

18

9
 15/03/2024

RESUMEN
Modelo Cliente servidor
Modelo P2P
Modelos Híbridos
Procesos que se comunican (sockets o puertos)
Protocolos de la capa de aplicación
Servicios de transporte a la capa de aplicación

19

PREGUNTAS SOBRE LO VISTO HASTA AHORA

20

10
 15/03/2024

UNIDAD 2: LA CAPA DE APLICACIÓN

Principios de las aplicaciones de red
World Whide Web Protocolo HTTP
SSL TSL Protocolo HTTPS
Correo Electrónico Protocolo POP3 SMTP IMAP
DNS

21

Una página Web

Objetos pueden ser
consiste de objetos
WEB Y HTTP archivos HTML, imágenes
(JPEG, GIF,...), Java applets,
Páginas Web consisten de archivos de audio, archivos
un archivo HTML base el de video,…
cual incluye referencias a
objetos Cada objeto es direccionable
por un Universal
Resource Locator (URL)

Ejemplo URL:
[Link]/ingreso

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

22

11
 15/03/2024

HTTP GENERALIDADES
HTTP: hypertext transfer protocol
 Protocolo de la capa aplicación de la
Web
 Modelo cliente/servidor
 cliente: browser que requiere,
recibe, “despliega” objetos Web server
running
 servidor: Servidor Web envía Apache Web
server
objetos en respuesta a
requerimientos iPhone running
 HTTP 1.0: RFC 1945 Safari browser

 HTTP 1.1: RFC 2068

23

HTTP GENERALIDADES Usa TCP:

HTTP no tiene “estado”  cliente inicia conexión TCP

(crea socket) al servidor,
 El servidor no puerto 80
mantiene  Servidor acepta conexión
información sobre TCP del cliente
los requerimientos  Mensajes HTTP (mensajes
del clientes del protocolo de capa
aplicación) son
intercambiados entre
browser (cliente HTTP) y
servidor Web (servidor
Protocolos que mantiene “estado” son HTTP)
complejos!  Se cierra la conexión TCP

24

12
 15/03/2024

CONEXIONES HTTP
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
 HTTP/1.0 usa HTTP no- el cliente y servidor.
persistente  HTTP/1.1 usa conexiones
persistentes en su modo
por defecto

25

HTTP NO-PERSISTENTE
(contiene texto,
Supongamos que el usuario ingresa la URL: referencias a 10
[Link]/someDepartment/[Link]
imágenes jpeg)
1a. Cliente HTTP inicia una conexión
TCP al servidor HTTP (proceso) en 1b. Servidor HTTP en host
[Link] en puerto 80 [Link] esperando por
conexiones TCP en puerto 80
“acepta” conexión, notifica la cliente
2. Cliente HTTP envía mensaje de
requerimiento (conteniendo el
URL) por el socket de la conexión
TCP. EL mensaje indica que el 3. El servidor HTTP recibe el
cliente quiere el objeto mensaje de requerimiento,
someDepartment/home/index forma el mensaje de
tiempo respuesta que contiene el
objeto requerido y envía el
mensaje por su socket.

26

13
 15/03/2024

HTTP NO-PERSISTENTE
4. El 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
time
6. Pasos 1-5 son repetidos para cada
uno de los 10 objetos jpeg.

27

MODELO PARA TIEMPO DE RESPUESTA

Definición de RTT: tiempo ocupado en
enviar un paquete pequeño desde el
initiate TCP
cliente al servidor y su regreso. connection

Tiempo de respuesta: RTT

request
 Un RTT para iniciar la conexión file
time to
 Un RTT por requerimiento HTTP y RTT transmit
file
primeros bytes de la respuesta file
received

r Tiempo de transmisión del archivo time time

total = 2RTT + tiempo de transmisión

28

14
 15/03/2024

HTTP PERSISTENTE
Problemas de HTTP no-persistente: Persistencia sin pipelining:
 requiere 2 RTTs por objeto  cliente envía nuevo
 OS debe trabajar y dedicar requerimiento sólo cuando el
recursos para cada conexión TCP previo ha sido recibido
 el navegador abre conexiones  un RTT por cada objeto
paralelas generalmente para referenciado
traer objetos referenciados. Persistencia con pipelining:
HTTP Persistente  default en HTTP/1.1
 servidor deja las conexiones  cliente envia requerimientos
abiertas despues de enviar la tan pronto éste encuentra un
respuesta objeto referenciado r tan
 mensajes HTTP subsecuentes entre poco como un RTT para
los mimos cliente/servidor son todas las referencias
enviados por la conexión
29

MENSAJE HTTP DE REQUERIMIENTO

Dos tipos de mensajes HTTP: requerimiento, respuesta
Mensaje de requerimiento HTTP:
 ASCII (formato legible)
Linea de requerimiento
(Comando GET, POST,
HEAD) GET /[Link] HTTP/1.1\r\n
Host: [Link]\r\n
User-Agent: Firefox/3.6.10\r\n
Lineas de Accept: text/html,application/xhtml+xml\r\n
encabezado Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
carriage return, line feed Connection: keep-alive\r\n
\r\n
Indica fin de mensaje

30

15
 15/03/2024

MENSAJE HTTP DE REQUERIMIENTO:

FORMATO GENERAL
method sp URL sp version cr lf request
line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

31

SUBIENDO INPUT DE FORMULARIO

Método Post:
 Páginas Webs usualmente incluyen
Métodos URL:
input de formulario
 Usa método GET
 Input es subido al servidor en el
 Entrada es subida en campos URL de la línea
cuerpo del mensaje
de requerimiento:

[Link]/animalsearch?monkeys&banana

32

16
 15/03/2024

TIPOS DE MÉTODOS
HTTP/1.0 HTTP/1.1
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  Sube archivos en cuerpo del
 Pide al servidor que deje el requerimiento en localización indicada
objeto requerido afuera de la por el campo URL
respuesta.  DELETE
 Borra archivo especificado en el campo
URL

33

MENSAJES HTTP DE RESPUESTA

Línea de estatus
(código de estatus
del protocolo Frase HTTP/1.1 200 OK\r\n
de estatus) Date: Sun, 26 Sep 2010 [Link] GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 [Link]
GMT\r\n
Líneas de ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
encabezado Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n
\r\n
data, e.g., data data data data data ...
archivo
HTML solicitado

34

17
 15/03/2024

CÓDIGOS HTTP DE RESPUESTA

En primera línea de respuesta del servidor-> 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 hubicació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

35

QUE SON LAS COOKIES

36

18
 15/03/2024

ESTADO USUARIO-SERVIDOR: COOKIES

Muchos sitios Web importantes usan cookies Ejemplo:
Cuatro componentes:  Susan accede Internet siempre desde el
1. Línea encabezado cookie en el mensaje mismo PC
respuesta HTTP  Ella visita un sitio ecommerce específico
2. Línea de encabezado cookie en por primera vez.
requerimiento HTTP  Cuando el requerimiento HTTP inicial
3. Archivo cookie es almacenado en la llega al sitio, éste crea un ID único y crea
máquina del usuario y administrada por una entrada en la base de datos para
su navegador ese ID.
4. Base de datos en sitio Web

37

COOKIES: CONSERVANDO EL “ESTADO”

client server
ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action

38

19
 15/03/2024

Al margen
COOKIES
Cookies y privacidad:
 Cookies permiten que el sitio
Qué pueden transportar las
aprenda mucho sobre uno.
cookies:
 Podríamos proveer nombre y
 autorización
correo al sitio.
 shopping carts
 Motores de búsqueda usan
 sugerencias
redirecciones y cookies para
 Estado de la sesión del
aprender aún más
usuario (Web e-mail)
 Compañías de avisos obtienen
información de los sitios WEB

39

WEB CACHES (TAMBIÉN SERVIDORES PROXY)

Objetivo: satisfacer el requerimiento del cliente
sin involucrar al servidor destino.
proxy
server
 Usuario configura el browser: Acceso Web client
origin
vía cache server
 browser envía todos los requerimientos HTTP
al cache
 Si objeto está en cache: cache retorna
objeto
client
 Sino cache requiere los objetos desde el origin
server
servidor Web, y retorna el objeto al
cliente

40

20
 15/03/2024

MÁS SOBRE WEB CACHING

Por qué Web caching?
 Cache actúan como clientes y  Reduce tiempo de respuesta de las peticiones
servidores del cliente.
 Típicamente el cache está  Reduce trafico en el enlace de acceso al ISP.
instalado por ISP (universidad,  Internet densa con caches permite a
compañía, ISP residencial) proveedores de contenido “pobres” (no $$)
entregar contenido en forma efectiva.

41

EJEMPLO DE CACHE Servidores

web
Suposiciones
 Tamaño promedio de objetos = 100,000 bits
Internet
 Tasa de requerimientos promedio desde Publica
browsers de la institución al servidor WEB =
15/sec
 Retardo desde el router institucional a 1.5 Mbps
access link
cualquier servidor web y su retorno = 2 sec
Consecuencias Red
Instutucional
 utilización de la LAN = 15% 10 Mbps LAN

 utilización del enlace de acceso = 100%

 Retardo total = retardo Internet + retardo
de acceso + retardo LAN = 2 sec + minutos
+ millisegundos

42

21
 15/03/2024

EJEMPLO DE CACHE
Posible solución: origin
 Aumentar ancho de banda del servers
enlace a, por ejemplo, 10 Mbps public
Internet
Consecuencias:
 Utilización de la LAN = 15%
 Utilización del enlace de 10 Mbps
acceso = 15% access link
 Retardo Total = Retardo institutional
Internet + retardo de acceso + network
10 Mbps LAN
retardo LAN = 2 sec + msecs
+ msecs
 A menudo un upgrade caro.

43

EJEMPLO DE CACHE
Instalar un web Cache origin
servers
 Supongamos tasa de éxito1 (acierto) de 0.4 public
Consecuencias Internet

 40% de los requerimientos serán satisfechos

en forma casi inmediata (~10 msec)
 60% de los requerimientos satisfechos por el 1.5 Mbps
access link
servidor WEB
institutional
 Utilización del enlace de acceso es reducido network
10 Mbps LAN
al 60%, resultando en retardo despreciable
(digamos 10 msec) local web
cache
 Retardo total = Retardo Internet + retardo
acceso + retardo LAN = 0.6*(2.01) sec +
Tasa de éxito: Fracción de los requerimientos
0.4*0.01 < 1.3 sec satisfechos por la cache

44

22
 15/03/2024

servidor
GET CONDICIONAL cliente

HTTP request msg

 Objetivo: no enviar objetos si el cache tiene If-modified-since: <date> objeto
la versión actualizada no
modificado
 Cache: especifica la fecha de la copia en el HTTP response
HTTP/1.0
requerimiento HTTP If-modified-since: 304 Not Modified
<date>
 servidor: responde sin el objeto si la copia de
la cache es la última. : HTTP/1.0 304 Not
HTTP request msg
Modified If-modified-since: <date> objeto
modificado
HTTP response
HTTP/1.0 200 OK
<data>

45

RESUMEN
 WWW y Protocolo HTTP
Formato de los mensajes HTTP
Los distintos tipos métodos post get ...
Como son los mensajes http
Hablamos de las Cookies
Web Cache

46

23
 15/03/2024

PREGUNTAS SOBRE LO VISTO HASTA AHORA

47

UNIDAD 2: LA CAPA DE APLICACIÓN

Principios de las aplicaciones de red
World Whide Web Protocolo HTTP
SSL TSL Protocolo HTTPS
Correo Electrónico Protocolo POP3 SMTP IMAP
DNS

48

24
 15/03/2024

SSL TSL PROTOCOLO HTTPS

49

SEGURIDAD WEB
 HTTP no es un protocolo seguro
Es simple y no se establece un estado cliente/servidor. Ejecuta
sobre TCP/IP
 Es necesario instrumentar medidas de seguridad
 Revisaremos SSL (Secure Socket Layer) y su sucesor TLS
(Transport Layer Security)
 HTTPS
• Protocolo seguro HTTP
 El uso de SSL se aplica también a otras capas TCP/IP, por
ejemplo,
• POP3, SMTP, FTP, SSH, etc.

50

25
 15/03/2024

PROCESO DE HTTPS

51

¿QUÉ ES SSL/TSL
SSL (Secure Sockets Layer) traducido al español significa
Capa de Conexiones Seguras. Es un protocolo que hace
uso de certificados digitales para establecer
comunicaciones seguras a través de Internet. Recientemente
ha sido sustituido por TLS (Transport Layer Security) el cual
está basado en SSL y son totalmente compatibles.
Te permite confiar información personal a sitios web, ya
que tus datos se ocultan a través de métodos criptográficos
mientras navegas en sitios seguros.
Es utilizado ampliamente en bancos, tiendas en línea y
cualquier tipo de servicio que requiera el envío de datos
personales o contraseñas. No todos los sitios web usan SSL,
por eso debes ser cuidadoso.

52

26
 15/03/2024

LLAVE PUBLICA Y LLAVE PRIVADA

Son un par de “llaves” digitales asociadas a una persona o entidad y
generadas mediante métodos criptográficos. La llave pública es usada
para cifrar la información, haciendo una analogía, es como la llave
utilizada para cerrar una puerta y mantener fuera a cualquier
persona mientras que la llave privada se usa para descifrar, es decir,
la llave que abre la puerta y sólo la posee la persona autorizada, por
lo tanto ésta debe mantenerse en secreto.

53

OBJETIVOS DEL PROTOCOLO

1. Negociar algoritmos criptográficos

 Cifradores simétricos
 Método de intercambio de llave
 Función de digestión de mensaje
2. Autentica [opcionalmente] al cliente y al
servidor
3. Establece y comparte un secreto maestro

54

27
 15/03/2024

RESUMEN
Protocolos SSL y TSL

Proceso de https

Lave publica y llave privada

El objetivo de estos protocolos

55

PREGUNTAS SOBRE LO VISTO HASTA AHORA

56

28
 15/03/2024

UNIDAD 2: LA CAPA DE APLICACIÓN

Principios de las aplicaciones de red
World Whide Web Protocolo HTTP
SSL TSL Protocolo HTTPS
Correo Electrónico Protocolo POP3 SMTP IMAP
DNS

57

outgoing
message queue
CORREO ELECTRÓNICO user
user mailbox

agent
Tres mayores componentes:
 Agente usuario mail user
server
 Servidor de correo agent

 Simple Mail Transfer SMTP mail user

 Protocol: SMTP server agent

Agente Usuario SMTP

 r También conocido como “lector de correo” SMTP user
agent
 Escritura, edición, lectura de mensajes de mail
server
correos user
 e.g., Eudora, Outlook, elm, Netscape agent
Messenger user
agent
 Mensajes de salida, entrada son
almacenados en servidor

58

29
 15/03/2024

CORREO ELECTRÓNICO: SERVIDOR DE CORREO

Servidor de Correo user
agent
 casilla contiene mensajes de entrada para el mail user
server agent
usuario
SMTP mail
 Cola (queue) de mensajes de los correos de server

salida SMTP

 SMTP: Protocolo entre servidores de correo SMTP user

agent
mail
server
para enviar mensajes email user
agent
 cliente: servidor que envía el correo
user
agent
 “servidor”: servidor que recibe el correo

59

CORREO ELECTRÓNICO: SMTP [RFC 2821]

 Usa TCP para transferir confiablemente mensajes e-mail desde
el cliente al servidor, puerto 25.
 Transferencia directa: servidor envía correos al servidor
receptor
 Tres fases de la transferencia
 handshaking (apretón de manos, establecer conexión)
 Transferencia de mensajes
 cierre
 Interacción comandos/respuestas
 comandos: Texto ASCII
 respuesta: código de estatus y frase.
 Mensajes deben ser enviados en ASCII de 7-bits

60

30
 15/03/2024

ESCENARIO: ALICIA ENVÍA MENSAJE A BOB

1. Alicia usa agente usuario para componer 4. El cliente SMTP envía el mensaje de
el mensaje para bob@[Link] Alicia por la conexión TCP
2. El agente de Alicia envía en mensaje a 5. EL servidor de correo de Bob pone el
su servidor de correo; el mensaje es mensaje en su casilla
puesto en cola de salida 6. Bob invoca su agente usuario para leer
3. Lado cliente de SMTP abre una conexión el mensaje
TCP con el servidor de correo de Bob

1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server

61

SMTP: PALABRAS FINALES

Comparación con HTTP:
 HTTP: pull (saca contenido desde
 SMTP usa conexiones persistentes servidor)
 SMTP requiere que el mensaje  SMTP: push (pone contenido en
(encabezado y cuerpo) sean en ASCII de servidor)
7-bits  Ambos tienen interacción
 Servidor SMTP usa [Link] para comando/respuesta en ASCII, y tienen
terminar el mensaje códigos de estatus
 HTTP: cada objeto es encapsulado en
su propio mensaje
 SMTP: múltiples objetos son enviados en
un mensaje multiparte

62

31
 15/03/2024

FORMATO DE MENSAJES DE CORREO

SMTP: protocolo para
intercambio de mensajes de
correo
header
RFC 822: estándar para el Línea en
formato de los mensajes: blanco

E.g. líneas de encabezado

 To: body
 From:
 Subject:
different a los commandos SMTP!

Cuerpo: el “mensaje”
 Solo caracteres ASCII

63

PROTOCOLOS DE ACCESO DE CORREO

user
mail access user
SMTP SMTP protocol agent
agent
(e.g., POP,
IMAP)

sender’s mail receiver’s mail

server server
 SMTP: permite envió y almacenamiento de correo en servidor del
destinatario
 Protocolo de acceso a correo: permite extraer correo desde el servidor
 POP: Post Office Protocol [RFC 1939]
• autenticación (agent <-->server) y bajada
 IMAP: Internet Mail Access Protocol [RFC 1730]
• Más características (más complejo)
• Permite manipulación de los mensajes almacenados en el servidor
 HTTP: Hotmail , Yahoo! Mail, etc.
64

32
 15/03/2024

PROTOCOLO POP3 S:
C:
+OK POP3 server ready
user bob
Fase de autorización S: +OK
Comandos del cliente: C: pass hungry
 user: declara username S: +OK user successfully logged on
 pass: password C: list Tamaño del mensaje
Respuesta del servidor S: 1 498
 +OK S: 2 912
 -ERR S: .
C: retr 1
Fase Transaccional, client: S: <message 1 contents>
list: lista números de mensaje S: .
C: dele 1
retr: extrae mensajes por su
número C: retr 2
S: <message 1 contents>
dele: borra S: .
quit C: dele 2
C: quit
S: +OK POP3 server signing off

65

RESUMEN
El mail y sus protocolos

Servidores de correo

Proceso de envio y recepcion

Formato del mensaje

66

33
 15/03/2024

PREGUNTAS SOBRE LO VISTO HASTA AHORA

67

UNIDAD 2: LA CAPA DE APLICACIÓN

Principios de las aplicaciones de red
World Whide Web Protocolo HTTP
SSL TSL Protocolo HTTPS
Correo Electrónico Protocolo POP3 SMTP IMAP
DNS

68

34
 15/03/2024

DNS: DOMAIN NAME SYSTEM

(SISTEMA DE NOMBRES DE DOMINIO)
Domain Name System:
Personas: muchos identificadores:
 Base de datos distribuida implementada en una
 ROL, RUT, name, # pasaporte
jerarquía de muchos servidores de nombres
Host y router en Internet:
 Protocolo de capa aplicación permite a host,
 Dirección IP (32 bit) – usada para
routers, y servidores de nombre comunicarse para
direccionar datagramas (ideal para
resolver nombres (traducción dirección/nombre)
router)
 No está orientado al uso directo de los usuarios.
 “nombre”, e.g., [Link] – son
 nota: función central de la Internet
usados por humanos
implementada como protocolo de capa
aplicación
Q: Quién mapea entre direcciones IP y
 La idea es dejar la complejidad en la
nombres?
“periferia” de la red. Routers no tienen
información de DNS
69

DNS ¿Por qué no centralizar DNS?

Servicios DNS  Único punto de falla
 Traducción de nombre de host a  Volumen de tráfico, muchos
dirección IP necesitan el DNS
 Alias para host  Sería una base de datos centralizada
 Nombre canónico y alias distante con grandes retardos de acceso.
 Nombre canónico: CNAME en  Mantención, es mejor que cada dominio
RFC 1035 gestione sus nombres
 Alias para servidor de correo
 Distribución de carga No es escalable!
 Servidores Web replicados: conjunto
de direcciones IP para un nombre
canónico (e.g. [Link].
[Link]), servidore DNS rota
entre direcciones IP
70

35
 15/03/2024

BASE DE DATOS JERÁRQUICA Y DISTRIBUIDA

Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

[Link] [Link] [Link]

[Link] [Link]
DNS servers DNS serversDNS servers
DNS servers DNS servers

Cliente desea IP de [Link]; 1ra aprox. :

 Cliente consulta al servidor raíz para encontrar servidor DNS de com
 Cliente consulta servidor DNS TLD (Top Level Domain) de com para obtener
servidor DNS de [Link]
 Cliente consulta servidor DNS [Link] para obtener dirección IP de
[Link]

71

DNS: SERVIDORES DE NOMBRE RAÍZ

 Son contactados por servidor de nombre local cuando no puede resolver un nombre
 Servidor nombre raíz:
 Contacta servidor de nombre autoritario de la zona superior (e.g. com) si mapeo del
nombre es desconocido para él
 Obtiene mapeo (propio o desde otro servidor raíz)
 Retorna mapeo al servidor de nombre local
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD
h. ARL Aberdeen, MD k. RIPE London (17 other sites)
j. Verisign, Dulles VA (69 other sites )
i. Netnod, Stockholm (37 other sites)

e. NASA Mt View, CA m. WIDE Tokyo

f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
sites)

a. Verisign, Los Angeles CA

13 servidores de
(5 other sites) nombre raíz en todo
b. USC-ISI Marina del Rey, CA
l. ICANN Los Angeles, CA el mundo –
(41 other sites)
g. US DoD Columbus, replicados muchas
OH (5 other sites)
veces

72

36
 15/03/2024

TLD Y SERVIDORES AUTORITARIOS

 Top-level domain (TLD) servers: responsable por com, org, net, edu, etc., y todos los
dominios superiores de cada país: uk, fr, ca, jp, cl, etc..
 Network solutions mantiene servidores para el TLD de com
 Educause para el TLD de edu
 Nic (network information center) para el TLD de cl ([Link])
 Servidores DNS autoritarios: son servidores DNS de las organizaciones y proveen
mapeos autoritarios entre hostname e IP (e.g., Web y mail).
 Éstos pueden ser mantenidos por la organización o el proveedor de servicio

73

SERVIDOR DE NOMBRE LOCAL

 r No pertenece estrictamente a la jerarquía
 Cada ISP (ISP residencial, compañía, universidad) tiene uno.
 También son llamados “servidor de nombre por omisión” (default
name server)
 Cuando un host hace una consulta DNS, ésta es enviada a su servidor
DNS local
 Actúa como proxy, re-envía consulta dentro de la jerarquía.

74

37
 15/03/2024

root DNS server

EJEMPLO 1
2
3
Consulta iterativa: TLD DNS server
4
 Host en [Link] quiere la dirección IP de
[Link] 5
 Servidor contactado responde con el nombre local DNS server
del servidor a contactar [Link]
7 6
 “Yo no conozco este nombre, pero pregunta a 1 8
este servidor”
authoritative DNS server
[Link]
requesting host
[Link]

[Link]

75

root DNS server

CONSULTAS RECURSIVAS
2 3
7
6
Consulta recursiva : TLD DNS
server
 Pone la carga de la resolución de nombre al
local DNS server
servidor contactado. [Link] 5 4

 ¿Qué pasa en situaciones de alta carga? 1 8

authoritative DNS server

[Link]
requesting host
[Link]

[Link]

76

38
 15/03/2024

DNS: CACHE Y ACTUALIZACIÓN DE REGISTROS

 Una vez que un servidor de nombre conoce un mapeo, éste guarda (caches) el
mapeo
 Las entradas del cache expiran (desaparecen) después de algún tiempo (ver
[Link])
 Servidores TLD típicamente están en cache de los servidores de nombre
locales
• Así los servidores de nombre raíz no son visitados con frecuencia
 Mecanismos de Actualización/notificación están bajo diseño por el IETF (Internet
Engineering Task Force)
 RFC 2136
 [Link]

77

REGISTROS DNS
DNS: es una base de datos distribuida que almacena registros de recursos (RR)

RR format: (name, value, type, ttl)

type=A type=CNAME
 name es un hostname  name is alias para algun nombre
 value es una dirección IP “canonico” (el real)
type=NS  [Link] es realmente
 name es un dominio (e.g., [Link]
[Link])  value es el nombre canonico
 value es la direccion IP
(nombre) del servidor type=MX
autoritario que sabe cómo  value es el nombre del
obtener las direcciones IP de
este dominio. servidor de correo asociado con
name
78

39
 15/03/2024

MENAJE DEL PROTOCOLO DNS

Mensaje de consulta y respuesta, ambos con el mismo formato de menaje
2 bytes 2 bytes

Cabecera del mensaje identification flags

 identification: 16 bit # para # questions # answer RRs

consulta, para responder a la
consulta utiliza el mismo # # authority RRs # additional RRs
 flags:
questions (variable # of questions)
 Consulta o respuesta
 Rescursividad deseada
answers (variable # of RRs)
 Recursividad disponible
 La respuesta es autoritaria
authority (variable # of RRs)

additional info (variable # of RRs)

79

MENAJE DEL PROTOCOLO DNS

2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

Nombre, para una consulta questions (variable # of questions)

RRs en la respuesta de answers (variable # of RRs)

una consutla
Registros para servidores
authority (variable # of RRs)
autorizados
Adicional, información additional info (variable # of RRs)
Que se puede utilizar

80

40
 15/03/2024

INSERCIÓN DE REGISTROS EN DNS

Ejemplo: Recién se crea una empresa “Network Utopia”
 Debemos registrar el nombre [Link] en un administrador de dominio (e.g.,
Network Solutions)
 Necesitamos proveer el nombre y la dirección IP de nuestro servidor de nombre
autoritario (primario y segundario)
 Administrador del dominio inserta dos RRs en el servidor TLD com:
([Link], [Link], NS)
([Link], [Link], A)
 Incorporar en el servidor autoritario un registro Tipo A para [Link] y
un registro Tipo MX para [Link]
 ¿Cómo la gente obtiene la dirección IP de nuestro Servidor WEB?
 En Chile debemos acceder al NIC Chile para arrendar un nombre de dominio.

81

RESUMEN
Sistema de nombres de dominio
Jerarquía de servidores
Servidores raíz
Servidores autoritarios y locales
Cache y actualización de registros
Mensajes del protocolo DNS
Registros

82

41
 15/03/2024

PREGUNTAS SOBRE LO VISTO HASTA AHORA

83

FIN DE LA PRESENTACIÓN – MUCHAS GRACIAS!!

84

42