CURSO:2020/2021

ORGANIZACIÓN ASIGNATURA
Unidad 1 Unidad 2 Unidad 3 Unidad 4

Semana 1 X

Semana 2 X

Semana 3 X

Semana 4 X

Semana 5 X

Semana 6 X

Semana 7 X

Semana 8 X

Semana 9 X

Semana 10 X

Semana 11 X

Semana 12 X

Semana 13 X

Roberto Vélez Gamboa <!1> TCP/IP

 CURSO:2020/2021

UNIDAD 1: OTRAS APLICACIONES

DE RED
TEMA 1: LA CAPA DE
APLICACIÓN
Las aplicaciones de red son la razón de ser de una red de computadoras: si no pudiéramos
concebir ninguna aplicación útil, no existiría la necesidad de disponer de infraestructura
de red y unos protocolos para darles soporte.

Entre las aplicaciones Internet se incluyen: correo electrónico de texto, el acceso remoto a
computadores, la transferencia de archivos y los grupos de noticias. También se incluyen la
mensajería instantánea y la compartición de archivos P2P.

1.1 CORREO ELECTRÓNICO EN INTERNET

El correo electrónico ha existido desde que internet viera la luz. Es un medio de

comunicación asíncrono (las personas envían y leen mensajes cuando les conviene, sin tener
que coordinarse con las agendas de otras personas). Mediante las listas de correos, se
pueden enviar mensajes de correo electrónico y correo basura (spam) a miles de destinatarios
a un mismo tiempo. A menudo, los mensajes de correo electrónico incluyen adjuntos.

Existen tres componentes principaleS: agentes de usuario, servidores de correo y el

protocolo simple de transferencia de correo (SMTP, simple mail transfer protocol).

Roberto Vélez Gamboa <!2> TCP/IP

 CURSO:2020/2021

Alicia, que envía un correo electrónico a un destinatario, Benito. Los agentes de usuario
permiten a los usuarios leer, responder, reenviar, guardar y componer mensajes. Microsoft
Outlook es un ejemplo de agente de usuario para correo electrónico. Cuando Alicia termina de
componer su mensaje, es colocado en la cola de mensajes salientes del servidor de correo.
Cuando Benito quiere leer un mensaje, su agente de usuario recupera el mensaje de su buzón,
que se encuentra en el servidor de correo.

Los servidores de correo forman el núcleo de la infraestructura del correo electrónico. Cada
destinatario, tiene un buzón de correo ubicado en uno de los servidores de correo. El buzón
de Benito gestiona y mantiene los mensajes que le han sido enviados. Un mensaje típico
inicia su viaje en el agente de usuario del emisor, viaja hasta el servidor de correo del
emisor y luego hasta el servidor de correo del destinatario, donde es depositado en el buzón
del mismo.

Cuando Benito quiere acceder a los mensajes contenidos en su buzón, el servidor de correo
que lo contiene autentica a Benito (mediante el nombre de usuario y la contraseña). El
servidor de correo de Alicia también tiene que ocuparse de los fallos que se producen en el
servidor de correo de Benito. Si el servidor de Alicia no puede enviar el mensaje de correo
al servidor de Benito, entonces el servidor de Alicia mantiene el mensaje en una cola de
mensajes e intenta enviarlo más tarde (normalmente cada 30 minutos). Después de varios
intentos de reenvío, si el servidor no consiguió el envío del correo, elimina el mensaje.

1.1.1 SMTP
SMTP es el principal protocolo de la capa de aplicación para el correo electrónico por
Internet. Utiliza el servicio de transferencia de datos fiables TCP para transferir el
correo desde el servidor de correo del emisor al servidor de correo del destinatario.

SMTP tiene dos lados: el lado cliente, que se ejecuta en el servidor de correo del emisor, y
el lado del servidor, que se ejecuta en el servidor de correo del destinatario.

Cuando un servidor de correo envía mensajes de correo a otro servidores, actúa como cliente
SMTP. Por el contrario, cuando recibe correo de otros servidores, actúa como un servidor
SMTP.

El protocolo SMTP, que está definido en el documento RFC 5321, es el corazón del correo
electrónico por internet. SMTP transfiere dede los servidores de correo de los emisores a
los servidores de correo de los destinatarios. Es una tecnología heredada que utiliza
algunas funciones arcaicas. Por ejemplo, restringe el cuerpo de todos los mensajes a formato
ASCII. Por tanto, para transmitir cualquier archivo se tiene que codificar a ASCII en origen
y descodificar en destino.

SMTP no utiliza servidores intermedios para enviar correos.

Funcionamiento básico de SMTP:

Roberto Vélez Gamboa <!3> TCP/IP

 CURSO:2020/2021

El protocolo SMTP presenta muchas similitudes con lso protocolos empleados por las personas
para las interacciones cara a cara.

1. El cliente SMTP establece conexión TCP con el puerto 25 del servidor SMTP destino. Si
el servidor no está operativo lo intentará de nuevo más tarde.

2. Después de establecer la conexión, el servidor y el cliente llevan a cabo el proceso de

negociación de la capa de aplicación. Durante esta fase, el cliente SMTP especifica la
dirección de correo electrónico del emisor y la dirección de correo electrónico del
destinatario.

3. A continuación de la presentación entre cliente y servidor, se envía el mensaje

mediante TCP para transferir el mensaje al servidor sin errores.

4. El cliente repite el proceso (punto 3) a través de la misma conexión TCP si tiene que
enviar otros mensajes al servidor, en caso contrario, indica a TCP que cierre la
conexión.

Ejemplo de los mensajes intercambiados entre un cliente SMTP(C) y un servidor SMTP(S). La

siguiente transmisión comienza tan pronto como se establece conexión TCP.

Como se puede ver, el cliente ejecuta

cinco comandos HELO (abreviatura de
HELLO), MAIL, FROM, RCPT TO, DATA y
QUIT.

Si es necesario enviar más mensajes

al mismo servidor, puede hacerlo en
la misma conexión TCP. Para cada
nuevo correo se inicia con un nuevo
comando MAIL FROM.

Se ejecutará el comando QUIT después

de que se envíen todos los mensajes.

Es muy recomendable que se utilice TELNET para establecer diálogo directo con un servidor
SMTP, para ello se debe ejecutar : telnet nombreServidor 25

1.1.2 Comparación con HTTP

Ambos protocolos se emplean para transferir archivos de un host a otro: HTTP transfiere
archivos desde un servidor web a un cliente web y SMTP desde un servidor de correo a otro
servidor de correos.

También, ambos emplean conexiones persistentes.

Sin embargo, tienen diferencias:

1. HTTP es principalmente un protocolo pull(protocolo de extracción): alguien carga la

información en un servidor web y los usuarios utilizan HTTP para extraer la información
del servidor cuando desean.

Roberto Vélez Gamboa <!4> TCP/IP

 CURSO:2020/2021

SMTP es fundamentalmente un protocolo push (protocolo de inserción): el servidor de

correo emisor introduce el archivo en el servidor de correo receptor.

2. SMTP requiere que cada mensaje esté en el formato ASCI. Por el contrario, HTTP no
impone esta restricción.

3. HTTP encapsula cada objeto en su propio mensaje de respuesta HTTP. SMTP incluye todos
los objetos del mensaje en un mismo mensaje.

1.1.3 Formatos de los mensajes de correos

Cuando una persona envía un mensaje de correo electrónico a otra, una cabecera que contiene
la información administrativa antecede al cuerpo del mensaje. Esta información se incluye en
una serie de líneas de cabecera, que están definidas en el documento RFC 5322. Las líneas de
cabecera y el cuerpo del mensaje se separan mediante una línea en blanco (mediante CRLF).

Cada línea de cabecera contiene texto legible, que consta de una palabra clave seguida de
dos puntos y de un valor. Algunas de las palabras calve son obligatorias y otras opcionales.
Toda cabecera tiene que estar formada por una línea de cabecera FROM: y una línea TO:,
también puede incluir otras líneas opcionales como Subject:. Estas líneas de cabecera son
diferentes de los comandos SMTP vistos en la sección 1.1.1.

Una cabecera típica es:

Después del mensaje de cabecera se incluye un línea en blanco y, a continuación, el cuerpo

del mensaje (en ASCII).

1.1.4 Protocolos de acceso para correo electrónico

Una vez que SMTP envía el mensaje del servidor de correo de Alicia al servidor de correo de
Benito, el mensaje se coloca en el buzón de este último.

Puesto que Benito(el destinatario) ejecuta su agente de usuario en su PC local, es natural

que se considere también incluir un servidor de correo en su PC local. De esta forma, el
servidor de correo de Alicia dialogará directamente con el PC de Benito. Sin embargo hay un
problema, si el servidor de correo de Benito residiera en su PC local, siempre tendría que
estar encendido y conectado a Internet para recibir los nuevos correos que pudieran llegar
en cualquier momento.

El agente de usuario de Alicia utiliza SMTP para introducir el mensaje de correo en su

propio servidor de correo, y a continuación el servidor de correo de Alicia utiliza SMTP

Roberto Vélez Gamboa <!5> TCP/IP

 CURSO:2020/2021

para pasar el mensaje al servidor de correo de Benito. Sin la retransmisión a través del
servidor de correo de Alicia, el agente de usuario de esta no tiene ninguna forma de acceder
a un servidor de correo de destino inalcanzable.

El RFC que se ocupa de SMTP define cómo se pueden utilizar los comandos SMTP para transmitir
un mensaje a través de varios servidores SMTP.

El agente usuario de Benito no puede utilizar SMTP para obtener los mensajes por que es una
operación de extracción (pull) mientras que

POP3

POP3 es un protocolo de acceso a correo extremadamente simple. Está definido en [RFC 1939],
teniendo un funcionalidad bastante limitada.

Se inicia cuando el agente de usuario (el cliente) abre una conexión TCP en el puerto 110 al
servidor de correo. Una vez establecida la conexión TCP, POP3 pasa a través de tres fases:

• Autorización: el agente de usuario envía un nombre de usuario y una contraseña para

autenticar al usuario. Tiene dos comandos principales:

• user

• pass

• Transacción: El agente de usuario recupera los mensajes , además puede marcar los mensajes
para borrado, eliminar las marcas de borrado y obtener las estadísticas del correo. El
usuario ejecutará los siguientes comandos:

• list: se pide el tamaño de cada uno de los mensajes

• retr:recuperar un mensaje

• dele: borrar un mensaje

• Actualización: tiene lugar después que el cliente haya ejecutado el comando quit,
terminando la sesión POP3, momento en el que el servidor borra los mensajes que han sido
marcados para borrado.

En una comunicación POP3, el usuario ejecuta comandos y el servidor devuelve una respuesta:

• +OK: el comando anterior era correcto.

• -ERR: el comando anterior tenía algún error.

Durante una sesión POP3, se mantiene la relación de los mensajes de usuario que han sido
marcados para ser borrados. Sin embargo, el servidor POP3 no conserva la información de

Roberto Vélez Gamboa <!6> TCP/IP

 CURSO:2020/2021

estado de una sesión POP3 a otra. Esta falta de memoria del

estado entre sesiones simplifica la implementación de un
servidor POP3.

IMAP

El protocolo IMAP está definido en [RFC 3501]. Al igual que

POP3, IMAP es un protocolo de acceso a correo. Ofrece muchas
más funcionalidades que POP3, pero también es más complejo.

Un servidor IMAP asociará cada mensaje con una carpeta; cuando

un mensaje llega al servidor, se asocia a la carpeta INBOX del
destinatarios, el cual puede enviar el mensaje a otra carpeta,
leerlo, borrarlo, etc. El protocolo IMAP proporciona comandos
que permiten a los usuarios crear carpetas y mover los
posible comunicación, comandos
mensajes de una carpeta a otra. También proporciona comandos transacción
que permiten a los usuarios realizar búsquedas en carpetas
remotas para localizar mensajes.

Un servidor IMAP mantiene la información acerca del estado a lo largo de las sesiones.

También dispone de comandos que permiten a un usuario obtener partes de los mensajes. Por
ejemplo, se puede obtener solo la cabecera del mensaje.

Correo electrónico web

El agente de usuario es un navegador web corriente y el usuario se comunica con su buzón

remoto a través de HTTP. Cuando un destinatario, como Benito, deea acceder a un mensaje de
su buzón, este es enviado desde el servidor de correo de Benito a su navegador usando el
protocolo HTTP. Cuando un emisor, como Alicia, desea enviar un mensaje de correo
electrónico, este es transmitido desde su navegador a su servidor de correo a través de HTTP
en lugar de SMTP. Sin embargo, el servidor de correo de Alicia, sigue enviando y recibiendo
los mensajes de otros servidores mediante SMTP.

Roberto Vélez Gamboa <!7> TCP/IP

 CURSO:2020/2021

1.2 DNS: SERVICIO DE DIRECTORIO DE INTERNET

Un identificador para los host es el nombre del host. Los nombres del host, como por ejemplo
www.diariodesoria.com son mnemónicos y son, por tanto, entendidos por las personas. Sin
embargo, los nombres de host proporcionan poca o ninguna información acerca de la ubicación
del host dentro de internet.

Los hosts también se pueden identificar mediante direcciones IP. Una dirección Ip es
jerárquica porque al explorar la dirección de izquierda a derecha, se obtiene información
cada vez más específica acerca del lugar en el que está ubicado el host dentro de internet.

1.2.1 Servicios proporcionados por DNS

Sistema de nombres de dominio (DNS) traduce los nombres mnemónicos y las direcciones IPs de
los servidores.

DNS es una base de datos distribuida implementada en una jerarquía de servidores DNS y un
protocolo de la capa de aplicación que permite a los hosts consultar la bbdd distribuida. El
protocolo DNS se ejecuta sobre UDP y utiliza el puerto 53.

Otros protocolos de la capa de aplicación, como HTTP y SMTP, emplean habitualmente DNS para
traducir los nombres de host suministrados por el usuario en direcciones IP.

Para que el host del usuario pueda enviar un mensaje de solicitud HTTP al servidor web
www.diariodesoria.com, el hosts del usuario debe obtener en primer lugar la dirección P.
Esto se hace del siguiente modo:

1. La propia máquina cliente ejecuta el lado del cliente de la aplicación DNS.

2. El navegador extrae el nombre de host www.diariodesoria.com, del URL y pasa el nombre de

host al lado del cliente de la aplicación DNS.

3. El cliente DNS envía una consulta que contiene el nombre de hosts a un servidor DNS.

4. El cliente DNS recibe finalmente una respuesta, que incluye la dirección IP

correspondiente al nombre del host.

5. Una vez que el navegador recibe la dirección IP del servidor DNS, puede iniciar una
conexión TCP con el proceso servidor HTTP localizado en el puerto 80 en esa dirección IP.

DNS proporciona otros servicios importante además de la traducción de nombres de host en

direcciones IP:

• Alias de host: un host con un nombre complicado puede tener uno o más alias. Una aplicación
puede invocar DNS para obtener el nombre de host canónico para un determinado alias, así
como la dirección IP del host.

• Alias del servidor de correo. Una aplicación de correo puede invocar al servicio DNS para
obtener el nombre del hosts canónico para un determinado alias, así como la dirección IP
del host.

• Distribución de carga: DNS también se emplea para realizar la distribución de carga entre
servidores replicados, como los servidores web replicados. Los sitios con una gran carga de
trabajo están replicados en varios servidores, ejecutándose cada servidor en un sistema
terminal distinto y teniendo cada uno una dirección IP diferente. Para los servidores web
replicados hay asociado un conjunto de direcciones IP con un único nombre de host canónico.
La bbdd DNS contiene este conjunto de direcciones IP- Cuando los clientes realizan una

Roberto Vélez Gamboa <!8> TCP/IP

 CURSO:2020/2021

consulta DNS sobre un nombre asignado a un conjunto de direcciones, el servidor responde

con el conjunto completo de direcciones IP, pero rota el orden de las direcciones en cada
respuesta. La rotación DNS también se emplea para el correo electrónico de modo que
múltiples servidores de correo pueden tener el mismo alias.

DNS está especificado en los documentos RFC 1034 y RFC 1035.

1.2.2 Como funciona DNS

Una determinada aplicación que se ejecuta en el host de un usuario, necesita traducir un
nombre de host en una dirección IP. La aplicación invocará al lado del cliente de DNS,
especificando el nombre del host que necesita la correspondiente traducción. Entonces, la
aplicación DNS en el host del usuario entra en funcionamiento, enviando un mensaje de
consulta a la red. Todos los mensajes de consulta y de respuesta DNS se envían dentro de
datagramas UDP al puerto 53. El servicio DNS del host del usuario recibe un mensaje de
respuesta DNS que proporciona la traducción deseada. DNS es una caja negra que proporciona
un servicio de traducción simple y directo.

Para abordar estos problemas de escalado, DNS utiliza un gran número de servidores,
organizados de forma jerárquica y distribuidos al rededor del mundo.

Tipos de servidores DNS:

• Servidores DNS raíz: los servidores de nombres raíz proporcionan las direcciones IP de los
servidores TLD.

• Servidores de dominio de nivel superior (TLD). Para todos los dominios de nivel superior,
como son com, org, es, etc, proporcionan las direcciones IP para los servidores DNS
autoritativos.

• Servidores DNS autoritativos: un servidor DNS autoritativo alberga los registros DNS de
los host que tienen accesibles públicamente.

Todos los servidores DNS raíz, TLD y autoritativos pertenecen a la jerarquía de servidores
DNS. Un servidor DNS local no pertenece estrictamente a la jerarquía, pero no obstante es
importante dentro de la arquitectura DNS local. Cada ISP tiene un servidor DNS local. Cuando
un host se conecta a un ISP, este proporciona al host las direcciones IP de uno o más de sus
servidores DNS locales.

Roberto Vélez Gamboa <!9> TCP/IP

 CURSO:2020/2021

El ejemplo mostrado a la
izquierda utiliza tanto
consultas recursivas como
consultas iterativas. La
consulta enviada desde
ese.nyu.edu a dns.nyu.edu es
una consulta recursiva, ya que
la consulta solicita a dns.nyu.
edu que obtenga por sí mismo la
correspondencia. Pero las tres
consultas siguientes son
iterativas puesto que todas las
respuestas son devueltas
directamente a dns. nyu. edu

Almacenamiento en caché DNS

DNS explota exhaustivamente el almacenamiento en caché para mejorar el comportamiento de los

retardos y reducir el número de mensajes DNS que van de un lado a otro por internet. En una
cadena de consultas, cuando un servidor DNS recibe una respuesta DNS, puede almacenar esta
información en su memoria local. Si una relación nombre de host/dirección IP se almacena en
la caché de un servidor DNS y llegan otras consultas a ese mismo servidor DNS preguntando
por el mismo nombre de host, el servidor DNS puede proporcionar la dirección IP deseada,
incluso aunque no sea autoritativo para el nombre del host. Dado que los hosts y las
correspondencias entre nombres de host y direcciones IP no son permanentes, los servidores
NDS descartan la información almacenada en caché pasado un cierto periodo de tiempo.

1.2.3 Registros y mensajes DNS

Los servidores DNS que implementan conjuntamente la bbdd distribuida DNS almacenan los
registros de recursos(RR), incluyendo los que proporcionan las correspondencias entre nombre
de host y dirección IP. Cada mensaje de respuesta DNS transporta uno o más registros de
recursos.

Un registro de recurso está formado por los siguientes cuatro campos:

Roberto Vélez Gamboa <!10> TCP/IP

 CURSO:2020/2021

TTL es el tiempo de vida del registro de recurso; determina cuándo un recurso debería ser
eliminado de una caché.

• Si Tipo = A, entonces nombre es un nombre de host y valor es la dirección IP

correspondiente a dicho nombre. Por tanto, un registro de tipo A proporciona la
correspondencia estándar nombre de host-dirección IP.

• Si tipo = NS, entonces nombre es un dominio y valor es el nombre de host de un servidor DNS
autoritativo que sabe cómo obtener las direcciones IP de los hosts del dominio. Este
registro se utiliza para enrutar las consultas DNS a lo largo de la cadena de consultas.

• Si tipo = CNAME, entonces valor es un nombre de host canónico correspondiente al alias

especificado por Nombre. Este registro puede proporcionar a los hosts que hacen consultas
el nombre canónico correspondiente a un nombre de hosts.

• Si tipo = MX, entonces valor es el nombre canónico de un servidor de correo que tiene un
alias dado por nombre. Los registros MX permiten a los nombres de hosts de los servidores
de correo tener alias simples.

Si un servidor DNS es autoritativo par aun determinado nombre de hosts, entonces el servidor
DNS contendrá un registro de tipo A para el nombre de host. Si un servidor no es
autoritativo para un nombre de host, entonces el servidor contendrá un registro de tipo NS
para el dominio que incluye el nombre de hosts; también contendrá un registro de tipo A que
proporcione la dirección Ip del servidor DNNS en el campo valor del registro NS.

Mensaje DNS

La semántica en los distintos campos de un mensaje DNS es la siguiente:

• Los primeros 12 bytes corresponden a la cabecera, la cual contiene varios campos. El

primero identifica la consulta, este identificador se copia en el mensaje de respuesta lo
que permite establecer correspondencias correctas entre las respuestas recibidas y las
consultas enviadas. En el campo indicadores se incluyen una serie de indicadores, por
ejemplo para saber si es respuesta o consulta.

• La sección cuestiones contiene información acerca de la consulta que se va a realizar. Esta

sección incluye un campo de nombre que contiene el nombre que se va a consultar y un campo
de tipo que especifica el tipo de cuestión que se plantea acerca del nombre.

• En una respuesta de un servidor DNS, la sección respuestas contiene los registros del
recursos para el nombre que fue consultado.

• La sección autoridad contiene registros de otros servidores autoritativos.

• La sección información adicional contiene otros registros útiles.

Roberto Vélez Gamboa <!11> TCP/IP

 CURSO:2020/2021

Inserción de registros en la base de datos DNS

Lo primero que seguramente deseará hacer es registrar el nombre de dominio networkutopia.com

en un registro. Un registrador es una entidad comercial que verifica la unicidad del nombre
de dominio, lo añade a la bbdd DNS y percibe unas pequeñas tasas por sus servicios.

Al registrar el nombre de dominio networkutopia.com en alguna entidad registradora, también

tendrá que proporcionarle los nombres y direcciones IP de sus servidores DNS
autoritativos principal y secundario. Para cada uno de estos dos servidores DNS
autoritativos, el registrador se asegura de que se introduzca un registro de tipo NS y un
registro de tipo A en los servidores TLD. La entidad registradora deberá insertar los
siguientes dos registros de recursos en el sistema de DNS:

También tendrá que asegurarse de que el registro de recurso de tipo A para su servidor web
www.networkutopia.com se ha introducido en sus servidores DNS autoritativos.

Una vez que haya completado estos pasos, los usuarios podrán visitar su sitio web y enviar
correos electrónico a los empleados de su empresa.

Roberto Vélez Gamboa <!12> TCP/IP

 CURSO:2020/2021

1.3 DISTRIBUCIÓN DE ARCHIVOS P2P

Una aplicación P2P muy corriente, distribuye un archivo de gran tamaño desde un único
servidor a muchos otros hosts.

Escalabilidad de las arquitecturas P2P

En una arquitectura P2P, el tiempo mínimo de distribución no solo siempre es menor que el
tiempo de distribución en la arquitectura cliente-servidor; también es menor que una hora
para cualquier número de N pares. Por tanto, las aplicaciones que emplean arquitectura P2P
pueden auto-escalarse. Esta escalabilidad es una consecuencia directa de que los pares
actúan a la vez como redestribuidores y consumidores de bits.

BitTorrent

BitTorrent es un protocolo popular P2P par ala distribución de archivos. En la jerga de

BitTorrent, la colección de todos los pares que participan en la distribución de un
determinado archivo se conoce como torrent. Los peers de un torrent descargan fragmentos del
mismo tamaño del archivo de uno a otro, siendo el tamaño típico 256Kb. Cuando un par se une
por primera vez a un torrent, no tiene fragmentos del archivo. A lo largo del tiempo va
acumulando cava vez más fragmentos. A la vez que descarga fragmentos, actualiza fragmentos
en otros pares. Una vez que un par ha adquirido el archivo completo, puede abandonar el
torrent o permanecer en el mismo y continuar suministrando fragmentos a otros pares. Además,
cualquier par puede abandonar el torrente en cualquier instante con solo un subconjunto de
fragmentos y volver a unirse más tarde.

Cada torrent tiene un nodo de infraestructura denominado tracker(rastreador). Cuando un par

se une a un torrent, se registra mediante el tracker y, periódicamente, informa de que
todavía se encuentra en el torrent. De esta manera, el tracker sigue la pista a los pares
que están participando en el torrent.

Roberto Vélez Gamboa <!13> TCP/IP

 CURSO:2020/2021

Cuando un nuevo par, Alicia, se une al torrent, el tracker selecciona de forma aleatoria un
subconjunto de pares del conjunto de peers participantes y envía las direcciones IP de estos
peers a Alicia. Teniendo en su poder esta lista de pares, Alicia intenta establecer
conexiones TCP concurrentes con todos los pares incluidos en dicha lista. Denominaremos a
todos los pares con los que Alicia consigue establecer con éxito una conexión TCP "pares
vecinos". Los pares vecinos de un determinando par irán variando con el tiempo.

En un determinado instante de tiempo, cada par tendrá un subconjunto de fragmentos del

archivo, disponiendo los distintos pares de subconjuntos diferentes. Periódicamente, Alicia
preguntará a cada uno de sus vecinos por la lista de fragmentos de la que disponen.

Si Alicia tiene L vecinos diferentes, obtendrá L listas de fragmentos. Con esta información,
Alicia solicitará los fragmentos que ella no tiene.

Alicia tendrá que decidir que fragmentos pide primero a sus vecinos y en segundo lugar, a
cuales de sus vecinos debe enviar ella los fragmentos solicitados. Para decidir que
fragmentos solicitar, Alicia utiliza una técnica conocida como primero el menos común. De
esta manera, dichos fragmentos se redistribuirán más rápidamente, consiguiendo que el número
de copias de cada fragmento sea aproximadamente igual dentro del torrent.

Para determinar a qué solicitudes debe ella responder, bitTorrent utiliza un algoritmo de
intercambio inteligente.

Roberto Vélez Gamboa <!14> TCP/IP

 CURSO:2020/2021

1.4 FLUJO DE VÍDEO Y REDES DE DISTRIBUCIÓN DE

CONTENIDO

1.4.1 Vídeo por internet

En las aplicaciones con flujos de vídeo almacenado, el medio subyacente es un vídeo
pregrabado como por ejemplo una película. Estos vídeos se almacenan en servidores, y los
usuarios envían solicitudes a los servidores para ver los vídeos a la carta.

Un vídeo es una secuencia de imágenes, que normalmente se visualizan a velocidad constante,

por ejemplo 24 fotogramas por segundo. Una imagen codificada digitalmente y no comprimida,
consta de una matriz de píxeles, codificándose cada pixel mediante una serie de bits que
representan la luminacia y el color. Una característica importante del vídeo es que se puede
comprimir, sacrificando algo de calidad de imagen a cambio de reducir la tasa de transmisión
de bits. Cuanto mayor sea la tasa de bits, mayor será la calidad de la imagen.

La medida de rendimiento más importante para los flujos de vídeo es, la tasa de trasferencia
media de extremo a extremo. PAra poder garantizar una reproducción continua, la red debe
proporcionar a la aplicación de flujos de vídeo una tasa de transferencia media que sea
igual o superior a la tasa de bist del vídeo comprimido.

También podemos usar la compresión para crear múltiples versiones del mismo vídeo, cada una
con un nivel diferente de calidad. Los usuarios pueden entonces decidir qué versión quieren
ver, en función de su ancho de banda.

1.4.2 Flujos de vídeo HTTP y tecnología DASH

En los flujos multimedia HTTP, el vídeo simplemente se almacena en un servidor HTTP como un
archivo normal, con un URL específico. Cuando un usuario quiere ver el vídeo, el cliente
establece una conexión TCP con el servidor y emite una solicitud GET HTTP para dicho URL. El
servidor envía entonces el archivo de vídeo dentro de un mensaje de respuesta HTTP. En el
lado del cliente, los bytes se acumulan en un buffer de la aplicación cliente. En cuanto el
número de bytes en el buffer sobrepasa un umbral predeterminado, la aplicación cliente
comienza la reproducción.

Aunque los flujos HTTP, se han implementado ampliamente en la práctica, presentan una
carencia fundamental: todos los clientes reciben la misma versión codificada del vídeo, a
pesar de las grandes variaciones en cuanto al ancho de vanda disponible para cada cliente.
Esto condujo al desarrollo de un nuevo tipo de flujos de vídeo, una tecnología que suele
denominarse DASH.

En DASH, el vídeo se codifica en varias versiones diferentes, teniendo cada versión una tasa
de bits distinta y, por tanto, un nivel de calidad diferente.

DASH permite que los clientes con diferentes tasas de acceso reciban flujos de vídeo con
tasas de codificación diferentes.

También permite a un cliente adaptarse al ancho de banda disponible, si el ancho de banda

extremo a extremo varía durante la sesión variará la tasa de codificación.

Cada versión del vídeo se almacena en un servidor HTTP, teniendo un URL diferente. Mientras
está descargando segmentos, el cliente también mide el ancho de banda de recepción y ejecuta
un algoritmo de determinación de la tasa de bits, para seleccionar el segmento que debe
solicitar a continuación.

DASH permite, de este modo, que el cliente cambie libremente entre distintos niveles de
calidad.

Roberto Vélez Gamboa <!15> TCP/IP

 CURSO:2020/2021

1.4.3 Redes de distribución de contenido

Para poder afrontar el desafío de distribuir cantidades masivas de datos de vídeo a usuarios
dispersos por todo el mundo, casi todas las principales empresa de flujos de vídeo utilizan
redes de distribución de contenido (CDN). Una CDN gestiona servidores situados en múltiples
ubicaciones geográficamente distribuidas, almacena copias de los vídeos en sus servidores y
trata de dirigir cada solicitud de usuario a una ubicación de la CDN que proporcione la
mejor experiencia de usuario posible. La CDN puede ser una CDN privada, es decir, propiedad
del propio proveedor de contenido o una CDN comercial que distribuya contenido por cuenta de
múltiples proveedores de contenido.

Las redes CDN adoptan normalmente dos posibles filosofías de colocación de sus servidores:

• Introducción profunda. consiste en introducirse en profundidad en las redes de acceso de

los proveedores de servicios Internet (ISP), implantando clústeres de servidores en
proveedores ISP de acceso por todo el mundo. El objetivo es acercarse a los usuarios
finales, mejorando así el retardo percibido por cada usuario y la tasa de trasferencia. La
tarea de mantener y gestionar los clústeres se convierte en un desafío.

• Atraer a los ISP. consiste en atraer a los ISP construyendo grandes clústeres en un número
más pequeño de lugares. Estas CDN suele colocar clústeres en puntos de intercambio de
internet (IXP). El diseño está basado en atraer a los ISP suele tener menos costes de
mantenimiento y gestión, posiblemente a cambio de un mayor retardo y una menor tasa de
trasferencia a los usuarios finales.

Una vez implantados los clústeres, la CDN replica el contenido entre todos ellos. La red CDN
puede no siempre almacenar una copia de cada vídeo en cada clúster, ya que algunos vídeos
solo se visualiza en raras ocasiones o solo son populares en ciertos países.

Funcionamiento de una red CDN

La mayoría de las CDN aprovechan DNS para interceptar y re dirigir las solicitudes.

Un ejemplo simple para ilustrar el modo en que DNS suele participar: Suponga que un
proveedor de contenido, NetCinema, utiliza a una empresa proveedora de servicios CDN,
KingCDN, para distribuir sus vídeos a sus clientes. En las páginas web de NetCinema, cada
uno de los vídeos tiene asignado un URL que incluye la cadena "video" y un identificador del
propio vídeo. Entonces sucederán seis pasos:

1. E l u s u a r i o visita la página web en

NetCinema.

2.Cuando el usuario hace clic sobre el vínculo

http://video.netCinema.com/6y7b23v, el hosts
del usuario envía una solicitud DNS preguntando
por video.netcinema.com.

3.El servidor DNS local del usuario (LDNS),

retransmite la solicitud DNS a un servidor DNS
autoritativo de NetCinema, que observa la
cadena "video" en el nombre de host
video.netcinema.com. Para "transferir" la
consulta DNS a KingCDN, lo que hace el
servidor DNS autoritativo de NetCinema es, en
vez de devolver una dirección IP, enviar al LDNS un nombre de host perteneciente al
dominio de KingCDN.

Roberto Vélez Gamboa <!16> TCP/IP

 CURSO:2020/2021

4. A partir de ese punto, la consulta DNS entra en la infraestructura DNS privada de KingCDN.
El LDNS del usuario envía entonces una segunda consulta, preguntando por el host obtenido
en el punto 4, y el sistema DNS de KingCD termina de devolver al LDNS las direcciones IP
de un servidor de contenido de KingCDN. Es por tanto aquí, dentro del sistema DNS de
KingCDN, donde se especifica el servidor CDN desde el cual recibirá el cliente su
contenido.

5. El LDNS reenvía al host del usuario la dirección IP del nodo CDN encargado de servir el
contenido.

6. Una vez que el cliente recibe la dirección IP de un servidor de contenido de KingCDNm

establece una conexión TCP directa con el servidor situado en dicha dirección IP y
transmite una solicitud GETHTTP para el vídeo deseado.

Estretaegias de selección de clusteres

Uno de los fundamentos de cualquier implantación de una red CDN es la estrategia de

selección de clústeres, es decir, el mecanismo para dirigir a los clientes dinámicamente
hacia un cluster de servidores o un centro de datos pertenecientes a la CDN. La CDN
determina la dirección IP del servidor LDNS del cliente a partir de la búsqueda DNS
realizada por el cliente. Después de determinar esta dirección IP, la red CDN necesita
seleccionar un clúster apropiado, dependiendo de dicha dirección.

Una estrategia sencilla consiste en asignar al cliente el clúster geográficamente más

próximo. Este tipo de solución puede funcionar razonadamente bien para una gran parte de los
clientes. Sin embargo, para algunos clientes la solución puede proporcionar un mal
rendimiento, por que el clúster geográficamente más cercano no es necesariamente el clúster
más próximo en términos de la longitud o el numero des latos de la ruta de red.

Para determinar el mejor clúster para un cliente basándose en las condiciones actuales de
tráfico, las redes CDN pueden, alternativamente, realizar periódicamente medidas en tiempo
real del retardo y del comportamiento de pérdidas entre sus clústeres y los clientes.

1.4.4 Casos de estudio: Netflix, YouTube y KanKan

Netflix

Netflix dispone de un sitio web que se encarga de gestionar numerosas funciones, incluyendo
los registros e inicios de sesión de los usuarios, facturación, etc.

La nube de Amazon se encarga de las siguientes funciones críticas:

• Ingesta de contenidos: Netflix recibe versiones maestras de estudio de las películas y las
carga en hosts situados en la nube de Amazon.

• Procesamiento del contenido: las máquinas de la nube de Amazon generan muchos formatos
distintos para cada película, adecuados para una amplia variedad de clientes de
reproducción. Para cada uno de estos formatos se crea una versión diferente usando DASH.

• Carga de las versiones en su CDN, una vez generadas todas las versiones de una película,
los hosts de la nube de Amazon cargan esas versiones en la CDN de Netflix.

Youtube

Youtube emplea flujos HTTTP, ofreciendo a menudo un pequeño número de versiones distintas de
cada vídeo, cada una con diferente tasa de bits y, correspondientemente, un diferente nivel
de calidad. Youtube no utiliza flujos adaptativos, sino que exige al cliente que seleccione
una versión de forma manual.

Roberto Vélez Gamboa <!17> TCP/IP

 CURSO:2020/2021

Emplea la solicitud de rango de bytes de HTTP para limitar el flujo de datos trasmitidos,
después de precargar una cierta cantidad predeterminada de vídeo.

KanKan

KanKan tiene ahora implantados unos pocos cientos de servidores en China y carga de forma
activa contenido de vídeo en esos servidores. Esta CDN de KanKan juega un papel principal
durante la etapa inicial de transmisión de los flujos de vídeo. En la mayoría de los casos,
el cliente solicita el principio del contenido a los servidores de la CDN y en paralelo pide
contenido a los homólogos. Cuando el tráfico P2P total es suficiente para la reproducción de
vídeo, el cliente deja de descargar de la CDN y descarga sólo de los homólogos. Pero si el
tráfico de descarga de flujos de vídeo P2P pasa a ser insuficiente, el cliente restablece
las conexiones con la CDN y vuelve al modo de flujos de vídeo híbrido CDN-P2P. De esta
manera, KanKan puede garantizar retardos iniciales de arranque cortos, al mismo tiempo que
minimiza la utilización de ancho de banda y de una costosa infraestructura de servidores.

Roberto Vélez Gamboa <!18> TCP/IP

 CURSO:2020/2021

1.5 PROGRAMACIÓN DE SOCKETS: CREACIÓN DE

APLICACIONES DE RED

1.5.1 Programación de sockets con UDP

Veamos ahora la interacción existente entre dos procesos que están comunicándose que usan
sockets UDP. Si se usa UDP, antes de que un proceso emisor pueda colocar un paquete de datos
en la puerta del socket, tiene que asociar en primer lugar una dirección de destino al
paquete. Una vez que el paquete atraviesa el socket del emisor, Internet utilizará la
dirección de destino para enrutar dicho paquete hacia el socket del proceso receptor, a
través de Internet. Cuando el paquete llega al socket de recepción, el proceso receptor
recuperará el paquete a través del socket y a continuación inspeccionará el contenido del
mismo y tomará las acciones apropiadas.

Cuando se crea un socket, se le asigna un identificador, al que se denomina número de

puerto.

El proceso emisor asocia con el paquete una dirección de destino que está compuesta de la
dirección IP del host de destino y del número de puerto del socket de destino. Además se
asocia al paquete la dirección de origen del emisor. Sin embargo, la asociación de la
dirección de origen al paquete no suele ser realizada por el código de aplicación UDP; en
lugar de ello, lo realiza automáticamente el sistema operativo subyacente.

Vamos a utilizar la siguiente aplicación cliente-servidor simple para demostrar cómo

programar un socket tanto para UDP como para TCP:

1. El cliente lee una línea de caracteres(datos) de su teclado y envía los datos al servidor.

2. El cliente recibe los datos y convierte los caracteres a mayúsculas.

3. El servidor envía los datos modificados al cliente.

4. El cliente recibe los datos modificados y muestra la línea en su pantalla.

Roberto Vélez Gamboa <!19> TCP/IP

 CURSO:2020/2021

El nombre del programa cliente es UDPCliente.py y el nombre del programa servidor es

UDPServidor.py.

Para el detalle de los comandos pag. 133 del libro.

1.5.2 Programación de sockets con TCP

TCP es un protocolo orientado a la conexión. Esto significa que antes de que el cliente y el
servidor puedan empezar a enviarse datos entre sí, tienen que seguir un proceso de acuerdo
en tres fases y establecer una conexión TCP. Un extremo de la conexión TCP se conecta al
socket del cliente y el otro extremo se conecta a un socket del servidor. Cuando creamos la
conexión TCP, asociamos con ella la dirección del socket del cliente y la dirección del
socket de servidor. Una vez establecida la conexión TCP, cuando un lado desea enviar datos
al otro, basta con colocar los datos en la conexión TCP a través de su socket.

Roberto Vélez Gamboa <!20> TCP/IP

 CURSO:2020/2021

Para más detalle de los comandos, página 137 del libro.

Roberto Vélez Gamboa <!21> TCP/IP