Version 01/03/17

Computer Networks ICapa de AplicaciónComputer Networks I

application

transport

network

Capa de Aplicación

Aplicación

link

physical

inocente.sanchez@uclm.es

Correo electrónico: Introducción

Servicio prestado: Envío de mensajes entre Remitente y Destinatario (los dos actores involucrados) Dirección única a nivel mundial. Dos partes (local y dominio) separadas por el símbolo @. Ejemplo:

alguien@empresa.com Un único sentido Un único sentido

La respuesta es otro mensaje también de un único sentido No se espera respuesta inmediata

Ni siquiera se espera respuesta

¿Cliente-servidor? Sería absurdo que un destinatario estuviera siempre a la escucha

Alguien tiene que estar siempre a la escucha: servidor de correo

Los servidores de correo sí usan el paradigma cliente servidor

Los servidores actúan como intermediarios, como las oficinas postales de correo

Pueden usar el mismo servidor de correo o distinto. En el último caso se necesita conectar entre ellos

2

Pueden usar el mismo servidor de correo o distinto. En el último caso se necesita conectar entre ellos

Cada actor se conecta vía LAN / WAN con su servidor de correo

Buzón: El administrador crea un buzón para cada usuario, que es un espacio del disco duro con acceso

restringido a cada usuario

Lista de correo: un alias para varias direcciones de correo

El administrador crea una cola para almacenar los mensajes a enviar

Correo electrónico: Arquitectura (I)

3

El sistema de correo electrónico necesita dosagentes (UA), dos parejas de MTAs (clienteservidor) y una pareja de MAA (cliente servidor)

Correo electrónico: Arquitectura (II)

Los 9 pasos del correo. Ejemplo: Remitente Alicia - Destinatario Roberto Agente de usuario Alicia (1. UA), Agente de Transferencia de Mensajes (2.

cliente MTA), y (3. servidor MTA). El usuario Remitente ejecuta un programa, lo envía a su servidor, vía LAN o WAN y lo almacena en la cola programa, lo envía a su servidor, vía LAN o WAN y lo almacena en la cola (pasos 1 a 3).

Otro cliente MTA (4). Necesita enviar el mensaje a través de Internet (5) al servidor del destinatario, a un servidor MTA (6). Este paso podría no ser necesario

El servidor MTA lo guarda en los buzones de cada usuario, y lo envía al servidor del Agente de Acceso de Mensajes MAA (7). El cliente del MAA (8) solicita al servidor MAA (7), y lo entrega al destinatario (9), a través de LAN o WAN.

4

WAN. El destinatario no se puede saltar su servidor de correo usando MTA

directamente. Tendría que estar siempre encendido y no sabe cuándo va a recibir un mensaje

El cliente servidor MTA es tipo push (empujar). El cliente pone el mensaje en el servidor. La información circula de izquierda a derecha

El destinatario necesita pull (coger) el mensaje del servidor

1) Alicia usa UA (agente de usuario) para componer un mensaje y lo dirije a Roberto, que tiene la dirección bob@someschool.edu

Correo electrónico: Arquitectura (III)

4) Se envía el correo entre servidores5) El servidor de correo de Roberto coloca el mensaje en

bob@someschool.edu2) El UA de Alicia envía el mensaje a su servidor de

correo (MTA); el mensaje se pone en la cola3) El cliente del servidor de correo de Alicia abre la

conexión TCP con el servidor de correo de Roberto

5

5) El servidor de correo de Roberto coloca el mensaje en su bandeja de entrada, donde queda almacenado

6) Roberto llama a su agente de usuario para extraer el mensaje cuando quiere leer su correo

Correo Electrónico: agente de usuario (UA)

Agente de usuario

El software que necesita el usuario para enviar, leer, responder, reenviar, etc... El software que necesita el usuario para enviar, leer, responder, reenviar, etc... Puede ser con comandos o con entornos gráficos y botones (usando ratón). Ejemplo del segundo tipo: Outlook, Eudora, ... Composición, edición, lectura de mensajes de correo

Sobre (envoltorio) y mensaje (cabecera y cuerpo) El envoltorio lo forman el remitente y el destinatario El mensaje tiene una cabecera y el cuerpo

La cabecera tiene información diversa: asunto, fecha y hora, etc... El cuerpo es el mensaje propiamente dicho

6

El agente de usuario se dispara por el usuario (o un temporizador) Si hay correo y el usuario lo desea, le aparece la lista (bandeja de entrada) Se ve un resumen de cada mensaje en la primera línea Se puede seleccionar cualquier mensaje para abrirlo y verlo íntegro

Al leerlo, se puede quitar del servidor (lo más habitual) O se puede mantener en el servidor (en algunos casos puede ser así)

Formato del mensaje de correo

cabeceraLínea

RFC 822: estándar para el formato del mensaje de texto: cabecera

cuerpo

Líneablanco

Líneas de cabecera A: Desde: Tema:

Cuerpo el mensaje propiamente dicho, sólo

caracteres ASCII

7

caracteres ASCII

Correo Electrónico: servidores de correo

Tres usos del paradigma cliente-servidor, dos usando el protocoloSMTP (1-2) y uno el protocolo POP / IMAP (3):

8

SMTP (1-2) y uno el protocolo POP / IMAP (3):

1.- Remitente – Su servidor de correo (LAN/WAN)

2.- Servidor de correo – servidor de correo (Internet)3.- Destinatario – Su servidor de correo (LAN/WAN)

Protocolos de acceso al correo

SMTP SMTP protocoloaccesoAgente

usuarioAgenteusuario

SMTP: agente de usuario y servidor / servidor y servidor Protocolo de acceso de control: recuperación desde el servidor

POP3: Post Office Protocol (versión 3) autorización (agente ↔ servidor) y descarga

IMAP4: Internet Mail Access Protocol (versión 4)

Servidor correoemisor

Servidor correoreceptor

RFC 1939

RFC 1730

9

IMAP4: Internet Mail Access Protocol (versión 4) más prestaciones (más complicado) gestión de mensajes almacenados en el servidor

Correo web (webmail): Gmail, Yahoo, Hotmail, etc. La comunicación entre los actores y los servidores de correo es vía web, con protocolo de acceso HTTP, bien para uno de los actores o ambos

RFC 1730

Protocolo POP3

Fase de autorización Comandos cliente:

user: nombre usuario

S: +OK POP3 server readyC: user bob S: +OKC: pass hungry S: +OK user successfully logged on

user: nombre usuario pass: contraseña

Respuesta servidor +OK -ERR

Fase de descarga, cliente: list: lista número de mensajes

retr: recupera mensaje por

C: list S: 1 498 S: 2 912 S: .C: retr 1 S: <message 1 contents>S: .C: dele 1 C: retr 2

10

retr: recupera mensaje por número

dele: borra quit: abandona

C: retr 2 S: <message 2 contents>S: .C: dele 2 C: quit S: +OK POP3 server signing off

POP3 (más) e IMAP

Más sobre POP3 Los ejemplos anteriores

usan el modo “descarga y

IMAP Conserva todos los mensajes en

un lugar: el servidorusan el modo “descarga y borra”.

Roberto no puede volver a leer el correo si él accede desde otro cliente

“Descarga-y-conserva”: copia mensajes en diferentes clientes

un lugar: el servidor Permite que el usuario organice

los mensajes en directorios Puede comprobar el correo antes

de descargarlo IMAP mantiene el estado del

usuario a través de las sesiones:Puede crear, borrar, renombrar

11

diferentes clientes POP3 es “sin estado” a

través de sesiones El cliente abre una conexión

TCP en el puerto 110 del servidor

Puede crear, borrar, renombrar carpetas, así como una estructura jerárquica de las mismas

Fases del protocolo SMTP(Simple Mail Transfer Protocol)

PROTOCOLO CLIENTE - SERVIDOR MTA

RFC2821

Usa conexión TCP para transferir de forma fiable el mensaje de correo desde el cliente al servidor por el puerto 25

Transferencia Directa: servidor Remitente al servidor Destinatario Tres fases del proceso de transferencia

establecimiento (saludo) transferencia de mensajes cierre

12

Interacción Comando/respuesta Comandos (cliente-servidor): texto ASCII Respuesta (servidor-cliente): códigos de tres cifras

Se deben enviar los mensajes en ASCII de 7 bits

SMTP: Comandos y respuestas (I)

13

SMTP: Comandos y respuestas (II)

14

Fases SMTP (I)

FASE DE ESTABLECIMIENTODespués de que un cliente haya realizado una conexión TCP al puerto 25

del servidor, ocurre que:1. El servidor envía el código 220 para decir que está preparado para recibir

el mensaje o el código 421 en caso contrario2. El cliente envía el mensaje HELO para identificarse usando su nombre de

dominio. Este paso es necesario para informar al servidor del nombre de dominio del cliente

3. El servidor responde con el código 250 para indicar OK o cualquier otro dependiendo de la situación

15

FASE DE TRANSFERENCIA1. El cliente envía el mensaje MAIL FORM para introducir la dirección

del remitente. Necesario por si hay que reportar errores de retorno

Fases SMTP (II)

del remitente. Necesario por si hay que reportar errores de retorno2. El servidor responde con el código 250 (OK)3(*). El cliente envía el mensaje RCTP TO que incluye la dirección del

destinatario4(*). El servidor responde con el código 250 (OK)5. El cliente envía el mensaje DATA para iniciar la transferencia6. El servidor responde con el código 354 para indicar que está

preparado

16

preparado 7. El cliente envía el contenido del mensaje en líneas consecutivas.

Cada línea termina con CR LF. El mensaje termina con un “·”8. El servidor responde con el código 250 (OK) o el que corresponda(*) Los pasos 3 y 4 se repiten si hay más de un destinatario

Fases SMTP (II-bis)

17

FASE DE CIERRE

Una vez entregado el mensaje con éxito, el cliente cierra la

Fases SMTP (III)

Una vez entregado el mensaje con éxito, el cliente cierra la conexión

1. El cliente envía el comando QUIT2. El servidor responde con el código 221 o el que

corresponda

18

Código ASCII (de 7 bits)

Representación de información alfanumérica alfanumérica (American Standart Code for Information Interchange, ASCII)

19

Código ASCII extendido

20

¿Cómo se materializa HTTP/1.1 200 OK?

Texto H T T P / 1 . 1 2 0 0 O K CR LFHexad. 48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D 0AHexad. 48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D 0A

Binario 01001000 01010100 00001101 00001010

1. Cada carácter ASCII se convierte en un par de hexadecimales2. Por cada par de hexadecimales se obtienen 8 bits (1 byte)3. En total hay 17 bytes, 34 hexadecimales, incluyendo CR y LF

21

3. En total hay 17 bytes, 34 hexadecimales, incluyendo CR y LF4. Ello supone un total de 136 bits

MIME

MIME: Multipurpose Internet Mail Extension. Protocolo suplementario para enviar caracteres No ASCII Otros idiomas distintos del inglés, otro tipo de datos, etc... Conversión No ASCII - ASCII y viceversa

RFC20452056

Conversión No ASCII - ASCII y viceversa Líneas adicionales en la cabecera del mensaje declaran tipo de contenido MIME:

From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

3. Datos multimedia:tipo, subtipo,

declaración de parámetros

2. Codificación de datos

1. Versión MIME

22

base64 encoded data ..... ......................... ......base64 encoded data

Cuerpo: datos codificados

4. Número de ID(Content-ID)

5. Descripción contenido(Content-Description)

Codificación de datos (algunos casos)

Hay 5 casos: (7 bits, 8 bits, Binario, Base64, quoted-printable)

Base 64

Cada 24 bits (3 bytes) no ASCII se convierten en 4 bloques de 6 bits y a cada uno se le asigna un carácter ASCII según una tabla

Dichos caracteres se envían como ASCII

En el extremo opuesto se aplica el proceso inverso y se

23

En el extremo opuesto se aplica el proceso inverso y se recuperan los 3 bytes no ASCII

Dos de cada ocho bits son “sobrecarga” (25%)

Si hay pocos caracteres No ASCII, es demasiada sobrecarga

Codificación de datos (Base 64)

Base 64

24

Codificación de datos (Quoted-printable)“encomillado imprimible”

Quoted-Printable (adecuado si la proporción de caracteres No ASCII es pequeña). Suponemos que mandamos bloques de 8 bits, mezclando caracteres ASCII (0xxxxxxx) y No ASCII (1xxxxxxx)(1xxxxxxx)

Los caracteres ASCII se envían como tales Los caracteres no ASCII se “triplican” en tres bloques

El primer bloque es la representación del signo =, cuyo código es 00111101 (3D)

El segundo bloque es el ASCII de la primera cifra hexadecimal en ASCII

El tercer bloque es la segunda cifra hexadecimal en ASCII

Ejemplo:

25

Ejemplo:

DNSRFC1034/RFC1035

DNS: Sistema de Nombre de Dominios (I)

Personas: muchos identificadores con letras:

nombre, apellidos, www.esi ...

Domain Name System (DNS):

Bases de Datos Distribuidas implementadas en jerarquías de muchos servidores de nombre nombre, apellidos, www.esi ...

Hosts Internet, routers:

Dirección IP (32 bit) - usada para enviar datagramas

Los datos enviados a la capa de transporte necesitan entre otras cosas la IP del destino

nombre

Usa un protocolo de la capa de aplicación de hosts, routers, servidores de nombre que se comunican para resolver nombres (traducción dirección / nombre)

No es un protocolo de interacción directa con el usuario

cosas la IP del destino

¿asignación entre dirección IP y nombre?

Función básica de Internet que da apoyo a otros protocolos de forma “transparente” (HTTP, SMTP)

La mayor complejidad de la arquitectura de red está en los extremos

¿Por qué no un DNS centralizado? Único punto de fallo: catrástrofe

Volumen de tráfico extremo

Servicios DNS

Traducción nombre del host a

DNS: Sistema de Nombre de Dominios (II)

Volumen de tráfico extremo Se obliga a que todo el mundo

se conecte con una única máquina: grandes retardos

Mantenimiento

¡ No es escalable !

dirección IP (paradigma cliente servidor)

Alias de hosts y servidores correoNombres canónicos y aliasEjemplo: webmail.cim.es es un alias

de m2.cim.esEl canónico es: m2.cim.es

Reparto de la carga¡ No es escalable ! Reparto de la cargaServidores web replicados: conjunto

de direcciones IP para un único nombre canónico. Se van rotando las IPS que se dan

DNS presta servicio a otros protocolos

Servicio DNS a SMTP

Un cliente SMTP puede pedir a un cliente DNS la IP de una dirección

El Servidor DNS responde con un número a través del cliente DNS El Servidor DNS responde con un número a través del cliente DNS

El cliente DNS se lo entrega al cliente SMTP

El Servidor DNS utiliza el puerto 53 tanto en UDP como en TCP

Base de Datos distribuida y jerárquica

El cliente busca la IP de www.amazon.com: El cliente se lo pide a un servidor raíz y le devuelve la dirección IP de

un servidor DNS “.com” un servidor DNS “.com” El cliente pide al servidor DNS “.com” y le devuelve la dirección IP

del servidor DNS “amazon.com” El cliente pide al servidor DNS “amazon.com” que le diga la dirección

IP de www.amazon.com y le devuelve la dirección IP definitiva.

DNS: Jerarquía de servidores

Tipos: Servidores DNS raíz Servidores TLD (Top-Level Domain). Ej: servidores DNS .com,

servidores DNS .org, etc,...servidores DNS .org, etc,... Servidores autorizadores. Ej: servidor DNS yahoo.com, servidor DNS

amazon.com, etc,...

DNS: Servidores de nombre raíz

Contactados por servidores de nombre locales que no pueden resolver el nombre Servidor de nombre raíz:

Contacta con el servidor de nombre autorizador si el nombre no lo conoce Consigue la asignación Consigue la asignación Devuelve la asignación al servidor de nombre local

13 servidores de nombre raíz por el mundo, 247 incluyendo los incluyendo los replicados (año 2011)

TLD y Servidores Autorizadores

Servidores de Dominio de Alto-Nivel (Top-Level Domain):responsables de .com, .org, .net, .edu, etc, y de los dominios raíz de países: .es, .fr, .ca, .jp.dominios raíz de países: .es, .fr, .ca, .jp. La empresa Verisign Gobal Registry Services

mantiene los servidores TLD .com Y Educause mantiene los servidores TLD .edu

Servidores DNS autorizadores: servidores DNS de una organización (empresa o institución), proporcionando un organización (empresa o institución), proporcionando un nombre propio y asociando IP a los servidores de la organización (ej. Web y mail) Se pueden mantener por la propia organización o por

un proveedor de servicios (ISP)

Servidores de nombre locales

Estrictamente no pertenecen a la jerarquía Cada ISP (residencial, empresa, universidad) Cada ISP (residencial, empresa, universidad)

tiene el suyo propio. También se llaman “servidor de nombre por defecto”

Cuando un host hace una petición DNS, se envía a su servidor DNS local, que actúa como un proxy Si sabe la respuesta, le responde Si no sabe la respuesta dirige la pregunta a la

jerarquía

Ejemplo: resolución iterativa

Un host solicitante en cis.poly.edu quiere saber la dirección IP de dirección IP de gaia.cs.umass.edu

Resolución iterativa:□ El DNS local no lo sabe y lo envía al

raíz

□ El raíz le devuelve una lista de DNS TLD (.edu) que pueden saberlo

El DNS local contacta con alguno de □ El DNS local contacta con alguno de ellos, quien repite el proceso

□ … Y así sucesivamente

RAIZ: …yo no lo sé, pero pregúntale a Fulano…

FULANO: …yo no lo sé, pero pregúntale a Mengano…

Ejemplo: resolución recursiva

Resolución recursiva:□ Pregunta a superior hasta

raízraíz

□ Desciende hasta el buscado

□ Respuesta en sentido contrario

□ El DNS local del cliente sólo pregunta a un servidor

El DNS raiz se encarga de resolver dando las órdenes oportunas a sus “subordinados” y se lo comunica directamente al DNS local

DNS: caché y registros de actualización

Una vez que (cualquier) servidor de nombreaprende la asignación, la guarda en su memoriacachéaprende la asignación, la guarda en su memoriacaché Las entradas de caché pasadas un cierto tiempo (dos

días) se borran para que no queden obsoletas Los servidores TLD típicamente “cachean” en

servidores de nombre local. De esta manera los servidores de nombre raíz no se visitan

a menudoa menudo

Registros de Recursos DNS

DNS: base de datos distribuida de almacenamiento de Registros de Recurso (RRs). Un registro es una cuádrupla compuesta por:

Formato RR:

El significado de Nombre y Valor depende del campo Tipo

Formato RR: (nombre, valor, tipo, caducidad/TTL)

□ Tipo=A♦ nombre es el nombre del host

♦ valor es la dirección IP

□ Tipo=CNAME♦ nombre es el alias de un host

♦ valor es el nombre canónico

□ Tipo=MX□ Tipo=NS

♦ nombre es el dominio (ej.: foo.com)

♦ valor es el nombre del host del servidor de nombre autorizador

que conoce cómo obtener las IPspara los hosts de dicho dominio

□ Tipo=MX♦ nombre es el alias de un

host

♦ valor es el nombre canónico del servidor de correo asociado cuyo alias aparece en nombre

Protocolo y mensajes DNS (I)

Protocolo DNS: los mensajes de preguntas y respuestas, ambos con el mismo formato de mensaje

Cabecera del mensajeCabecera del mensaje□ Identificación: número de 16 bits

que identifica la pregunta o respuesta

□ Indicadores de 1 bit (flags):

♦ Pregunta o respuesta (0/1)

♦ Recursión deseada

♦ Recursión disponible♦ Recursión disponible

♦ Respuesta es autorizadora

□ Números de:

♦ Preguntas, respuestas RRs

♦ RRs autorizad., RRs adicionales

Protocolo y mensajes DNS (II)

Resto del mensaje□ Questions (preguntas)

♦ Uno o más registros de preguntas □ Answers (sólo en modo respuesta)

♦ Uno o más registros de recursos□ Authority (sólo en modo respuesta)

♦ Información sobre uno o más servidores autorizadores de la preguntala pregunta

□ Adittional information (sólo en modo respuesta)♦ Información adicional que puede ser útil para resolver

Inserción de registros en DNS (I)

Ejemplo: se acaba de crear una empresa llamada “Network Utopia”

Se registra el nombre networkutopia.com en un registrador autorizado (ej.: Network Solutions), pagando una pequeña tasaEl registrador autorizado verifica la unicidad del dominio y lo mete El registrador autorizado verifica la unicidad del dominio y lo mete en una base de datos. Ver lista de registradores en www.internic.net

Necesario proporcionar nombres y direcciones IP de tus servidores DNS autorizadores (primario y secundario), por ejemplo dns1.networkutopia.com, dns2.networkutopia.com, 212.212.212.1, 212.212.212.2.

La IP del servidor web de networkutopia.com podría ser, por ejemplo, 212.212.71.4

El registrador insertará dos RRs por cada uno de ellos en el servidor TLD El registrador insertará dos RRs por cada uno de ellos en el servidor TLD .com

(dns1.networkutopia.com, 212.212.212.1, A) (networkutopia.com, dns1.networkutopia.com, NS)

(dns2.networkutopia.com, 212.212.212.2, A) (networkutopia.com, dns2.networkutopia.com, NS)

Inserción de registros en DNS (II)

Supongamos que Alicia quiere ver la página web www.networkutopia.com desde Australia.En primer lugar, su host enviará una solicitud DNS a su servidor DNS local. Si no dispone dela información, el servidor DNS local se pondrá en contacto con un servidor TLD (.com). Elservidor DNS local también tendrá que ponerse en contacto con un servidor DNS raíz si elservidor TLD (.com) no tiene la información en su memoria caché.

Este servidor TLD contiene registros de recursos tipo NS y tipo A citados anteriormente,porque el registrador insertó estos registros de recursos en todos los servidores TLD (.com). Elservidor TLD (.com) envía una respuesta al servidor DNS local de Alicia, con la respuestaque contiene los dos registros de recursos.

El servidor DNS local de Alicia envía una solicitud DNS a la dirección 212.212.212.1,preguntando por el registro tipo A correspondiente a www.networkutopia.com. Este registropreguntando por el registro tipo A correspondiente a www.networkutopia.com. Este registroproporciona la dirección IP del servidor web deseado, por ejemplo, 212.212.71.4, que elservidor DNS local de Alicia pasa a su host.

El navegador de Alicia ahora puede iniciar una conexión TCP al host 212.212.71.4 y enviaruna petición HTTP sobre la conexión.

Compartir P2P RFC5694

Compartición de ficheros P2P (Peer to peer, igual a igual)

Ejemplo

Alicia ejecuta una aplicación

• Alicia elige a uno de ellos, a Roberto

Alicia ejecuta una aplicación cliente P2P en su equipo

Intermitentemente se conecta a Internet; consigue nueva dirección IP en cada conexión

Pide la canción “Hey Jude”

• El fichero se copia desde el PC de Roberto al equipo de Alicia: HTTP

• Mientras Alicia descarga, otros usuarios descargan desde el equipo de Alicia

Pide la canción “Hey Jude”

La aplicacion presenta otros peers que tienen copia de la canción “Hey Jude”

• El equipo de Alicia es tanto un cliente web como un servidor web esparádico

¡Todos los peers son servidores = altamente escalable!

Compartición de ficheros P2P

P2P (peer to peer, igual a igual) Pueden ser máquinas domésticas. No se

necesita una infraestructura previanecesita una infraestructura previa Cada máquina puede actuar como cliente y

obtiene el contenido de otra y como servidor y proporciona el contenido a otra, incluso simultáneamente

No hay un punto central de control No hay un punto central de control Creó problemas legales con los derechos de

autor Son autoescalables

P2P: directorio centralizado (Napster)

Diseño original “Napster”

1) cuando un peer se conecta, informa al servidor central:

Dirección IP Servidor

Roberto

Contenido dispuesto a compartir

2) Alicia pregunta sobre la canción “Hey Jude” y el servidor le responde que la tiene Roberto

3) Alicia pide el fichero a Roberto directamente

Servidordirectorios

centralizado

peers

1

1

1

12

3

Ventajas:* Todos los peers son servidores

peers

Alicia

* Todos los peers son servidores

* Altamente escalable

Inconvenientes:* Un punto de fallo central

* Impone un límite (cuello de botellas) de prestaciones

* Infracción de derechos de autor

P2P: problemas con el directorio centralizado

Fácil mantenimiento, pero... Un ataque al servidor hace que caiga todo el sistema

Mucha congestión y ralentización del sistema Mucha congestión y ralentización del sistema Infracción derechos de autor, clausurado en 2001 En 2003 Roxio compró Navster y creó la versión 2, de pago

La transferencia de ficheros está descentralizada, pero la está descentralizada, pero la localización de contenidos está muy centralizada

BitTorrent (I)

Nace en 2002 (Bram Cohen) Motivación:

Los peers en P2P se ausentan a menudo Malo si Alicia abandona a Roberto mientras está descargando un Malo si Alicia abandona a Roberto mientras está descargando un

(enorme) fichero de ella La popularidad decrece rápidamente con el tiempo

Enfocado a un intercambio eficiente: Los ficheros se trocean en segmentos de 256 KB (unidades a compartir) Los peers solicitan en primer lugar segmentos raros para redistribuirlos más

rápidamente

BitTorrent no proporciona mecanismos para localizar contenidos Supone que los clientes tienen un fichero “.torrent”, existe un “servidor de

seguimiento (tracker)”, que lleva el seguimiento de los segmentos que tienen los peers

Malla de peers interesados en un fichero concreto

BitTorrent (II)

Protocolo P2P para compartir ficheros grandes un grupo de peers Compartir no en el sentido visto hasta ahora, cliente servidor Un grupo de peers colaboran para que un fichero sea obtenido por todos Un grupo de peers colaboran para que un fichero sea obtenido por todos

ellos Esto es posible gracias a un proceso colaborativo llamado torrente

BitTorrent (III)

Cada peer descarga trozos (chunks) de un fichero de otro peer que tiene y sube trozos que otros peers no tienen

Al conjunto de todos los peers que tienen algo que dar o recibir se les llama enjambre (swarm)les llama enjambre (swarm) Un peer que tiene el fichero completo se llama sembrador (seed) Un peer que no tiene el fichero completo y aspira a tenerlo se llama

sanguijuela (leecher)

BitTorrent (IV)

Además de los peers, hay otro actor, un Servidor Rastreador (Tracker), que rastrea las operaciones del enjambre y mantiene la lista actualizada de participantes enjambre y mantiene la lista actualizada de participantes en cada momento

Se crea un archivo .torrent que se puede descargar por parte de quien esté interesado

Si un nuevo peer quiere descargar un fichero, accede al Servidor con el nombre del fichero y recibe un archivo con metadatos llamado torrentecon metadatos llamado torrente Contiene información sobre los trozos La dirección del servidor

BitTorrent (V)

Accede al Servidor y recibe las direcciones IP de los peers vecinos

Se conectan con ellos mediante TCP. Se conectan con ellos mediante TCP. Un cliente BitTorrent gestiona el proceso. Es conocido el uTorrent Pasa a formar parte del enjambre y puede subir y descargar

trozos. En un cierto momento cada peer tiene un determinado conjunto

de trozos y puede saber los trozos que tienen los restantes peers. Un determinado peer puede pedir a otros peers los trozos que él no tiene.no tiene.

Cuando finaliza la descarga puede Permanecer en el enjambre ofreciendo “sus servicios” a los que hay o puedan entrar Abandonar el enjamble

También puede abandonar el enjambre antes de haber descargado. En ese caso, puede volver más adelante o no volver

BitTorrent (VI)

Se distribuye un fichero de metadados (.torrent) a todos los peers Normalmente vía E-mail, web, etc... Normalmente vía E-mail, web, etc...

Un peer sabe si tiene un trozo verificando el hash Un peer siempre sabe los trozos que tienen otros peers El fichero .torrent contiene:

Claves de descifrado (hashes o identificadores) de todas los trozostrozos

Referencia de tracker (URL) Longitud de pieza: normalmente 256 KB

BitTorrent (VII)

BitTorrent (VIII)

Ventajas: Evita saturación de los servidores. Se aprovecha el ancho de banda de Evita saturación de los servidores. Se aprovecha el ancho de banda de

los usuarios que están descargando

Redundancia. La información está en muchos peers. Basta con que haya uno para disponer de la misma

Alta disponibilidad a la hora de descargar. Hay muchos usuarios conectados pudiendo descargar de varios de ellos al mismo tiempo

Inconvenientes:Inconvenientes: Errores. A veces se pueden dar errores al componer el archivo. Dependencia de los peers. Si un peer se ausenta en cuanto descarga, no

comparte y rompe el espíritu del protocol BitTorrent Dependencia del tracker. Sin él nada se puede hacer