Investigación para reducir el tráfico internacional - source url

Transcripción

Facultad de Ingeniería
Universidad Diego Portales
Investigación para reducir el tráfico
internacional en la aplicación BitTorrent y
realizar descargas segmentadas desde la
CDN de Youtube.
Nathalia Rebolledo U. y Osvaldo Ceballos O.
Memoria para optar al título de Ingeniero Civil en Informática y
Telecomunicaciones
Profesor guía
Nicolás Boettcher Palma.
Comité
Phd. Diego Dujovne Helman
Phd. Luciano Ahumada Fierro.
Diciembre, 2013
UNIVERSIDAD DIEGO PORTALES
CDN de Youtube.
Memoria para optar al título de Ingeniero Civil en Informática y
Telecomunicaciones
Nicolás Boettcher Palma
Profesor guía
Diego Dujovne Helman
Comité
Luciano Ahumada Fierro
Comité
Diciembre, 2013
Osvaldo : Dedicado a la memoria de Inés Bacho.
Nathalia: Dedicado a la familia Rebolledo Ulloa y a la memoria de Sofía
Rebolledo.
Contenido
Abstract
xv
Resumen
xvii
Capítulo 1 Introducción
1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2. Descripción del problema . . . . . . . . . . . . . . . . . . . .
3
1.3. Descripción de la solución . . . . . . . . . . . . . . . . . . . .
4
1.3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . .
4
1.3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . .
4
Capítulo 2 Estado del arte en Redes P2P
7
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2. Redes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1. Clasificaciones de redes P2P . . . . . . . . . . . . . . .
8
2.3. Historia de las aplicaciones P2P. . . . . . . . . . . . . . . . .
9
2.4. Optimizaciones a P2P . . . . . . . . . . . . . . . . . . . . . .
10
2.4.1. Optimización con colaboración de las ISP . . . . . . .
11
2.4.2. Optimización sin colaboración de las ISP . . . . . . . .
12
Capítulo 3 Características y funcionamiento: BitTorrent
15
3.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2. Funcionamiento general del protocolo . . . . . . . . . . . . . .
16
3.3. Tamaño de división de piezas y sub-piezas. . . . . . . . . . . .
20
3.4. Métodos de BitTorrent. . . . . . . . . . . . . . . . . . . . . .
21
3.4.1. Distribución de los peers. . . . . . . . . . . . . . . . .
21
3.4.2. Método de Canalización. . . . . . . . . . . . . . . . . .
21
3.4.3. Método del Juego Final (End Game). . . . . . . . . .
22
3.4.4. Tit-for-tat. . . . . . . . . . . . . . . . . . . . . . . . .
22
3.4.5. Estrategia de Pareto. . . . . . . . . . . . . . . . . . . .
23
3.5. Algoritmos de BitTorrent: Selección de Piezas. . . . . . . . . .
23
3.5.1. Rarest First Algorithm. . . . . . . . . . . . . . . . . .
23
3.5.2. Random First Pieces.
. . . . . . . . . . . . . . . . . .
24
3.5.3. Choking Algorithms. . . . . . . . . . . . . . . . . . . .
24
3.5.4. Optimistic Unchoke. . . . . . . . . . . . . . . . . . . .
25
v
Capítulo 4 Fundamento Teórico: CDN
27
4.1. Mirrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2. CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . .
30
4.3. La CDN de Google para Youtube. . . . . . . . . . . . . . . .
33
4.3.1. Selección del servidor de video. . . . . . . . . . . . . .
33
4.3.2. Conclusión . . . . . . . . . . . . . . . . . . . . . . . .
35
Capítulo 5 Propuestas e implementación de las soluciones.
37
5.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2. Selección de herramientas y técnicas. . . . . . . . . . . . . . .
38
5.3. Propuestas de mejora para la disminución de Sistemas Autónomos en descargas BitTorrent. . . . . . . . . . . . . . . . . .
42
5.3.1. Solución 1: Traceroute para el filtro ASFB . . . . . . .
43
5.3.2. Implementación del Filtro ASFB mediante Traceroute.
44
5.3.3. Solución 2: Estudio sobre la relación del TTL con los
Sistemas Autónomos. . . . . . . . . . . . . . . . . . . .
47
5.3.4. Resultado del estudio de relación TTL/SA. . . . . . .
48
5.4. Descargador Segmentado desde una CDN . . . . . . . . . . .
52
5.4.1. Geolocalización de los content-servers de Youtbe CDN.
52
5.4.2. Implementación y uso. . . . . . . . . . . . . . . . . . .
57
5.4.3. Resumen. . . . . . . . . . . . . . . . . . . . . . . . . .
60
Capítulo 6 Análisis de Resultados.
61
6.1. Reducción de Sistemas Autónomos ASFB . . . . . . . . . . . .
61
6.1.1. Resultados para el filtro ASFB . . . . . . . . . . . . . .
62
6.2. Cliente de descarga segmentada desde la CDN de YouTube .
65
6.2.1. Análisis. . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.2.2. Resultados. . . . . . . . . . . . . . . . . . . . . . . . .
65
6.3. Implementación y resultado de la unión conceptual: BitTorrent y CDN. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capítulo 7 Conclusiones.
7.1. Trabajo Futuro. . . . . . . . . . . . . . . . . . . . . . . . . . .
Anexo A Análisis detallado del protocolo BitTorrent.
vi
69
75
76
85
A.1. Experiencia 1. . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
A.2. Experiencia 2. . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
A.3. Descripción del protocolo. . . . . . . . . . . . . . . . . . . . .
87
A.3.1. Comunicación con el Tracker. . . . . . . . . . . . . . .
89
A.3.2. Comunicación entre clientes. . . . . . . . . . . . . . . .
92
A.3.3. Análisis de mensajes. . . . . . . . . . . . . . . . . . . .
93
Anexo B Documentación.
97
B.1. Documentación del Desarrollo en Aria2. . . . . . . . . . . . .
97
B.1.1. Archivos y Clases importantes para el desarrollo en Aria2 97
B.2. Control de versiones oficial para Aria2.
. . . . . . . . . . . .
98
B.2.1. Paso a paso. . . . . . . . . . . . . . . . . . . . . . . . .
99
B.3. Compilar Aria2. . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.4. Cómo agregar opciones a Aria2. . . . . . . . . . . . . . . . . . 100
vii
Lista de figuras
1.1. Las 10 aplicaciones de intercambio de archivos más usadas en
América según su uso de ancho de banda. [3] . . . . . . . . .
2
1.2. Tráfico de internet por protocolo en el año 2013 en Estados
Unidos[2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3. Diagrama de división de tareas . . . . . . . . . . . . . . . . .
5
2.1. Topología CDN, P2P Y P4P respectivamente . . . . . . . . .
12
2.2. Ejemplo de P2P sobre 3 ISP . . . . . . . . . . . . . . . . . . .
14
3.1. Diagrama general del proceso del protocolo BitTorrent para
descargar un archivo. . . . . . . . . . . . . . . . . . . . . . . .
18
4.1. Evolución conceptual dada por los mirrors. . . . . . . . . . . .
28
4.2. Arquitectura referencial genérica de una CDN [28]. . . . . . .
30
4.3. Ejemplo de recuperación de un recurso en una CDN. . . . . .
31
4.4. Ejemplo de cacheo en una CDN. . . . . . . . . . . . . . . . .
32
5.1. Historia de commits mensuales del código de Wget [37]. . . .
39
5.2. Historia de commits mensuales del código de Axel [37]. . . . .
39
5.3. Historia de commits mensuales del código de Aria2 [37]. . . .
40
5.4. Diagrama general de los métodos. . . . . . . . . . . . . . . . .
43
5.5. Diagrama para filtro ASFB . . . . . . . . . . . . . . . . . . . .
45
5.6. Esquema para el cálculo de la relación TTL vs SA. . . . . . .
49
5.7. Gráfico de Correlación de Pearson. . . . . . . . . . . . . . . .
50
5.8. Gráfico de Correlación de Spearman. . . . . . . . . . . . . . .
51
5.9. Multilateralización con restricciones de distancia geográfica
para los landmarks usados.
. . . . . . . . . . . . . . . . . . .
55
5.10. Expresión regular para la identificación de la URL del video
en youtube.com . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.1. Prueba T - Intervalo de confianza. . . . . . . . . . . . . . . .
62
6.2. Gráfico de regresión lineal para cantidad de SA totales vs Peers
totales por descarga. . . . . . . . . . . . . . . . . . . . . . . .
63
6.3. Gráfico de dispersión para Tiempo vs SA/Peers. . . . . . . . .
64
6.4. Tiempo de descarga desde 1 a 10 conexiones paralelas, para
todas las variaciones de latencia. . . . . . . . . . . . . . . . .
66
6.5. Gráfico del Throughput en paquetes de entrada para la descarga con una conexión a un server, con latencia l = 1000ms.
67
6.6. Gráfico del throughput en paquetes de entrada para la descarga con una conexión a 6 servers , con latencia l = 1000ms. . .
67
ix
6.7. Gráfico del throughput en paquetes de entrada para la descarga con una conexión a 2 servers , con latencia l = 100ms.
. .
68
6.8. Esquema de la unión ASFB -CDNVideo. . . . . . . . . . . . .
69
6.9. Gráfico de eficiencia BitCDN y BitTorrent.
71
. . . . . . . . . .
6.10. Tiempos de descarga para BitCDN, BitTorrent con ASFB y
x
BitTorrent. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
A.1. Escenario Experimental 1. . . . . . . . . . . . . . . . . . . . .
86
A.2. Escenario Experimental 2. . . . . . . . . . . . . . . . . . . . .
87
A.3. Estructura del fichero .torrent de metainformación . . . . . .
87
A.4. Estructura de la respuesta del tracker
. . . . . . . . . . . . .
90
A.5. Respuesta del Tracker: peers. . . . . . . . . . . . . . . . . . .
91
A.6. Estructura de mensaje Handshake. . . . . . . . . . . . . . . .
93
A.7. Captura de Handshake con Wireshark. . . . . . . . . . . . . .
94
A.8. Estructura de mensaje bitfield . . . . . . . . . . . . . . . . . .
94
A.9. Estructura de mensaje Request. . . . . . . . . . . . . . . . . .
95
A.10.Captura de Request con Wireshark.
. . . . . . . . . . . . . .
95
A.11.Estructura de mensaje Piece. . . . . . . . . . . . . . . . . . .
95
A.12.Mensaje piece en Wireshark. . . . . . . . . . . . . . . . . . . .
95
A.13.Captura de Piece con Wireshark. . . . . . . . . . . . . . . . .
96
Lista de tablas
3.1. Clientes BitTorrent más usados en el año 2011 [22] . . . . . .
16
3.2. Partición de pieza según tamaño del archivo . . . . . . . . . .
20
4.1. URL de descarga de un video de Youtube. . . . . . . . . . . .
34
5.1. Nombre y posición geográfica de los landmarks . . . . . . . .
52
5.2. Distancia y latencia entre los landmarks . . . . . . . . . . . .
53
5.3. Conjunto de servers entregados por la CDN de Youtube a los
landmarks.
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4. Mediciones de latencia di,τ desde los landmarks a los targets.
53
55
5.5. Distancia geográfica estimada entre los landmarks L y los targets τ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.1. Tiempo promedio de descargas . . . . . . . . . . . . . . . . .
64
A.1. Codificación Bencoding
. . . . . . . . . . . . . . . . . . . . .
89
A.2. Tipos de Mensajes BitTorrent. . . . . . . . . . . . . . . . . .
93
xi
Agradecimientos
La presente Tesis es un esfuerzo en el cual, directa o indirectamente,
participaron varias personas. Leyendo, opinando, corrigiendo, teniéndonos
paciencia, dando ánimo, acompañando en los momentos de crisis y en los
momentos de felicidad.
Agradecemos al Profesor Nicolás Boettcher por haber confiado en
nosotros, por la paciencia y por la dirección de este trabajo. Al Profesor
Diego Dujovne por sus comentarios en todo el proceso de elaboración de la
Tesis y sus atinadas correcciones.
Gracias también a nuestros compañeros que muchos de ellos se convirtieron en nuestros amigos, y que nos apoyaron permitiéndonos entrar en su
vida durante estos 6 años de convivir dentro y fuera de la universidad. Gracias también a nuestros amigos en general y a las personas que han estado
ahí siempre, no solo para este año particular si no que, siempre.
A nuestras familias que nos acompañaron en esta aventura que significó
el estudio de ingeniería y que, de forma incondicional, entendieron nuestras
ausencias y nuestros malos momentos.
Gracias a la música, al pasto, al sol, a la playa, al surf y a todas las
cosas culz de la vida.
Gracias totales.
xiii
Abstract
Currently, Bittorrent is one of the most popular file exchange protocols,
strongly influencing the increase in Inter-ISP traffic, augmenting global traffic
costs between ISPs, congestion probability and file download time.
In this work, we propose to reduce the number of AS (Autonomous
Systems) traversed by each Bittorrent data flow. This mechanism would
significantly increase the file download speed and simultaneously reduce the
Inter-ISP international traffic levels, thus generating a win-win situation.
In order to achieve this goal, we propose three techniques: First, to
implement a Bittorrent filter peer to reduce the number of Autonomous
Systemas for each download; the second to implement a download module
from the Youtube CDN using multiple TCP connections and third, to merge both techniques to download files from Bittorrent and Youtube’s CDN
concurrently, providing a massive new file exchange system. As a result, we
obtained a reduction in the number of Autonomous Systems for BitTorrent
data flows together with a better user experience with the combination of
Bittorrent and CDN downloads.
xv
Resumen
BitTorrent es uno de los protocolos más utilizados en la actualidad,
e influye fuertemente en el aumento del tráfico Inter-ISP. El aumento del
tráfico Inter-ISP incrementa los costos asociados al tráfico global de datos
entre proveedores, aumentando en consecuencia la congestión y el tiempo de
descarga de los archivos compartidos con este protocolo.
Con el presente trabajo, se propone la reducción de la cantidad de sistemas autónomos por lo que atraviesa los flujos de datos que se intercambian
entre los usuarios de los clientes de BitTorrent para así mejorar significativamente tanto la velocidad de descarga para los usuarios como reducir el nivel
de tráfico internacional de los proveedores de internet, permitiendo a los dos
actores obtener ventajas.
Para lograr este objetivo, se proponen tres técnicas: la primera de
ellas consiste en implementar un filtro de peers BitTorrent para reducir los
Sistemas Autónomos de cada descarga, la segunda en implementar un módulo de descarga de videos desde la CDN de Youtube utilizando múltiples
conexiones TCP y por último la combinación de ambas realizando descargas
desde BitTorrent y desde la CDN simultáneamente, dando pie a un posible
nuevo sistema de intercambio de archivos multiprotocolo masivo. Como resultado, se obtuvo una disminución del número de Sistemas Autónomos en
las descargas BitTorrent y simultáneamente, una mejora en la experiencia
del usuario al combinar ambos los protocolos.
xvii
Capítulo 1
Introducción
1.1.
Introducción
Este trabajo es el resultado del proyecto de investigación conjunto
de Nathalia Rebolledo y Osvaldo Ceballos, para la reducción del tráfico
internacional producido por el uso del protocolo BitTorrent.
El tráfico de internet ha ido creciendo en forma exponencial [1] a
través de los años. La infrastructura de red ha tenido que ir adaptandose
debido a la fuerte demanda, y su uso se ha diversificado, de manera tal que
las aplicaciones tienen una mayor importancia en el tráfico que el protocolo
de transporte de hipertexto (HTTP) y de archivos (FTP) para los que fue
diseñada la red en sus orígenes. Dos de las aplicaciones que influyen de
manera importante en este aumento de tráfico internacional son BitTorrent
y Youtube [2], en las que se indaga en este trabajo.
1
Por una parte, BitTorrent, es un protocolo que permite realizar descargas de archivos en redes P2P. Estas son redes donde el contenido no está
disponible en la modalidad cliente-servidor, sino que está conformada por
una serie de nodos que se comportan como iguales entre sí, es así como se
crean micro-redes de intercambio de archivos. Este tipo de redes genera alto
tráfico en internet [2] y actualmente BitTorrent es uno de los protocolos de
transferencias más usados en Latinoamérica en tráfico Upstream, Downstream y Aggregate [2]. Como se ve en la Figura 1.1, podemos observar que
es el protocolo de file sharing más usado en el continente americano.
Figura 1.1: Las 10 aplicaciones de intercambio de archivos más usadas en
América según su uso de ancho de banda. [3]
La especificación técnica del protocolo BitTorrent carece de la aceptación de la IETF [4] y en general existe poco desarrollo en la documentación
oficial [5]. Algunas mejoras al protocolo han podido estandarizar sus especificaciones como uTP (también conocido como LEDBAT) [6], sin embargo
BitTorrent posee una carencia importante en este aspecto.
2
Por otra parte, Youtube es una servicio web donde los usuarios suben
videos para ser vistos en línea y se ha convertido en la fuente más grande de
videos en internet. Nació en el año 2005 y fue adquirido por Google en el año
2006, aumentando su alcance significativamente. Hoy en día cuenta con más
de 1000 millones de usuarios y más de 200 millones de videos [7], y junto a
Netflix es el servicio que genera más tráfico, como se observa en la Figura 1.2.
La infraestructura de Youtube ha tenido que responder a la alta demanda
que tiene este servicio. Y es por ello que integra variadas tecnologías para
garantizar una alta disponibilidad [8], entre ellas CDN (Content Delivery
Networks). Las CDN son redes de clase mundial que ayudan a resolver el
problema del tráfico internacional como se verá en el Capítulo 4.
Figura 1.2: Tráfico de internet por protocolo en el año 2013 en Estados
Unidos[2].
1.2.
Descripción del problema
El problema es la cantidad de tráfico internacional e inter sistemas autónomos
que genera P2P, lo que resulta finalmente en la saturación de los enlaces
internacionales por la alta demanda de tráfico que se genera en estas redes
distribuidas. La solución que han tomado algunos proveedores de internet es
establecer políticas restrictivas para reducir o bloquear ilegalmente el tráfico
(traffic shaping) [9], restringiendo la libertad de los clientes. Esta solución
no enfrenta el problema real, sino que lo evita de una manera que entra
en conflicto con las leyes de neutralidad de la red [10], y ocasionando una
disminución en la Calidad de Experiencia (QoE) del usuario .
3
1.3.
Descripción de la solución
Para esta memoria se prepararán 2 soluciones modificando un mismo cliente
de descarga. Uno enfocado a las ISPs y el segundo a los usuarios. Ambas
soluciones poseen un fin en común y en conjunto e integradas darán lugar a
un nuevo paradigma para la descarga de archivos, inexistente a la fecha (ver
Capítulo 7).
Para la implementación enfocada a las ISPs, se pretende reducir el
tráfico internacional generado por el protocolo BitTorrent dándole prioridad
a los nodos correspondientes a los sistemas autónomos más cercanos, de
cuyas conexiones los peers descargan. Con esto se disminuirían los costos de
operación de la red, ya que se vería minimizado el consumo de recursos para
los proveedores. Luego se integrará esta solución a un cliente BitTorrent, y
se evaluará la mejora en cuanto a la cantidad de sistemas autónomos de cada
descarga.
Para la implementación enfocada a los usuarios, se pretende aprovechar
las características que ofrecen las CDN, dado que acercan el contenido a
descargar al usuario final, su alcance es global y su despliegue es coordinado
con las ISP. Para esto se desarrollará un módulo de descarga multisegmentada
de videos de Youtube, introduciendo en este tipo de soluciones un formato
estándar multiprotocolo llamdo Metalink [11], con el fin de mejorar la calidad
de experiencia QoE de los usuarios.
1.3.1.
Objetivo general
Realizar una investigación para la reducción del tráfico internacional
en la aplicación BitTorrent y realizar descargas segmentadas desde
la CDN de Youtube, modificando un cliente de descarga. Para luego
poder descargar videos desde BitTorrent y CDN simultaneamente.
1.3.2.
Objetivos específicos
Debido a que esta tesis es el resultado de implementaciones e investigaciones de dos alumnos, en la Figura 1.3 se pueden observar los objetivos
específicos por separados, y finalmente los objetivos específicos en común.
4
Figura 1.3: Diagrama de división de tareas
5
Capítulo 2
Estado del arte en Redes P2P
2.1.
Introducción
En este capítulo se estudiarán las redes P2P, su historia y su des-
cripción en sus características esenciales y particulares. Posteriormente se
presentarán las optimizaciones planteadas en la literatura para solucionar el
problema del tráfico en redes P2P. La principal razón por la cual se indaga
en estas tecnologías es fundamentalmente para acercar la información, que
es el enfoque al cual se desea llevar la solución propuesta.
2.2.
Redes P2P
P2P es una red donde todos los nodos dentro de ella actúan como
cliente y servidor al mismo tiempo, permitiendo así el intercambio directo
de la información y evitando sobrecargar los servidores, ya que no sólo se
descarga el archivo original, sino que mientras más usuarios tengan el archivo,
más fuentes descargan de él. Dicho de otra forma, en las redes P2P no existen
clientes ni servidores fijos, sino que corresponden a una serie de nodos que
van actuando como iguales entre sí. Estas redes constituyen el sistema de
distribución de contenidos más usado hoy en día en Internet y se calcula
que representan más del 34 % [2] del tráfico de datos de subida de Latino
América en el año 2012.
7
Los avances de la tecnología informática y sus múltiples aplicaciones
en el campo de las telecomunicaciones han ido por delante de normativas y
legislaciones, lo que ha producido en muchas ocasiones un vacío legal. Los
usuarios P2P han sabido tomar ventaja de esto y han buscado la manera de
crear formas de intercambio de archivos, como música, películas, fotografías,
etc. Esto ha contribuido a su masificación.
Las redes P2P gestionan el uso de las tasas de transferencia de los
peers a través de la medición de la conectividad entre ellos; de esta manera se
aumenta el rendimiento en las transferencia de archivos respecto del método
convencional cliente-servidor.
El estado más general de las redes P2P se describe a continuación en
3 etapas:
1. Entrada: Un nodo ajeno a la red se une a ésta. Un nodo cualquiera puede conectarse a múltiples nodos como también recibir nuevas
conexiones.
2. Búsquedas: Un nodo envía un mensaje a los nodos con los cuales está
conectado para buscar archivos. Estos nodos buscan si los archivos
están disponibles de forma local y reenvían el mensaje de búsqueda a
los nodos a los que ellos están conectados. Si un nodo posee el archivo,
inmediatamente contesta al nodo original que lo solicitó.
3. Descarga: La descarga de archivos se hace directamente desde los nodos que contestaron. Si son múltiples nodos, suele partirse el archivo
en diferentes trozos y cada nodo envía uno de éstos, aumentando la
velocidad total de descarga.
2.2.1.
Clasificaciones de redes P2P
Se puede realizar una clasificación acorde a su organización:
Redes Centralizadas: Todos los intercambios de bloques de datos se realizan a través de un único servidor, que sirve de punto de enlace entre
el resto de los nodos, distribuyendo y reenviando la información y
peticiones de los clientes.
8
Redes semicentralizadas: Existe un servidor central que administra los
recursos de ancho de banda, enrutamiento y comunicación entre nodos
pero sin saber la identidad de cada nodo y sin almacenar información
alguna; sólo actúa como coordinador. El resto de los nodos almacena
la información, mejorando de esta forma la escalabilidad de la red.
Redes descentralizadas: Las comunicaciones son directamente de usuario
a usuario con ayuda de uno o varios nodos intermedios (que es otro
usuario) quienes permiten enlazar esas comunicaciones.
2.3.
Historia de las aplicaciones P2P.
En este capítulo se dará a conocer la historia de las aplicaciones que
utilizan estas redes para analizar cuáles son sus diferencias, semejanzas y
entender cómo han ido evolucionando con el paso del tiempo. Ya que su
principal función es el intercambio de archivos, la mayoria de ellos regidos a
los derechos de autor, los problemas legales no estaban al margen.
La primera aplicación P2P fue Hotline Connect, desarrollada en 1997
para el sistema operativo Mac OS por Adam Hinkley. Hotline Connect [12],
era una plataforma de distribución de archivos destinada a empresas y universidades, pero no tardó en servir de intercambio de archivos, incluidos
archivos con derechos de autor y otro tipo de archivos ilegales. El sistema
Hotline Connect estaba descentralizado, puesto que no utilizaba servidores
centrales sino autónomos, donde los archivos se almacenaban en los ordenadores de los usuarios que deseaban funcionar como servidores, y permitían
la entrada al resto de usuarios. En caso de que un servidor se cerrara, no
existía ningún otro lugar del cual seguir descargando ese mismo archivo, y
no quedaba más que cancelar la descarga y reiniciarla desde otro servidor.
Este sistema quedó obsoleto porque cada usuario dependía de un único
servidor en la descarga, y además, porque fue desarrollado fundamentalmente
para un sistema operativo minoritario, como Macintosh en esa época.
9
Luego apareció Napster en 1999, a quién erróneamente se le atribuye
la invención del P2P. Nació como la primera aplicación de este tipo para
el sistema operativo Windows. El hecho de que Napster fuera un servicio
centralizado, lo llevó al cierre. En diciembre de 1999, compañías discográficas
estadounidenses demandaron a Napster causando su cierre en el año 2001.
La diferencia con Hotline Connect era que, aunque la transferencia de los
archivos también se hacía directamente entre dos equipos, Napster utilizaba
servidores centrales para almacenar la lista de equipos y los archivos que
proporcionaba cada uno.
Terminar con las redes centralizadas era relativamente sencillo, pues
bastaba con cerrar el servidor que almacena las listas de usuarios y archivos
compartidos, por lo que se crearon las redes descentralizadas que no dependen de un servidor central, y por tanto no tienen registro de los archivos
intercambiados.
Es así como aparecieron Gnutella, Kazaa, Ares, Ares Lite y una serie
de clientes P2P, que al no tener servidores centralizados, no pueden ser
penalizados legalmente. Otra de las aplicaciones de P2P es BitTorrent, que
fue la primera aplicación que utilizó el protocolo con el mismo nombre. Este
protocolo ha sido uno de los más usados hasta la fecha. Como BitTorrent se
planteó como un protocolo abierto, esto permitió generar una multiplicidad
de clientes (como por ejemplo uTorrent y Vuze).
2.4.
Optimizaciones a P2P
Como se menciona en la introducción, existen varias optimizaciones
a P2P que se han propuesto, probado y en algunos casos implementado.
Estas propuestas se dividen en 2 grupos: los modelos que contemplan el uso
de la infraestructura de las ISP y quienes los ignoran. Utilizando el primer
enfoque, destacan las propuestas de P4P y el uso de Redes de Distribución
de Contenido CDN [13]. En el segundo enfoque se encuentran las ideas no
implementadas aún [14] que evitan la colaboración con los proveedores de internet. Los conceptos fundamentales que están detrás de estas optimizaciónes
son:
1. La distancia entre el seeder (o servidor de descarga dependiendo del
caso) y el leecher (o host que descarga) se refiere a su situación de red,
cuya medición dependerá de la implementación.
10
2. La replicación y/o distribución del contenido, es decir evitar la centralización de los recursos y distribuirlos en la red, ya sea desde granjas
de servidores como de otros peers de una red P2P.
A continuación se procederá a describir la evolución de estas optimizaciones, para el caso concreto del intercambio de archivos.
2.4.1.
Optimización con colaboración de las ISP
Una de las formas de optimización de P2P bajo la colaboración de las
ISP es P4P, cuyo acrónimo es Network Provider Participation for P2P.
P4P no es un protocolo P2P, sino un medio para que los proveedores
de Internet optimicen el tráfico de las redes P2P de sus usuarios. P4P prioriza
los peers inter-ISP sobre los que están fuera de su red. Básicamente se trata
de una optimización de los recursos por parte de los proveedores de internet,
orientados al funcionamiento de este tipo de redes (P2P), que entre otras
cosas les permite optimizar el consumo de ancho de banda inter-ISP, ya que
no es lo mismo ofrecer conexiones con nodos dentro del ISP que tener que
utilizar a nodos de otras redes. Por lo tanto, se optimiza dando siempre
preferencia al tráfico dentro de un misma ISP, y a continuación, preferencia
a los nodos más cercanos[15].
En una red P2P la fuente de los distintos paquetes se selecciona prácticamente al azar, mientras que P4P filtra las peticiones y las redirige al
nodo más cercano de su propia red. Evidentemente, el tráfico dentro de una
misma red es mucho más eficiente que el tráfico entre distintas redes, como
se observa en la Figura 2.1.
A P4P se le denomina también P2P Híbrido. Incluso se ha creado un
grupo de trabajo, denominado P4P Working Group [16], para estudiar la
implementación y desarrollo de este sistema. Son muchos los proveedores de
internet que ya forman parte de este grupo de trabajo, entre ellos Telefónica y
Verizon, que es uno de los principales ISP de EE.UU, proveniente de la fusión
de Bell y GTE. También están integradas en este grupo varias universidades
y empresas del sector [17].
11
Una de las desventajas de P4P es que implica un mayor control del
tráfico de datos por parte de las ISP, y les facilita el poder priorizar ciertos
contenidos o proveedores, entrando en conficto directamente el concepto de
neutralidad de la red. La posibilidad de que los proveedores ISP saquen
provecho de esta situación les permitiría no sólo obtener ingresos de los
usuarios, cosa que ya hacen mediante el cobro de las conexiones, sino también
de los proveedores, al controlar el tráfico entre nodos. Esto es muy relevante,
porque puede significar el favorecer las conexiones a determinados contenidos
o proveedores en detrimento de otros. En la figura 2.1, se puede observar la
topología CDN, P2P Y P4P respectivamente.
Figura 2.1: Topología CDN, P2P Y P4P respectivamente
2.4.2.
Optimización sin colaboración de las ISP
A pesar de que tanto los CDN como P4P ayudan a resolver el problema
del tráfico generado por las redes P2P especialmente por el intercambio de
archivos (BitTorrent), existen varias posturas [18] [19] que consideran que
estas soluciones tienden a plantear un problema ético-moral e incluso legal,
desde el punto de vista de la libertad y los canales de información. En
definitiva, el hecho de que se optimice para utilizar nodos dentro de la ISP
o dentro del mismo Sistema Autónomo también beneficia a los usuarios. El
problema es quién toma la decisión de qué peer utilizar.
12
Este enfoque propone resolver el problema de emparejar peers en una
red P2P minimizando el costo para las ISP. Para ello se dividió el costo en
2 partes: Inter-ISP e Intra-ISP. El costo inter-ISP se refiere a la cantidad de
dinero que una ISP consumidor debe pagar a una ISP proveedor para pasar
su tráfico por internet. Por lo general las ISP mantienen contratos y acuerdos
comerciales entre ellas, para negociar la carga y uso de este tráfico. El más
común de éstas es el basado en el peak del percentil 95 del ancho de banda
usado en los nodos internos de una ISP proveedora. En general reducir el
tráfico inter ISP reduce los costos para las ISP.
Esta optimización no considera los costos individuales o casos particulares de alguna ISP específica, dado que esta información requiere tener
conocimiento de los acuerdos comerciales entre ellas y el estado real de sus
redes, lo que constituye información de alta sensibilidad para estas empresas.
Para minimizar el tráfico inter-ISP (es decir el tráfico de datos entre distintas
ISPs), los algoritmos de emparejamiento deben retornar peers más cercanos
en términos de los que se define como distancia de red, que corresponde al
número de Sistemas Autónomos (que se refiere a un conjunto de redes y
dispositivos router IP que se encuentran administrados por una sola entidad,
como por ejemplo VTR) que debe recorrer la información desde un seeder a
un leecher en una conexión P2P.
Para inferir el camino (path) de los Sistemas Autónomos, se debe
construir un grafo, de los enlaces entre los Sistemas Autónomos donde cada
enlace se anota con un parámetro llamado R-AS que abstrae los acuerdos
comerciales entre 2 sistemas autónomos, sean estos parte de una misma ISP
o no. En las clasificaciones de las relaciones entre los sistemas autónomos
R-AS se definen en 3 categorías: cliente-proveedor (c2p), peer-to-peer (p2p),
y vecino-vecino (s2s). Existen varios algoritmos para inferir y construir los
grafos entre los AS. La gran mayoría estan basados en la información pública
de las tablas BGP y mediciones de traceroute.
13
Para ilustrar lo anterior tomemos como ejemplo el siguiente caso (ver
Figura 2.2): Se tienen cuatro peers conectados en una red P2P, un leecher
que llamaremos L, y tres seeders S1, S2 y S3. Existen tres ISP a las cuales
cada peer se conecta a internet, ISP A, ISP B e ISP C. Tanto S3 como S1
y L se conectan desde Santiago de Chile pero cada uno a las ISP A, B y C
respectivamente, S2 se conecta desde la ISP A desde New York.
Figura 2.2: Ejemplo de P2P sobre 3 ISP
Se puede apreciar en la Figura 2.2 que si L descarga de S1, el costo
InterISP sería menor que si descarga de los 3 seeders juntos.
Como se explica en el Capítulo 1, el propósito de este trabajo es reducir la sobrecarga del tráfico internacional, o al menos InterISP. En cuanto
al protocolo BitTorrent, el intentar llegar a una solución genérica con colaboración de las ISP como plantea P4P o LiteLoad parece poco factible, y si
bien es cierto el P4P Working Group ha implementado la solución en algunas
ISP importantes, la disyuntiva provocada por las leyes de neutralidad de la
red y las diferencias sustanciales en las políticas nacionales de los proveedores hacen que la mejor forma de enfocar la búsqueda de la solución sea sin
colaboración de las ISP.
14
Capítulo 3
Características y funcionamiento: BitTorrent
3.1.
Introducción.
En el año 2001 Bram Cohen crea un protocolo de intercambio de archivos
llamado BitTorrent. Su primera implementación pública fue en julio de ese
año. Desde su creación se han hecho estudios cuyas estadísticas demuestran
que su utilización es masiva [20]. En febrero de 2013, BitTorrent fue el
responsable de un 3,35 % de todo el ancho de banda del mundo, equivalente
a más de la mitad del 6 % del ancho de banda total dedicado a compartir
archivos [3].
Ahora bien, la pregunta que surge es ¿Qué hace a BitTorrent ser
el protocolo P2P más utilizado?. La respuesta es que este protocolo posee
algoritmos y métodos que optimizan el sistema de intercambios de archivos,
los que hacen más rápido este proceso y enriquecen la experiencia del usuario
[21].
El portal TorrentFreak.com, especializado en noticias sobre el mundo
que rodea al BitTorrent, publicó en el año 2011 un ranking con los clientes más usados, con su cuota de mercado y las plataformas en las que se
encuentran disponibles [22].
15
Cuota del
Posición
Cliente
Mercado ( %)
Peers
Plataformas
1
uTorrent
47.97
267.466
Windows, Mac
2
Vuze
22,49
125.417
Windows, Mac, Linux
3
BT Mainline
13,1
72.536
Windows, Mac, Linux
4
Transmission
7,00
39.011
Mac, Linux
5
Unknown
6,22
34.703
na.
6
Liborrent
1,02
5.703
Windows, Mac, Linux
7
BitComet
1,01
5.638
Windows
8
Other
1,27
7.062
na
Tabla 3.1: Clientes BitTorrent más usados en el año 2011 [22]
Como se observa en Tabla 3.1 uTorrent domina ampliamente el mercado para ese año. Luego le sigue no muy de cerca su directo competidor,
Vuze. En Unknown se encuentran los clientes no identificados, y en other
otros clientes BitTorrent como Ares con poca cuota en el mercado.
Para efectos de esta tesis se utilizará Vuze para realizar las primeras
experiencias (Anexo A) ya que este cliente tiene un plugin P4P. Este plugin es una investigación en marcha en el Laboratorio de Sistemas de Red
en la Universidad de Yale para hacer las aplicaciones P2P más rápidas y
más eficientes. En el caso particular de este trabajo, es bueno conocer cómo
trabaja este plugin, ya que tiene funcionalidades similares a la propuesta de
optimización que se planteará. Cabe destacar que para todos los clientes BitTorrent el funcionamiento del protocolo es el mismo, por lo que la propuesta
planteada en esta tesis puede ser implementada en cualquiera de éstos.
3.2.
Funcionamiento general del protocolo
En esta sección se describirá el funcionamiento general del protocolo,
sin profundizar en su mecanismo interno detalladamente. El objetivo de este
protocolo es la transferencia de archivos. La idea fundamental es que todos
los usuarios puedan intercambiar partes del archivo entre sí.
16
El archivo que es distribuido se divide en partes pequeñas las que se
denominan pieces (piezas), y éstas a la vez se dividenen sub-piezas. Cada vez
que un usuario recibe una pieza nueva del archivo, puede a su vez compartirla
con otros usuarios. En BitTorrent, la tarea de distribución es compartida por
todos aquellos que desean tener el archivo.
Existe un número de conceptos referidos a BitTorrent que se utilizarán más adelante en la descripción de los mecanismos del protocolo. Estos
conceptos son los siguientes:
Cliente: Aplicación BitTorrent que se usa para descargar y subir archivos.
Choke: Situación en que un peer A deja de transmitir a otro peer B dejando
sin poder finalizar la descarga a B.
Leech o Leecher: Usuario que se encuentra descargando un torrent.
Peer: Un miembro de un grupo de clientes descargando el mismo archivo.
Pieces: Sección del archivo, ya que éste es dividido en piezas.
Seed: Una copia completa de archivo disponible para la descarga.
Seeder: Un usuario que ya finalizó la descarga y lo pone a disposición para
otros usuarios.
Sub piezas: Sección de un piece.
Tracker: Servidor especial que contiene la información necesaria para que
los peers se conecten unos con otros.
En la Figura 3.1 se observa el proceso general para descargar un archivo
con el protocolo BitTorrent.
17
Figura 3.1: Diagrama general del proceso del protocolo BitTorrent para descargar un archivo.
Primero el usuario debe obtener el archivo .torrent a partir de un web
service (u otro servicio de distribucion de archivos). Este archivo contiene la
dirección URL de él o los trackers. El tracker devuelve una lista al azar de
peers que contienen el archivo y finalmente se procede a descargar las piezas
de los peers de la lista que el tracker retornó.
18
El tracker, que es un servidor centralizado especial del protocolo, es el
responsable de ayudar a los leechers a obtener información de las fuentes que
contienen las piezas del archivo, ya que éste contiene una lista de información
de contacto de los usuarios que están descargando el mismo archivo. Los
usuarios que quieren descargar, obtienen el archivo .torrent y crean otro
nodo BitTorrent que actúa como leecher, intercambiando partes del archivo
con el seeder y con otros peers.
En el caso de que el usuario desee subir un archivo, este debe crear
un archivo con extensión .torrent. Esto se hace a través de cualquier cliente
BitTorrent. Luego de crearlo, el archivo se debe distribuir, ya sea mediante
la web o de cualquier otra forma.
Cada pieza del archivo está protegida por un hash criptográfico contenido dentro del archivo torrent. Esto asegura que cualquier modificación que
se produzca pueda ser detectada, y por lo tanto evita que tanto los cambios
no intencionales como los intencionales sean recibidos por otros peers.
Las piezas no se suelen descargar de forma secuencial. Éstas son reordenadas por el cliente, el que comprueba las partes que ha obtenido y las
que le falta recibir. En el caso particular del streaming con BitTorrent (como
Live Torrent) esto no funciona así, ya que al ser streaming, las piezas deben
ser descargadas secuencialmente [23].
Mientras más seeders contengan un archivo, mayor es la probabilidad
de que un peer pueda descargar el archivo completo más rápido. Comparado
con los esquemas de distribución tradicionales, esto permite al distribuidor
original reducir los costos de infraestructura y de ancho de banda. Esto también proporciona redundancia ante posibles problemas del sistema, reduce
la dependencia con el distribuidor original y proporciona fuentes de descarga transitorias (no son siempre los mismos usuarios los que comparten el
archivo).
19
3.3.
Tamaño de división de piezas y sub-piezas.
El protocolo BitTorrent no define estrictamente el tamaño de división
de las piezas. Esto va a depender de cada cliente generador del archivo
.torrent (el que crea el archivo). Sin embargo por lo general, un torrent tiene
alrededor de 1000-1500 piezas; la división del archivo en un número mayor
de piezas ayuda a una descarga más rápida del archivo.
Según la literatura, el tamaño de la pieza más común suele ser se
256 KB y sub-piezas de 16 KB [24], que corresponden a las más pequeñas
unidades reales de transmisión en el protocolo BitTorrent. Esto da lugar a
“la transmisión en curso” de cantidades de datos (piezas sin terminar) para
cada cliente.
Entonces, analizando el sistema de división de piezas, los clientes
deben considerar que piezas demasiado grandes causan ineficiencia y piezas
demasiado pequeñas forman un archivo .torrent más pesado. En la Tabla 3.2
se puede ver el patrón aproximado que los clientes que generan el archivo
.torrent, siguen para la división de las piezas.
Tamaño del Archivo
Tamaño de la Pieza
Hasta 50 MB
32 KB
de 50 MB a 150 MB
64 KB
de 150 MB a 350 MB
120 KB
de 350 MB a 512 MB
256 KB
de 512 MB a 1.0 GB
512 KB
de 1.0 GB a 2.0 gb
1024 KB
2.0 GB o más
2048 KB
Tabla 3.2: Partición de pieza según tamaño del archivo
Este sistema de división de piezas no es general, ya que como fue
antes mencionado no existe uno como tal. Dos clientes que generan archivos
.torrent distintos pueden dividir el mismo archivo en distintos tamaños de
piezas y sub-piezas, pero todos se aproximan a los valores de la Tabla 3.2.
20
3.4.
Métodos de BitTorrent.
Bittorrent posee una serie de métodos y algoritmos que utilizan para
su funcionamiento. Uno de ellos es por ejemplo, su sistema de distribución,
donde se utiliza Tit-for-tat (Subsección 3.4.4) como método de búsqueda de
la eficiencia de Pareto (Subsección 3.4.5). Esto alcanza una mayor robustez
y optimización de recursos que la mayoría de las otras técnicas.
La estrategia para la asignación de carga que parece dejar a los peers
más satisfechos con sus tasas de descarga, es hacer que la tasa de descarga de
cada peer sea proporcional a su tasa de subida. En la práctica es muy difícil
evitar que las tasas de descargas no se vayan a cero, y mucho más difícil
aún hacer que las tasas de descarga y subida estén correlacionadas. Aún así,
existen formas de solucionar estos problemas, las que serán explicadas en
esta sección.
3.4.1.
Distribución de los peers.
Todos los problemas logísticos de la descarga de archivos se manejan
en la interacción entre peers. Parte de la información sobre las tasas de carga
y descarga se envían al tracker para la recopilación de estadísticas.
Las responsabilidades del tracker están estrictamente limitadas a ayudar a los peers a encontrarse, ya que es la única forma y el único punto de
coordinación y el algoritmo estándar del tracker para llevar a cabo dicha responsabilidad, es retornar una lista aleatoria de peers. La cantidad de peers
que devuelva va a depender de cada tracker. Generalmente, cuando el archivo que se quiere bajar es de caracter masivo (muchos usuarios lo poseen), el
tracker proporciona 50 peers activos, mientras que el cliente busca mantener
conexiones con 20-40 peers. Si alguna vez un cliente no puede mantener al
menos 20 conexiones, vuelve a hacer una consulta al tracker para obtener
peers adicionales [25].
3.4.2.
Método de Canalización.
Cuando la transferencia de datos es a través de TCP, como BitTorrent,
es importante tener siempre varias solicitudes pendientes a la vez, para evitar
un retraso entre las piezas que se envían, lo cual perjudica a las tasas de
transferencia. BitTorrent facilita esto rompiendo los pedazos en sub-piezas,
cada vez que llega una sub-pieza se envía una nueva petición.
21
3.4.3.
Método del Juego Final (End Game).
Este modo empieza al final de la descarga de la última pieza, cuando
el peer pide todas las sub-piezas que todavía no han sido recibidas a todos
los peers de su conjunto de peers que tienen esas sub-piezas. Cada vez que
se recibe una sub-pieza, el peer cancela la petición para la sub-pieza recibida
a todos los peers en su conjunto de peers que tienen la petición activa.
3.4.4.
Tit-for-tat.
Esta estrategia la ocupa BitTorrent para buscar la eficiencia de Pareto,
la cual se expresa en el denominado “Choking Algorithm”, por lo que es bueno
saber de dónde proviene y qué es lo que hace.
En [26] se demuestra el valor de la estrategia Tit-for-tat para asegurar
el éxito a largo plazo y establecer las condiciones necesarias para la cooperación. El autor del libro invitó a especialistas en Teoría de Juegos a enviar
estrategias que serían comparadas una con la otra por medio de simulación
en una computadora, explorando el Dilema del Prisionero. La estrategia ganadora fue la de Tit-for-tat que es la estrategia en la cual se coopera en el
primer movimiento y luego se actúa de la misma forma en la que el oponente
respondió.
Se identificaron cuatro características que condujeron al éxito de Titfor-tat:
Evitar conflicto innecesario cooperando mientras que el otro haga lo
mismo.
Responder a la provocación ante la traición del otro.
Perdón después de responder a una provocación.
Claridad de comportamiento de manera que el otro jugador pueda
adaptarse al patrón de acción del oponente.
22
3.4.5.
Estrategia de Pareto.
Las teorías económicas muestran que el sistema de Pareto es eficiente,
lo que significa que no hay dos contrapartes, ya que pueden hacer un intercambio y las dos partes reciben lo que quieren. En términos informáticos,
la eficiencia de Pareto es un algoritmo de optimización local en el que parejas de contrapartes ven si pueden mejorar su situación en conjunto, y este
tipo de algoritmos tienden a conducir a óptimos globales. En concreto, si
dos peers están recibiendo una reciprocidad pobre por parte de la carga que
están ofreciendo, ellos pueden ofrecer iniciar una descarga del uno al otro y
los dos tendrán una mejor tasa de descarga.
El Choking Algorithm de BitTorrent trata de lograr la eficiencia de
Pareto utilizando una versión de Tit-for-tat, explicada en la Subsección 3.4.4.
Los peers actúan recíprocamente subiendo data a los peers que le suben data
a ellos con el objetivo de tener varias conexiones que se están transfiriendo
activamente en ambas direcciones.
3.5.
Algoritmos de BitTorrent: Selección de Piezas.
La selección de piezas para descargar es muy importante para un buen
rendimiento. Un pobre proceso de selección de piezas puede resultar en no
obtener ninguna pieza.
La primera política de selección de piezas de BitTorrent es que una vez
que una sola sub-pieza ha sido solicitada, se piden las restantes sub-piezas
de esa misma pieza antes de cualquier otra. Con esto se consiguen piezas
completas tan pronto como sea posible.
3.5.1.
Rarest First Algorithm.
Cuando se elige qué pieza se utilizará para iniciar la siguiente descarga,
los peers generalmente descargan piezas con una menor cantidad de peers, a
esta técnica se le denomina Rarest First, y funciona de la siguiente manera:
Cada peer mantiene una lista con el número de copias de cada pieza del
archivo requerido presente en el sistema. Esta lista se actualiza cada vez
que una pieza se copia a un usuario presente en el conjunto de pares. Esta
información ayuda a los clientes a decidir qué cantidad es la más rara y la que
debe ser adquirida. Cada peer selecciona la siguiente pieza para descargar
random en su conjunto de piezas más raras [27].
23
3.5.2.
Random First Pieces.
Una excepción de Rarest first algorithm, es cuando se inicia la descarga. En ese momento, el peer no tiene nada que cargar, así que es importante
conseguir una pieza completa lo antes posible. Por esta razón, las piezas a
descargar son seleccionados al azar hasta que la primera pieza se complete,
y luego la estrategia cambia a Rarest First Algorithm.
3.5.3.
Choking Algorithms.
BitTorrent no tiene una asignación central de recursos, cada nivel es
responsable de tratar de maximizar su propia velocidad de descarga. Para
cooperar, los peers suben contenido y para no cooperar ellos utilizan lo que se
denomina choke. Esta es una pausa temporal de subida, pero aún así pueden
seguir descargando y la conexión no necesita ser regenerada cuando el choke
se detenga.
Choking Algorithm técnicamente no es parte del protocolo de BitTorrent, pero es necesario para un buen rendimiento. Un buen Choking
Algorithm debe utilizar todos los recursos disponibles. Ofrecen velocidades
de descarga razonablemente consistentes para los peers que sólo descargan y
no suben contenido.
Este algoritmo se usa para garantizar una buena relación subida/bajada entre los peers. Por ejemplo, los peers que no cargan deben penalizarse.
El algoritmo se describe desde el punto de vista del peer local. Por lo tanto, “interesado” significa interesado en el peer local y “bloqueado” significa
bloqueado por el peer local.
El algoritmo es el siguiente:
4 peers remotos pueden estar bloqueados e interesados a la vez como
máximo.
Cada 10 segundos, los peers remotos interesados se ordenan de acuerdo a su velocidad de bajada hacia el peer local y los 3 más rápidos
son desbloqueados. Esto evita el desperdicio de recursos y agiliza el
funcionamiento de TCP.
Cada 30 segundos, un peer interesado adicional se desbloquea aleatoriamente. Esto se llama "Desbloqueo Optimista"(Optimistic Unchoke).
24
3.5.4.
Optimistic Unchoke.
El desbloqueo optimista tiene dos objetivos: permite evaluar la capacidad de bajada de nuevos peers en el conjunto de peers y también posibilita
que los peers que no tienen ninguna pieza que compartir puedan obtener su
primera pieza.
Descargar sólo de los peers que tienen una mejor tasa de descarga
podría ser perjudicial por el hecho de que ese peer podría sobrecargarse,
habiendo otras conexiones, quizás no con su misma tasa de descarga pero
con menos peticiones. Para solucionar este problema, en todo momento un
peer BitTorrent tiene un “desbloqueo optimista”, que es un desbloqueo del
peer independiente de la tasa de descarga que éste posea.
Cada peer del desbloqueo optimista es rotado a cada 30 segundos, que
es el tiempo suficiente para que la carga se ejecute con toda su capacidad.
Esto es recíproco con la descarga.
25
Capítulo 4
Content Delivery Networks.
Las Redes de Distribución de Contenido son una solución relativamente
moderna [28] que nació para resolver variados problemas que aquejaban a los
sitios de principios del 2000. En este capítulo se estudiará su funcionamiento
como estado del arte, partiendo por la explicación de su antecesor conceptual,
los mirrors, hasta el detalle de una CDN específica como la de Google para
Youtube.
4.1.
Mirrors
Los Mirrors son sitios de descarga que replican en la totalidad otro
sitio (ver Figura 4.1), para obtener una serie de beneficios, como evitar que se
sobrecargue un servidor único que entrega el contenido y acercar el contenido
al cliente final reduciendo la latencia y los cuellos de botella provocados por
el tráfico internacional, y en algunos casos mejorando la experiencia del
usuario.
27
Figura 4.1: Evolución conceptual dada por los mirrors.
La tecnología usada es bastante antigua, pues se basa en las capacidades de los discos de almacenamiento de configurarse en RAID, tecnología de
los años 80, pero replicando esto a internet, duplicando los servidores FTP
de origen. Básicamente, los algoritmos de sincronización y la verificación
del estado y versión de los archivos se efectúa a través de comparaciones
de un hash, que es frecuentemente MD5. Los mirrors nacieron por la alta
demanda que empezaron a tener algunas distribuciones de GNU/Linux en
los años 90, que eran mantenidas por comunidades que no podían financiar
grandes velocidades de acceso para sus servidores y por lo que de manera
social empezaron a recibir ayuda de otras comunidades y universidades de
todo el mundo, levantando una política estándar para hacer mirroring.
Hoy en día destacan en el uso de esta tecnología las distribuciones
Linux, sourceforge.org, eclipse SDK entre otros. Se han incorporado algunas
mejoras al modelo tradicional, como por ejemplo el uso de protocolos híbridos TCP/UDP para las descargas, o selectores automáticos de mirrors más
cercanos utilizando geolocalización por IP.
4.2.
CDN
Las redes de distribución de contenido (CDNs) son una evolución
natural del concepto de mirroring, el DNS caching, y el content caching de
los navegadores, entre otras tecnologías. Están orientadas a satisfacer todo el
mercado de internet cambiando por completo la forma topológica de la red
mundial.
28
Los usuarios con altas velocidades de conexión con frecuencia veían
empobrecido su rendimiento con interrupciones de conexión, alta latencia, y
baja calidad de experiencia. Esto se debe a que al estar almacenados en un
servidor de hosting único, la sobrecarga en los enlaces y del servicio mismo,
sumado a la latencia propia de las distancias que debe cruzar la información,
reducen considerablemente la calidad de servicio.
Las CDN minimizan los problemas de latencia, jitter, optimizan las
velocidades de distribución y maximizan el ancho de banda disponible para
cada usuario [29]. Estas redes usan múltiples servidores en varias locaciones
geográficas para mejorar el rendimiento de la distribución de contenido,
tanto estático como dinámico (streaming). Las consultas y requerimientos de
los usuarios de internet son dirigidos automáticamente a los servidores más
cercanos [30], mejorando la velocidad de descarga de los componentes de las
páginas y servicios web, y maximizando el ancho de banda de las conexiones,
proveyendo contenido idéntico sin importar la saturación de tráfico de los
enlaces de del sitio original. Dependiendo del tráfico y del número de nodos,
los algoritmos de red seleccionan la mejor opción de ruteo para entregar un
desempeño óptimo y evitar los cuellos de botella.
La arquitectura de las CDN (ver Figura 4.2) fue desarrollándose en
forma paulatina, basándose en la necesidad de contar con un sistema global
de “Alta Disponibilidad”. Sus principales servicios son soportados por esta
combinación de tecnologías.
29
Arq.pdf
Figura 4.2: Arquitectura referencial genérica de una CDN [28].
4.2.1.
Funcionamiento
Cuando un navegador hace una solicitud por un recurso en una red
tradicional (sin CDN), el primer paso es hacer una solicitud a un DNS server
para consultar por la IP del dominio en cuestión. Cuando éste obtiene la
IP, el navegador se puede conectar directamente con el servidor web donde
está hospedada la aplicación. Para los requerimientos y consultas posteriores
existen múltiples capas de DNS caching que permiten resolver los dominios
de manera rápida y cómoda para el usuario final, dado que es un servicio
transparente para el usuario este rara vez se percata.
30
En el caso de que un navegador haga una solicitud a un DNS para
un dominio que es manejado por una CDN, el servidor DNS responderá
con la IP de un servidor DNS dentro de la red de la CDN. Esta tratará de
entregar el mejor conjunto o subconjunto de servidores que puedan manejar
esa consulta, es decir el DNS server de la CDN, hace una búsqueda geográfica
basada en la IP del consultor y la dirección IP de un edge server que esté
más cerca de esa área (ver 4.3). Hay que tomar en cuenta que las compañías
proveedoras pueden optimizar las CDN para resolver las IP por otros factores,
por ejemplo redirigir a un servidor que es más barato en la resolución del
recurso, o bien por balanceo de carga [13].
Para acceder al contenido se utilizan los edge servers, que son proxy
cachés que funcionan de forma similar al caché de los navegadores. Cuando
un requerimiento de un recurso llega a un edge server se realiza el siguente
proceso: Primero verifica que el contenido está disponible en caché, si el
contenido se encuentra en caché y no ha expirado, entonces el contenido se
sirve directamente desde el edge server sin llegar la consulta a el web server
donde estaba originalmente almacenado el recurso llamado origin server. Es
importante aclarar que las CDN sirven contenido web y no la página en sí,
5
Edge server 1
youtube.com/watch?v=T9peaJJAyso
r9.sn-x1x7sne7.c.youtube.com: type A, class IN, addr {edge server 2 addr}
por lo que la consulta por la página llega de igual forma al origin server.
1
4
Si no está en caché
youtube.com
Edge server 2
DNS de la
CDN
3
Edge server 4
Edge server 3
Auth DNS
Local DNS
youtube.com: type A, class IN, addr {youtube.com addr}
2
CNAME youtube.com: type A, class IN
Figura 4.3: Ejemplo de recuperación de un recurso en una CDN.
31
Por otro lado, si el contenido no se encuentra en caché, la entrada en
el caché ha expirado, o bien ha vencido su cuota de expiración. Entonces, el
edge server hace una solicitud al origin server para recuperar la información.
Cuando los edge servers reciben la información nueva, actualizan el caché
y la expiración del contenido. En la Figura 4.4 se observa cómo peticiones
subsiguientes se resolverán al nivel de los edge servers.
Figura 4.4: Ejemplo de cacheo en una CDN.
El sistema de cacheo, balanceo de cargas y proxy más usado es Apache
Traffic Server y sus respectivas modificaciones. Los servicios más importantes
de estas redes de distribución de contenido son: Akamai, Amazon CloudFront,
BitGravity, CacheFly, CDNetworks, CloudFlare, EdgeCast, EdgeStream,
Limelight Networks, Google CDN, LocalMirror, MaxCDN, Mirror Image,
Panther Express y CoralCDN.
Las CDNs han extendido su uso tanto geográficamente como en la multiplicidad e importancia de servicios que las ocupan o implementan (Google,
Facebook, Vimeo). Es por ello que se decide utilizar la ya optimizada plataforma que ofrecen para obtener archivos o material desde ellas. En particular,
interesa la capacidad de redirigir el tráfico y la demanda acercándolo a los
hosts, por lo que cualquier solución que aproveche esta capacidad puede
obtener los beneficios de su eficiencia.
En particular, la extensión de los servicios de Google y lo masivo de su
uso, convierten esa red en el mejor motor de uso cotidiano y comercial para
probar el alcance de las tecnologías de estas redes. A continuación se detallan
las características de la CDN de Google para la aplicación de visualización
de videos youtube.com.
32
4.3.
La CDN de Google para Youtube.
Youtube es el sitio de compartimiento de videos más popular en el
mundo [31], y es un referente respecto al uso de tecnología de las CDN.
Desde que Google lo adquiriera en el 2006, ha crecido no sólo en cantidad
de usuarios sino que también en tecnología, cambiando y actualizándose
constantemente. Estos elementos apoyan la decisión de implementar una
aplicación de descarga segmentada desde una CDN, usando a Youtube como
base, ya que es un excelente ejemplo de uso y extensión de la capacidad de
las Content Delivery Networks.
4.3.1.
Selección del servidor de video.
La URL de un video de youtube es (usualmente) del tipo http://
www.youtube.com/watch?v=XXXXXXXXXXX. A diferencia de otros servicios
de CDN, la petición de un video no va a un origin server, sino que a lo que
Google llama front-end servers [32], que corresponden a clusters de resolución
rápida que resuelven el brokering (que es la interoperación entre CDNs [33])
y el ruteo a los edge-servers que son parte de la CDN de Google, donde
se encuentra el contenido buscado. La descarga se realiza desde este edge
server abriendo una conexión TCP paralela a la del front-end server. Otra
particularidad interesante es que la URL es personalizada por la IP del cliente
[34].
A continuación se muestra un ejemplo de una URL de descarga (ver
Tabla 4.1), se debe tener en cuenta que estas URLs son dinámicas y cambian
su formato con relativa regularidad, por lo que se aconseja al lector verificar
el formato.
33
http://r1—sn-8ug-njal.c.youtube.com/videoplayback?
ms=au
expire=1382527201
source=youtube
upn=QzFvdYmyt8I
mv=m
id=a4a53ea1c45d41e6
cp=U0hXR1VNVV9FS0NON19NR1lDOmNtQ1Z0cjRPcDhW
ratebypass=yes
fexp=922217 %2C924397 %2C924616 %2C924610 %2C907231
sver=3
sparams=cp %2Cid %2Cip %2Cipbits %2Citag %2Cratebypass
%2Csource %2Cupn %2Cexpire
ipbits=8
itag=43
key=yt5
ip=190.163.70.30
mt=1382500889
signature=8295E4DD8849F027A78F75EBA5A2399DF68E097D
24854A46A12408B8D99F3C063713AA7DC2BB336E
Tabla 4.1: URL de descarga de un video de Youtube.
Ahora bien, la información requerida se solicita a un servidor de
caché. Estos tienen la siguiente estructura de nombres para la URL: v[124].cache[1-8].c.youtube.com. Nótese que la consulta también puede ser dirigida a un servidor físico de una granja edge cercana (llamados por Google Content Servers), cuya estructura de nombres es
r[1-20].CODIGO-
CIUDAD.c.youtube.com .
En particular el sufijo o dominio pricipal puede variar de c.youtube.com
a googlevideo.com pero ambos dominios se referirán siempre a la misma IP
puesto que lo que determina el server es el prefijo. Existen referencias [35]
que tratan de identificar el patrón de nombres de los content-servers pero
sus resultados son parciales. Sin embargo se puede saber que se trata de
posiciones geográficas específicas, por lo que se puede hablar de redundancia
de servers para un “site”.
34
4.3.2.
Conclusión
Las CDN son una tecnología en uso, que posee interesantes caracteristicas de cara a la implementación de clientes de descarga, tanto las descargas
directas como los protocolos P2P (como BitTorrent) pueden verse beneficiados si se aprovechan de la capacidad de servir contenido a alta velocidad
desde un sitio geográfico cercano a los clientes.
35
Capítulo 5
Propuestas e implementación de las soluciones.
.
5.1.
Introducción.
Para alcanzar el objetivo principal de este proyecto, que consiste en contribuir a la reducción del tráfico internacional para la aplicación BitTorrent, se
implementará un filtro para descargar de los peers a menos Sistemas Autónomos de distancia, que para efectos de esta tesis se denominará filto ASFB .
Además de implementar un descargador de video de Youtube y realizar descargas segmentadas desde la CDN en el mismo cliente de descarga, con el fin
de realizar descargas desde un mismo cliente a dos protocolos distintos simultáneamente (CDN y BitTorrent). Estas son las propuestas planteadas que a
lo largo de este capítulo se analizarán detalladamente; además se analizarán
las herramientas a utilizar y las metodologías para su implementación.
37
5.2.
Selección de herramientas y técnicas.
Dado que las mejoras propuestas deben ser implementadas en un cliente,
existen a priori opciones a considerar: La primera es implementar un cliente
propio y la segunda es modificar un cliente de descarga de código abierto para
incluir la propuesta de la Subsección 5.3. Por razones de eficiencia, costo y
alcance de este trabajo, se decidió utilizar una herramienta de descarga open
source minimalista, sin interfaz gráfica llamada Aria2. Para la elección de la
herramienta se analizaron alternativas más importantes, respecto a clientes
de descarga open source, sin interfaz gráfica.
.
Wget
GNU Wget [36] es un paquete de software libre creado en 1999 que se utiliza
para descargar archivos remotos usando los protocolos más utilizados en la
red, tales como HTTP, HTTPS y FTP. Es una herramienta no interactiva
que se ejecuta desde una línea de comandos, por lo que puede integrarse
fácilmente con scripts y procesos gestionados en un sistema operativo tipo
UNIX (como GNULinux o MAC OSX).
Entre sus características destacables de encuentran:
Puede resumir descargas abortadas previamente.
Puede utilizar meta-caracteres y expresiones regulares para hacer mirroring de sitios FTP completos.
Convierte opcionalmente enlaces absolutos en enlaces relativos, de manera que los links entre los archivos descargados sigan funcionales
cuando se ejecuten localmente.
Soporta proxies HTTP.
Soporta cookies HTTP.
Soporta conexiones HTTP persistentes.
Puede operar como demonio, de fondo o desatendido.
Puede hacer comparaciones de timestamp entre archivos para mantener
la sincronía cuando se hace mirroring.
38
Figura 5.1: Historia de commits mensuales del código de Wget [37].
En la Figura 5.1 se observa el nivel de desarrollo que ha tenido este proyecto
a lo largo del tiempo y su estado de actividad o abandono actual. Wget es un
proyecto de software con una larga trayectoria, correctamente mantenido y
documentado por la FSF (Free Software Foundation), sin embargo el hecho
que no permita conexiones paralelas y simultáneas con varios puntos limita
la posibilidad de escogerlo como base para este trabajo.
Axel
Axel [38] es un acelerador de descarga de código abierto para Linux. Optimiza
Wget tratando de mejorar la tasa de descarga HTTP/FTP estableciendo
múltiples conexiones TCP para la descarga de un único archivo, maximizando
el uso de ancho de banda disponible. Puede utilizar múltiples mirrors y
en general hereda las características básicas de Wget. Sin embargo Axel
es un proyecto terminado que no recibe demasiada atención de parte de
sus mantenedores. En la Figura 5.2 se aprecia que su código no ha tenido
intervenciones desde el 2010, y su documentación es deficiente. Por lo tanto
no es recomendable su uso considerando que las alternativas tienen mejor
proyección por su mantenimiento.
Figura 5.2: Historia de commits mensuales del código de Axel [37].
39
Aria2
Aria2 [39] es un software utilitario liviano de descarga por linea de comandos.
Es multi-protocolo y multi-fuente. Soporta HTTP/HTTPS, FTP, BitTorrent
y Metalink.
Entre sus características más destacables se encuentran:
Al igual que Axel procura utilizar al máximo el ancho de banda de
descarga estableciendo múltiples conexiones, añadiendo la ventaja de
hacerlo independiente del protocolo.
Es un cliente BitTorrent completo, con todas las características disponibles: DHT, PEX, encriptación, Magnet link, web-seeding, Local Peer
Discovery y UDP tracker.
Soporta el formato de descripción de descargas Metalink, que ofrece la
verificación de archivos HTTP/FTP/BitTorrent de forma integrada.
Ofrece una interfaz para el control del proceso Aria2 a través de RPC,
con JSON-RPC (sobre HTTP y WebSocket) y XML-RPC.
Aria2 se encuentra en fuerte desarrollo (ver Figura 5.3) y el esfuerzo humano
(COCOMO) en el proyecto supera 31 veces a Axel. Sus características lo
dejan como la mejor opción, ya que es un cliente de descarga multiconfigurable, multiprotocolo, y además se utiliza actualmente de manera incipiente
en investigación [40] aunque aún no tiene la robustez de Wget.
Figura 5.3: Historia de commits mensuales del código de Aria2 [37].
Descripción del formato Metalink
El formato Metalink fue desarrollado en el 2005 por Anthony Brian
como una optimización a P2P, como una alternativa de Web Seeding, aunque
su uso es muy bajo y pocos clientes lo soportan, tiene un potencial enorme
ya que permite utilizar distintos protocolos para una descarga. Fue diseñado
para soportar mirrors (HTTP y FTP) y BitTorrent.
40
Metalink se describe por un archivo XML con variadas particularidades. Puede describir al cliente una multiplicidad de archivos y en ellos una
multiplicidad de URLs de descarga. Su descripción ha sido elaborada como
un estándar de la IETF (Internet Engineering Task Force) [41]. En el Código
5.1 se muestra un ejemplo decriptivo del formato de un archivo Metalink V
3.0 [11].
1
2
<? xml version ="1.0" encoding =" UTF -8" ? >
< metalink version = " 3.0 "
xmlns = " http :// www . metalinker . org / " >
3
4
5
6
< files >
< file name = " example . ext " >
< verification >
7
< hash type = " md5 " > example - md5 - hash </ hash >
8
< hash type = " sha1 " > example - sha1 - hash </ hash >
9
< signature type = " pgp " / >
10
</ verification >
11
< resources >
12
< url type = " ftp " location = " us " preference = " 90
" > ftp :// ftp . example . com / example . ext </ url >
13
< url type = " ftp " location = " uk " preference = " 90
" > ftp :// ftp . example . net / example . ext </ url >
14
< url type = " http " location = " us " preference = "
90 " > http :// example . com / example . ext </ url >
15
< url type = " http " location = " de " preference = "
90 " > http :// example . net / example . ext </ url >
16
< url type = " bittorrent " preference = " 100 " > http
:// example . org / example . ext . torrent </ url >
17
< url type = " rsync " / >
18
< url type = " magnet " / >
19
< url type = " ed2k " / >
20
21
22
23
</ resources >
</ file >
</ files >
</ metalink >
Código 5.1: Formato de un archivo de descarga Metalink V3
41
Es importante considerar que Metalink peermite usar variadas verificaciones de hash, entre ellas SHA-1 y MD5. Además, las URLs de descarga
pueden ser seteadas por prioridad a través de la opción “preference” del tag
“<url>” con valores que van de 0 a 100.
Para este trabajo particular se le dará prioridad de conexión a BitTorrent por sobre la CDN usando la opción “preference” de Metalink, dado
que en el escenario donde se realizan las pruebas (Chile), la conexión con la
CDN de Google tiene demasiada ventaja.
5.3.
Propuestas de mejora para la disminución de
Sistemas Autónomos en descargas BitTorrent.
Como se menciona el Capítulo 1 la ineficiencia que afecta el tráfico
interdominio es importante para los proveedores por la cantidad de tráfico
generado por BitTorrent. Creemos que el problema en los enlaces internacionales será mayor en la medida que crezca el tráfico generado por las naciones
emergentes y en vías de desarrollo, cuya penetración de conexiones de red de
alta velocidad crece linealmente desde hace una década [42].
Uno de los objetivos finales de esta tesis es realizar una reducción en el
tráfico Inter-ISP, para el protocolo BitTorrent. La propuesta de solución es
disminuir la cantidad sistemas autónomos en cada descarga implementando
un filtro para descargar desde los peers que estén a menos Sistemas Autónomos de distancia. Cabe destacar que no se utilizará la latencia como factor
a la hora de elegir los peers a descargar, ya que la latencia de la red tiene un
impacto marginal en el tiempo necesario para descargar un archivo [43].
Como se especificó en la sección anterior 5.2, se utilizará la herramienta
Aria2, que es el único cliente de código abierto (C++) multiprotocolo, y que
sirve de plataforma base de descarga que se utilizará para llevar a cabo todos
los objetivos de este trabajo.
La base fundamental de la implementación de la propuesta como fue
dicho anteriormente, es seleccionar los peers a menos sistemas autónomos de
distancia. En la Figura 5.4 se observa un diagrama explicativo.
42
Figura 5.4: Diagrama general de los métodos.
La respuesta del tracker actualmente consta de una serie de peers que
contiene el archivo a descargar, de los cuales nuestro cliente se conecta a
través de sockets y elige de cuáles descarga al azar. Se tomaron dos caminos
para la selección de peers, un de ellas mediante Traceroute (Solución 1) y el
otro mediante TTL (Solución 2). A continuación se mostrarán los resultados
de investigación/implementación de estos dos caminos.
5.3.1.
Solución 1: Traceroute para el filtro ASFB .
Traceroute es una herramienta utilizada entre otras cosas para caracterizar los caminos de extremo a extremo de red, descubrir la topología de
Internet y detectar problemas de enrutamiento. Proporciona una lista de
los Sistemas Autónomos (ASes) a lo largo de la ruta de transmisión, lo que
lo hace una herramienta importante para los investigadores y operadores de
red. Es por eso que se utilizará esta herramienta, ya que existen publicaciones
[44] [45] en donde es utilizado para las mediciones antes nombradas.
43
El funcionamiento en resumen es el siguiente: Se ejecuta el traceroute
desde la computadora de origen y se envían 3 paquetes UDP al destino con
TTL=1, 3 paquetes UDP al destino con TTL=2, y así sucesivamente. Cada
router intermedio disminuye en una unidad el valor del campo TTL. Si TTL
llega a cero, el router intermedio envía un mensaje ICMP encapsulado en un
datagrama IP que indique que el TTL se ha excedido y que se ha descartado
el datagrama inicial.
Si existe ruta para hacer llegar el mensaje ICMP a la computadora de
origen que realizó el traceroute, se podrá imprimir la dirección IP del
nodo intermedio y se incrementará en una unidad el valor del campo
TTL.
El mensaje ICMP se descartará si no se recibe respuesta, en este caso
no se podrá imprimir la dirección IP del nodo intermedio e imprimirá
un ‘*’ y se continuará el envío de datagramas IP incrementando en una
unidad el valor del campo TTL.
Cuando los datagramas IP lleguen al destino final, la computadora
con la IP de destino enviará mensajes ICMP indicando puerto inexistente y
el origen, al recibirlos terminará la ejecución de traceroute.
Para el caso del presente trabajo, se requiere específicamente saber por
cuantos sistemas autónomos distintos pasó la traza que realizó el traceroute,
para ello el comando traceroute tiene una opción denominada “-A” el cual
genera un informe del Número de Sistema Autónomo (ASN) en cada salto.
5.3.2.
Implementación del Filtro ASFB mediante Traceroute.
Luego de que el tracker le envíe al cliente (Aria2) la cantidad de peers
aleatorios que contienen el archivo a descargar, se utilizará un comando
posteriormente definido para filtrar dichos peers.
Aria2 crea los peers a medida que el tracker entrega las IPs con su
respectivo puerto y se guardan en una pila uno por uno, para luego iniciar la
descarga. En el período entre que se inicia la descarga y el almacenamiento
de los peers en la pila, se ejecuta el traceroute con cada IP de destino que
devuelve el tracker. El tiempo que se demora en realizar cada traceroute a
los peers que devuelve el tracker antes de iniciar la descarga será denominado
“ tiempo α”.
44
El comando utilizado para la implementación del filtro ASFB es [46]:
traceroute -UnAm 15 (IP_DESTINO)
-U: Pasar al siguiente salto luego que el primero haya llegado exitosamente.
-n: Mostrar las IPs y no los hostnames.
-A: Especifica los sistemas autónomos por los que pasa el paquete.
-m 15: La cantidad de hops que se realizarán son 15, ya que por defecto
traceroute provee 30 saltos lo cual duplicaría el “tiempo α” que se
tomaría para iniciar la descarga. Otra razón importante para esta
decisión, es que como el umbral µ tiene al promedio, los peers con
sistemas autónomos muy altos se descartarán de todas formas.
Debido a la forma en que trabaja Aria2 para seleccionar los peers
se utilizará un umbral (Subsección 5.3.2). Es decir, los peers con Sistemas
Autónomos mayores a un número umbral µ, serán descartados. En la Figura
5.5 se puede apreciar un diagrama explicativo.
Figura 5.5: Diagrama para filtro ASFB .
45
Selección del umbral µ.
El umbral que se utilizará para seleccionar los peers es un umbral
dinámico que tiende al promedio de los Sistemas Autónomos que entrega el
Tracker. Esto proviene de un método estadístico llamado “El método de las
medias móviles”, en el cual se analiza un conjunto de datos para crear series
de promedios. Como se ve en el siguiente pseudocódigo (Código 5.2).
1
Prom : Promedio
2
U : Umbral
3
AS : Suma de sistemas a u t n o m o s .
4
5
U = infinito , Prom = 5;
6
7
PARA todos los peers ( P )
entregados por el tracker :
8
9
SI
AS ( P ) < U
10
Se inicia descarga
11
Prom : ( Prom + AS ( P ) ) /2
12
13
14
SI (U - Prom ) > 1
U ++;
15
16
Si no
U - -;
17
Código 5.2: Algoritmo del umbral dinámico
46
5.3.3.
Solución 2: Estudio sobre la relación del TTL con los
Sistemas Autónomos.
El objetivo de esta investigación es analizar si es factible usar como
alternativa un filtro a través del calculo del TTL en vez de la herramienta
anterior (traceroute) para poder evitar el tiempo α provocado por éste. En la
literatura no se encontró información que especifique la relación directa entre
TTL y los Sistemas Autónomos, lo cuál haría meritorio cualquier indagación
profunda al respecto.
Como fue explicado de forma parcial en la Subsección 5.3.1 uno de
los datos que lleva cada datagrama enviado por IP es el TTL, que es el
número de saltos (pasos por routers) que el paquete puede dar antes de ser
descartado. Esto es un límite impuesto por el protocolo TCP para evitar que
queden paquetes circulando en loops por la red indefinidamente. El número
máximo de saltos permitidos en el protocolo IP es 255, pero normalmente las
aplicaciones que usan el protocolo TCP/IP fijan un valor menor (por ejemplo,
128 un host con Window XP o 32 en los primeros Sistemas Operativos de
Windows, etc.). El valor TTL disminuirá una unidad por cada paso de router,
hasta llegar al tope establecido. El router por el que pasen datos con TTL
igual a cero, no redigirá dichos datos, sino que los descartará enviando un
mensaje ICMP de tipo 11 (Time Exceded) para informar al origen.
Sabiendo el valor inicial del TTL se podría saber cuántos saltos ha
dado el paquete. Hay que tomar en cuenta, que los host a los que hacen ping
no devuelven el mismo TTL del paquete que reciben, sino su propio valor
TTL. Por ejemplo, se hace un ping con Window XP (valor TTL de 128) que
pasa por 10 routers, y llega a destino con valor 118. Ahora bien, el TTL y
los SA hipotéticamente podrían estar relacionados de la siguiente manera: El
TTL del paquete mientras más saltos realice, podría pasar por más Sistemas
Autónomos.
Para analizar esta hipótesis, en primera instancia se necesita saber
cuál es la relación real en la práctica entre el TTL (cantidad de saltos) y SA.
Se utilizó la misma lógica que al implementar el contador de sistemas
autónomos con Traceroute, es decir después de recibir la respuesta del tracker
y antes de iniciar la descarga.
47
Para esto:
Se creó en primera instancia un socket para lograr la comunicación con
el peer de la IP entregada por el Tracker.
Se obtuvo el TTL de llegada utilizando un sniffer.
Se cerró la conexión del socket.
Con el TTL de llegada se puede conocer la cantidad de saltos de la
siguiente forma:
TTL Propio - TTL de llegada = Cantidad de saltos.
5.3.4.
Resultado del estudio de relación TTL/SA.
Se realizaron 20 descargas para tener un total de 300 peers (datos) a
los cuales se les calculó la cantidad de saltos y los sistemas autónomos para
establecer su relación. Como se menciona al comienzo de esta subsección,
luego de que el tracker provee las IPs y antes de comenzar a descargar, se
implementó un sniffer que devuelve el TTL de llegada (de cada IP), al cual
se le restó al TTL propio calculando así la cantidad de saltos. Luego a cada
IP a la que se sniffeó el valor TTL, se le calculó la cantidad de Sistemas
Autónomos con traceroute. En la Figura 5.6 se puede observar un diagráma
explicativo.
48
Figura 5.6: Esquema para el cálculo de la relación TTL vs SA.
Correlación.
Para analizar la relación entre los saltos del TTL y los Sistemas Autónomos se utilizó la correlación estadística. La correlación estadística indica la
fuerza y la dirección de una relación lineal y proporcional entre dos variables
estadísticas. Se considera que dos variables cuantitativas están correlacionadas cuando los valores de una de ellas varían sistemáticamente con respecto
a los valores homónimos de la otra: si tenemos dos variables (A y B) existe
correlación si al aumentar los valores de A lo hacen también los de B y
viceversa.
El coeficiente de correlación puede variar desde -1.00 hasta 1.00. La
correlación de proporcionalidad directa o positiva se establece con los valores
+1.00 y de proporcionalidad inversa o negativa, con -1.00. No existe relación
entre las variables cuando el coeficiente es de 0.00.
49
Existen distintos coeficientes que miden el grado de correlación, adaptados a la naturaleza de los datos. Uno de ellos es el coeficiente de correlación
de Pearson, que se obtiene dividiendo la covarianza de dos variables entre el
producto de sus desviaciones estándar. Otro de ellos es el coeficiente de correlación de Spearman que es menos sensible que el de Pearson y se diferencian
en que Spearman utiliza valores medidos a nivel de una escala ordinal.
Resultado Correlación de Pearson.
En la Figura 5.7 se puede observar el resultado de la correlación
de Pearson para la relación de saltos TTL con la cantidad de Sistemas
Autónomos.
Figura 5.7: Gráfico de Correlación de Pearson.
El resultado es un coeficiente de relación de 0.24. A pesar que el
resultado es positivo, es un número que esta más cercano a 0 lo que indica
que la correlación es muy débil.
50
Resultado Correlación de Spearman.
En la Figura 5.8 se puede observar el resultado de la correlación de
Spearman. En este caso la correlación subió a un a 0.31, pero aún así sigue
siendo una correlación baja (ya que es cercana a 0).
Figura 5.8: Gráfico de Correlación de Spearman.
Según los resultados de la investigación práctica y los test de correlación matemáticos se puede afirmar que la relación entre los saltos TTL y los
sistemas autónomos es débil. Por lo que implementar un filtro utilizando el
TTL no es factible para este trabajo.
51
5.4.
Descargador Segmentado desde una CDN
5.4.1.
Geolocalización de los content-servers de Youtbe CDN.
Se realizaron muestras de RTT a los content servers de un video de
Youtube buscando una relación entre las latencias y su posición geográfica,
la técnica utilizada está basada en Constraint Based Geolocation (CBG)
[47], técnica de georeferenciación basado en latencia que ha sido empleada
anteriormente en otros trabajos de investigación para el mismo fin [35].
Lo que interesa es que se cumpla la premisa que los edge-servers a los
cuales da acceso la CDN de Google, estén relativamente cerca del usuario
para esa descarga específica, al menos en el mismo país. En particular se
tomaron capturas de 1 hora, ya que si se quisieran tomar decisiones en base
a pruebas de latencia no puede ser en base a mediciones demasiado extensas.
Metodología
Se seleccionaron 3 landmarks activos, que corresponden a computadores para los que se tiene su localización geográfica resuelta (ver Tabla 5.1),
y que pueden ser controlados directamente a través de SSH. Estos describen
el subconjunto necesario L = {L1 , L2 , L3 } para poder realizar las mediciones
a los servers objetivo definidos como “targets” T = {τ1 , τ2 , τ3 }.
Landmark
Nombre
Ciudad (país)
Latitud λ
Longitud ϕ
L1
DEC UDP
Santiago (Chile)
-33.452622
-70.660878
L2
EC2 Sao Paulo
Sao Paulo (Brasil)
-23.596003
-46.692325
L3
EC2 Oregon
Oregon (USA)
45.916408
-119.342264
Tabla 5.1: Nombre y posición geográfica de los landmarks
Se realizaron mediciones de latencia de 1 hora y se calculó la distancia
geodésica entre cada uno de ellos, usando la fórmula del Haversine Ec.5.1
para un radio terrestre medio R = 6371km, .
a = sin2 (∇ϕ/2) + cos(ϕ1)cos(ϕ2)sin2 (∇λ/2)
√ √
c = 2 atan2( a, 1a)
g = Rc
52
Donde g corresponde a la distancia entre los landmarks. En la Tabla
5.2 se observan los resultados de las mediciones de latencia (promedio) entre los landmarks di,j y la distancia gi,j calculada con la técnica descrita
anteriormente.
Landmarks
Distancia gi,j [Km]
RTT di,j [ms]
L1 - L2
2577
47
L1 - L3
10090
180
L2 - L3
10630
200
Tabla 5.2: Distancia y latencia entre los landmarks
Para la selección de los targets, se identifican una colección de grupos
de edge-servers y caché servers de Youtube, es importante notar que tal como
se menciona en el Capítulo 4 los servers de caché situados en PoPs (Point of
Presence) de las ISPs locales tienen 8 IPs (servidores) y los edge-servers 20
IPs por site. En la Tabla 5.3 se observa este resumen, útil en caso de que se
desee dar continuidad a este trabajo, donde X = [1, 20] e Y = [1, 8].
Content Servers
IP inicio
IP final
rX—sn-bg07yn7s.googlevideo.com
74.125.107.133
74.125.107.153
rX—sn-nja7sn7r.googlevideo.com
209.85.239.166
209.85.239.185
rX—scl03s01.googlevideo.com
209.85.239.6
209.85.239.25
rX—sn-gpv7en7e.googlevideo.com
74.125.107.6
74.125.107.25
rX—gru09s03.googlevideo.com
74.125.107.133
74.125.107.153
rX—gru06s03.googlevideo.com
74.125.165.134
74.125.165.153
rX—sn-nx57yn7r.googlevideo.com
173.194.56.166
173.194.56.185
Cache Servers
IP inicio
IP final
rY—sn-8ug-njas.googlevideo.com
190.45.0.76
190.45.0.83
rY—vtr-scl3.googlevideo.com
190.45.0.76
190.45.0.83
rY—sn-upfn-hp56.googlevideo.com
208.117.253.12
208.117.253.19
rY—sn-p5qlsu76.googlevideo.com
74.125.214.144
74.125.214.151
Tabla 5.3: Conjunto de servers entregados por la CDN de Youtube a los
landmarks.
53
En la referencia [48] se presenta una suposición respecto de los nombres de dominio de los servidores de Google, se plantea la posibilidad de que
se asignen en base a las denominaciones cortas de los aeropuertos de acuerdo
al estandar de la IATA [49], pero esta cualidad se cumple en escasas oportunidades. En el caso particular de los servers encontrados en este trabajo,
aparecen dos content servers que parecen cumplir con esa característica, SCL
(Santiago, Chile) y GRU (Sao Paulo, Brasil). Esta posible coincidencia de
locación con los landmarks los deja como excelentes candidatos a targets,
ya que CBG funciona mejor para los casos donde un target está cerca de
un landmark y alejado de los otros, y permitiría apoyar la hipótesis de la
literatura [48] o rechazarla. Para el tercer target se escoge el único sever que
se encuentra fuera del rango de IPs de los otros dos, es decir sn-nx57yn7r.
El planteamiento del problema de la geolocalizción a través de métricas
de red ha sido resuelto de múltiples formas, siendo muy común usar la
multilateralización como técnica para estimar un nodo desconocido. En la
Figura 5.9 se observa esquemáticamente la lógica detrás de esta técnica. En
general se cumple que gbiτ = giτ + γiτ , donde gbiτ es la estimación de la
distancia entre el landmark Li y el target τ , giτ es la distancia real entre el
landmark Li y el target τ y γiτ es la distancia de incertidumbre ocasionada
por la variabilidad de las mediciones de latencia y el error en su traducción
a distancia geográfica.
54
Figura 5.9: Multilateralización con restricciones de distancia geográfica para
los landmarks usados.
Luego se realizaron mediciones de latencia desde los landmarks Li a
los targets τ , definida como di,τ . En la Tabla 5.4 se observan los resultados
de estas mediciones de latencia, se incluyeron las mediciones a un server de
caché, VTR-SCL3 (ver Tabla 5.3), que a diferencia de los content-servers,
respondía al comando whois como miembro de la red del operador chileno
VTR.
Cache
Content
SCL-VTR
SCL03 τ1
GRU09 τ2
nx57yn7r τ3
L1
2 ms
1 ms
50 ms
160 ms
L2
50 ms
51 ms
2 ms
198 ms
L3
170 ms
170 ms
210 ms
7 ms
Tabla 5.4: Mediciones de latencia di,τ desde los landmarks a los targets.
55
Con esta información, el problema de encontrar las distancias entre
un landmark y un target se traduce a resolver el problema de programación
lineal, de minimización (ver Eq. 5.3) de lo que se define como “bestline”
(ver Eq. 5.2), que pretende establecer una relación lineal entre el RTT (ms)
y la distancia (km). En general se trata de encontrar para cada landmark
i,
la pendiente
i
y el coeficiente de posición bi , donde la pendiente es
i
=
(dij − bi )/gij , dadas la latencia dij y la distancia gij entre Li y todos los otros
landmarks Lj con i 6= j.
y−
diτ − bi
x − bi ≥ 0, ∀i 6= j
m

mı́n 
bi ≥0
(5.2)

X
y−
i6=j
diτ − bi
x − bi 
m
(5.3)
Una vez obtenidos los valores de mi y di se utiliza Eq. 5.4 para estimar
las distancias desde los landmarks a los targets. Cuyos resultados se pueden
observar en la Tabla 5.5
gbiτ =
diτ − bi
m
(5.4)
gc
iτ
τ1
τ2
τ3
L1
22.82
2110.20
12007.99
L2
1998.62
45.77
12384
L3
11931
14884
341
Tabla 5.5: Distancia geográfica estimada entre los landmarks L y los targets
τ.
Con esta información se puede concluir que la premisa de que la
CDN entrega los content-servers más cercanos se cumple, al menos para el
caso descrito (que incluye el caso probado en el Capítulo 6). Ya se tenía
información preliminar de que las CDN resuelven comunmente por latencia,
pero la relación entre latencia y distancia geográfica no estaba clara.
56
Ahora se puede tener confianza, en que la CDN entrega los servidores
que se necesitan como peers para este trabajo. Se decide realizar las pruebas
de descarga utilizando los content-servers, en lugar de los caché servers, por
dos razones poderosas. La primera es que por la la ley de Zipf, una pequeña
cantidad de contenido se econtrará en caché en cualquier momento, dado
que los contenidos populares siempre son escasos. La segunda razón es que
dado que dado que las CDN entregarán el contenido desde los caché servers
automáticamente en caso de que se encuentre ahí, el desafío aparece cuando
el contenido no se encuentra cacheado.
5.4.2.
Implementación y uso.
La implementación se realiza como un módulo con 2 opciones nuevas
para el software Aria2, que tiene entre sus características la capacidad de
realizar descargas segmentadas en TCP y UDP, para una multiplicidad de
protocolos descritos en la Sección 5.1.
Se implementaron 2 opciones nuevas, creando instancias de los handlers
de Aria2. La más relevante es la que contiene la inteligencia para la descarga
de videos llamada CDNVIDEO. Su uso se describe a continuación.
$aria2c -Y <Url video de youtube>
Generando una URL de descarga válida.
Se incorpora un nuevo detector de protocolos a la clase ProtocolDetector, ya existente en Aria2, guiado por la expresión regular descrita
visualmente en la Figura 5.10.
Figura 5.10: Expresión regular para la identificación de la URL del video en
youtube.com .
57
Con la URL del video y la información subyacente a ésta, se ensambla
una URL de descarga usando el formato descrito en el Capítulo 4, y se extrae
el nombre del video. Luego se genera una cookie minimalista pero válida para
no depender de los tiempos de expiración de la conexión. La cookie se extrae
directamente de un response HTTP y un request HTTP con una llamada
externa a FileCookieJar de la libreria cookielib en Python. A continuación
se muestra un ejemplo de una cookie generada por el programa.
# Netscape HTTP Cookie File
# http://www.netscape.com/newsref/std/cookie_spec.html
# This is a generated file!
Do not edit.
.youtube.com TRUE / FALSE 1405322332 PREF gl=US&hl=en&f1=50000000
.youtube.com TRUE / FALSE 1405322332 VISITOR_INFO1_LIVE K3zFQeFzCYU
Una vez realizada una URL de descarga válida se crea un objeto
que ensambla un archivo Metalink en base a a la información de la URL.
El archivo Metalink describirá el archivo de descarga y contendrá tantas
URLs como la descripción de opción -s de Aria2, que, de ser definida por el
usuario, indica la cantidad de conexiones paralelas que se realizarán para una
descarga, en caso de no ser definida se utiliza la opción por defecto, s = 5.
A continuación se enfatiza en las capacidades del formato Metalink.
Generando un archivo Metalink de multiples URLs de descarga
Como las URLs tienen un número relacionado al servidor de la CDN
de descarga, que pueden variar entre 1 y 20 (ver Capítulo 4), y se puede
elegir indistintamente entre estos servidores, simplemente se genera una lista
de URLs válidas cambiando este número, por ejemplo:
http://r1---sn-nja7sn7r.c...
...
Luego en base a esta información y a la información adquirida en
el paso anterior se crea un archivo Metalink válido bajo el estándar de la
versión 3.0 llamado video.metalink. En el Código 5.3 muestra un ejemplo
para descarga de 3 servidores para el mismo video.
58
1
2
< metalink version = " 3.0 " xmlns = " http :// www . metalinker .
org / " >
< publisher >
3
4
< name > Youtube . com </ name >
5
< url >
6
http :// www . youtube . com / watch ? v = AidSQATDGos </
url >
7
</ publisher >
8
< description > Download youtube videos using aria2c
9
</ description >
10
< tags > youtube , download , video </ tags >
11
< files >
12
< file name = " [20130809][ AidSQATDGos ] EU001 -
13
Ultra HD 4 K - The Colors of Cyprus ( by
VOXLIBERTUM ) . mp4 " >
< resources >
14
15
< url type =
16
" http " > http :// r1 - - - sn -8 ug - njal . c ... </ url >
17
< url type = " http " > http :// r2 - - - sn - nja7sn7r .
c ... </ url >
< url type = " http " > http :// r3 - - - sn - nja7sn7r .
18
c ... </ url >
</ resources >
19
20
21
22
</ file >
</ files >
</ metalink >
Código 5.3: Metalink generado para la descarga de videos de Youtube usando
Aria2
Finalmente se intercambia el RequestGroup de Aria2 generado originalmente para una descarga simple por HTTP para la descarga usando
múltiples conexiones del Metalink generado.
59
El uso de la potencialidad de Metalink será extendido en este trabajo
agregando, en términos generales no sólo una nueva capacidad al software de
Aria2 sino que al protocolo mismo de Metalink, ya que se añade a través del
módulo la capacidad de descargar videos desde un servicio de compartimiento
de videos en linea.
5.4.3.
Resumen.
Cliente BitTorrent: Aria2.
Cliente de Descarga: Aria2.
Selección de peers: Mediante el filtro estadístico que se denominará ASFB
(Autonomous System Filter BitTorrent).
Mecanismo de descarga desde la CDN: Metalink V3.0.
Herramientas de software: Traceroute, Aria2, netem, surl, bwm-ng, tcpdump, SPSS Statics, Matlab.
Archivo Torrent para realizar las pruebas de ASFB : Parks.and.Recreation.S05E17.HDTV.x264LOL.mp4.
Video de YouTube para realizar las pruebas: Ultra HD 4K - The Colors of Cyprus (by VOXLIBERTUM).mp4.
Archivo a descargar usando metalink usando BitTorrent y la CDN
: Ultra HD 4K - The Colors of Cyprus (by VOXLIBERTUM).mp4
60
Capítulo 6
Análisis de Resultados.
6.1.
Reducción de Sistemas Autónomos ASFB .
Se realizaron 60 pruebas en total (30 para el cliente modificado con
filtro ASFB , y 30 para el cliente sin modificación), donde la métrica que
es importante analizar para esta parte del trabajo referido a la reducción
de Sistemas Autónomos es la razón de: Cantidad de Sistemas Autónomos y
cantidad de peers por cada descarga.
Se analizó el intervalo de confianza para calcular la desviación estandar
de los datos con la herramienta IBM SPSS Statistics. El resultado se puede
observar en la Figura 6.1
61
Figura 6.1: Prueba T - Intervalo de confianza.
Se puede desprender de este resultado que el intervalo de confianza
para el caso de los datos con filtro ASFB es de [4,5960 , 4,9119] y para
el caso de los datos sin filtro es de [5,4780 , 5,8067]. En ambos casos el
intervalo de confianza es estrecho lo que implica una mayor precisión en
los datos. La desviación estandar en un conjunto de datos es una medida
de dispersión, que nos indica cuánto pueden alejarse los valores respecto al
promedio (media), por lo tanto es útil para buscar probabilidades de que un
evento ocurra. En este caso se puede observar que la desviacion estandar es
en ambos casos es 0,4, lo que implica poca dispersión de los datos y por ende
un comportamiento similar para cada descarga.
6.1.1.
Resultados para el filtro ASFB .
La Figura 6.2 es un gráfico de regresión lineal para una dispersión
simple con los datos de sistemas autónomos en el eje Y y cantidad de peers en
el eje X. Se puede observar según las pruebas realizadas que, con la inserción
del filtro ASFB al cliente Aria2 se puede obtener la misma cantidad de peers
con menos Sistemas Autónomos, minimizando asi la cantidad de Sistemas
Autónomos por cada descarga.
62
Figura 6.2: Gráfico de regresión lineal para cantidad de SA totales vs Peers
totales por descarga.
Esto demuestra una eficiencia que corresponde al 15 % en cuanto a
la disminución de Sistemas Autónomos en la implementación realizada. La
eficiencia se calculó de la siguiente forma: se tomaron las dos rectas de ajuste
de la regresión lineal, y las áreas bajo la curva se restaron obteniendo así la
diferencia.
En el caso del tiempo de descarga, hay que mencionar que no se tomó
en cuenta el “tiempo α” (Sección 5.3.2), que es el tiempo que se demora
en hacer Traceroute a cada peer que devuelve el tracker. Esto debido a que
ese tiempo es el que se demora el software en particular (Traceroute), en
entregar el dato que se necesita, pero lo que nos interesa medir es el tiempo
que se demora la descarga al usar el filto ASFB disminuyento la cantidad de
sistemas autónomos. Es por eso que no se toma en cuenta el “tiempo α” ya
que es un dato marginal a lo que se busca medir, que en este caso particular
es de 5 minutos.
En la Figura 6.3 se puede observar un gráfico de dispersión cuyo
eje X corresponde a la métrica de normalización de la cantidad de Sistemas
Autónomos por la cantidad de peers de cada descarga, y el eje Y corresponde
al tiempo de descarga.
63
Figura 6.3: Gráfico de dispersión para Tiempo vs SA/Peers.
Debido a que los datos están claramente dispersos, no se puede asegurar un comportamiento constante de ningún tipo, ya que se puede observar
que el tiempo de descarga es independiente a la razón de cantidad de sistemas
autónomos/peers. En el caso particular de nuestra implementación se puede desprender que reduciendo la cantidad de sistemas autónomos por cada
descarga con el filtro ASFB , el tiempo de descarga no se va a ver afectado
siendo transparente para el usuario.
Para el caso de las pruebas realizadas, las medias del tiempo de descarga para el cliente con filtro ASFB y para el cliente sin filtro con una
diferencia de 0,33 minutos, se pueden observar en la siguiente Tabla 6.1:
Tiempo de descarga promedio (minutos)
Cliente con filtro $ASF_B$
10,16
Cliente sin modificar
9,83
Tabla 6.1: Tiempo promedio de descargas
64
El objetivo de esta tesis es investigar e implementar métodos para
reducir la sobrecarga del tráfico internacional. En cuanto a la reducción de
los sistemas autónomos con filtro ASFB el resultado fué positivo ya que
efectivamente reduce la cantidad de sistemas autónomos en un porcentaje
considerable (15 %), eligiendo los peers más cercanos. El lado negativo en la
práctica fue lo denominado en esta tesis como “tiempo α” ya que atrasa el
inicio de la descarga en varios minutos (5 en este caso particular), por lo que
perjudicaría la experiencia del usuario al bajar archivos .torrent.
Aún así sigue siendo una solución válida ya que logra su objetivo, que
con la reducción del “tiempo α” con la ayuda de otras tecnologías en el
futuro, sería una solución que se podría llevar directamente al usuario final,
y contribuir como primer paso a un problema que irá creciendo a lo largo del
tiempo [1].
6.2.
Cliente de descarga segmentada desde la CDN
de YouTube
6.2.1.
Análisis.
Para analizar el desempeño de las descargas utilizando el módulo
CDNvideo de Aria2 implementado por los memoristas, se utilizó un video
de resolución 4k de 15 minutos de distribución libre. Este video sirve como
muestra para apreciar las diferencias en rendimiento a medida que aumentan
los content servers desde los que se descarga en forma paralela.
Para probar con distintas latencias de conexión a los edge-servers, se
utilizó la herramienta netem [50] para agregar a la interfaz de red del servidor
varios niveles de latencia desde 0 ms de latencia agregada a 1000 ms, para
caracterizar distintos escenarios de prueba en forma emulada.
# tc qdisc add dev <interfaz>root netem delay Xms
6.2.2.
Resultados.
Se midió el throughput a través de la herramienta “Bandwidth Manager” utilizando la información de configuración que se encuentra en /proc/net/dev usando el comando.
$bwm-ng -i proc -f /proc/net/dev -I<interfaz>-ocsv
65
Con este software se obtendrá el throughput en forma de paquetes de
entrada para la interfaz de red del equipo que ejecuta el cliente, las mediciones
se hacen en paralelo con cada descarga.
Se probó hasta un número de servidores igual a 10 puesto que la
orientación del desarrollo no es sobresaturar la conexión del cliente, y si los
resultados son fijos, carece de sentido llegar hasta las 20 conexiones posibles.
Además, se varía la latencia a través de la herramienta netem para plantear
distintos escenarios desde 0 ms latencia agregada a 1000 ms, totalizando 140
pruebas.
En general, los tiempos de descarga disminuyen drásticamente para
las latencias más altas pero no tan significativamente para las más bajas.
Las descargas paralelas segmentadas convergen posteriormente al nivel más
bajo dado por el uso máximo del ancho de banda disponible tal como se ve
en la Figura 6.4.
Figura 6.4: Tiempo de descarga desde 1 a 10 conexiones paralelas, para todas
las variaciones de latencia.
66
Los resultados para la convergencia al througput máximo medido en
paquetes de entrada varían considerablemente respecto de la latencia, por
ejemplo si se observa el nivel de estabilidad en las Figuras 6.5 y 6.6 que
corresponden al throughput para 1000ms de latencia con descarga directa a
1 server en primer lugar y descarga segmentada de 6 servers en el segundo.
Se observa en la Figura 6.5 que existe una grán variabilidad y se está lejos
de llegar al máximo throughput posible para la conexión.
Figura 6.5: Gráfico del Throughput en paquetes de entrada para la descarga
con una conexión a un server, con latencia l = 1000ms.
Figura 6.6: Gráfico del throughput en paquetes de entrada para la descarga
con una conexión a 6 servers , con latencia l = 1000ms.
67
Si se comparan los resultados anteriores con un gráfico del througput
para una latencia del orden de 100 ms se observa que rápidamente se alcanza
el máximo deseado con sólo 2 conexiones, como se aprecia en la Figura 6.7.
Figura 6.7: Gráfico del throughput en paquetes de entrada para la descarga
con una conexión a 2 servers , con latencia l = 100ms.
El módulo implementado cumple su objetivo, la mejora observada
obtiene en general un aumento del throughput, especialmente para latencias
altas.
Además, y lo más importante, se provee de un nuevo uso para una
tecnolgía incipiente (Metalink) a través de la implementación del módulo de
descarga de videos en Aria2. Con el trabajo realizado se abre una puerta
a variadas formas de compartimiento de archivos, reunidos en un estándar
propuesto.
68
6.3.
Implementación y resultado de la unión conceptual: BitTorrent y CDN.
La idea fundamental es poder descargar un archivo desde dos protocolos distintos. La base para poder llevar a cabo esto es crear un archivo
.torrent en un metalink para que estos puedan ser descargados también desde
las CDN que garantizan una “cercanía” y se disminuye el tiempo de descarga, ya que los Edge Servers son peers que estarán siempre activos y con la
implementación de CDNVideo el tiempo de descarga disminuye mejorando
la experiencia del usuario. Pero también manteniendo todas las ventajas de
BitTorrent con el filtro ASFB implementado para mantener la “cercanía” de
los peers y evitar la saturación de los enlaces internacionales.
Figura 6.8: Esquema de la unión ASFB -CDNVideo.
En la Figura 6.8 se muestra un esquema de la unión ASFB y CDN
Video donde aparece un Leecher descargando un .torrent a través de un
metalink, descargando desde los Edge Servers de las CDN y a la vez de los
peers de la topología BitTorrent con el filtro ASFB incluido, ya que como se
observa el P eer1 está a 10 sistemas autónomos de distancia, dejando de ser
un peer “cercano” y descartandolo de la descarga.
69
Para llevar a cabo esta unión se creó un archivo .torrent del video Ultra HD 4K - The Colors of Cyprus (by VOXLIBERTUM).mp4 (ver
Subsección5.2) y se subió a una página de distribuición de torrents http:
//extratorrent.cc/torrent/3316761. Luego se creó un metalink para torrent utlizando un hash SHA1 que identifica al archivo dado por el archivo
.torrent y la url de descarga de donde se alojó del archivo. En Código 6.1 se
puede observar el metalink utilizado.
1
2
< metalink version = " 3.0 " xmlns = " http :// www . metalinker .
org / " >
< publisher >
3
4
< name > Youtube . com </ name >
5
< url > http :// www . youtube . com / watch ? v =
AidSQATDGos </ url >
6
</ publisher >
7
< description > Download youtbe videos using aria2c
8
</ description >
9
< tags > youtube , download , video </ tags >
< files >
10
< file name = " [20130809][ AidSQATDGos ] EU001 -
11
Ultra HD 4 K - The Colors of Cyprus ( by VOXLIBERTUM
) . mp4 " >
12
< verification >
13
< hash type = " sha1 " >
AC299AF3C0CD683C98245E468CACA6AB18430B3F
14
</ hash >
15
</ verification >
16
< resources >
< url type = " http " preference = " 5 " > http :// www .
17
youtube . com / watch ? v = AidSQATDGos </ url >
< url type = " bittorrent " preference = " 100 " > http ://
18
extratorrent . cc / download /3316761/
\ %5 B20130809 \ %5 D\ %5 BAidSQATDGos \ %5 D + EU001 + -+
19
Ultra + HD +4 K + -+ The + Colors + of + Cyprus +\ %28 by +
VOXLIBERTUM \ %29. mp4 . torrent </ url >
</ resources >
20
</ file >
21
22
</ files >
70
23
</ metalink >
Código 6.1: Metalink de descarga de una URL de youtube a través de los
content-servers de la CDN de Google y peers BitTorrent simultaneamente
Para analizar la eficiencia de la mezcla de las implementaciones planteadas se propondrán dos escenarios para medir la cantidad de sistemas
autónomos totales y el tiempo de descarga. La fusión de los protocolos se
denominará BitCDN.
Se utilizará el archivo .torrent creado anteriormente en Capítulo 6.3
el cual se distribuirá en 7 computadoras para que puedan existir 7 seeders
disponibles, 4 en Santiago de Chile y 3 en el extranjero (Francia, Portugal y
Brazil). Se realizarán descargas desde BitCDN, y desde BitTorrent normal y
se analizarán los resultados y sus diferencias.
Resultados de BitCDN en comparación a BitTorrent.
La Figura 6.2 es un gráfico de regresión lineal para una dispersión
simple con los datos de sistemas autónomos en el eje Y y cantidad de peers
en el eje X. Se puede observar según las pruebas realizadas que, al igual que
con el caso del filtro ASFB con la fusión de protocolos denominado BitCDN
se puede obtener la misma cantidad de peers con menos sistemas autónomos,
en este caso los peers que son filtrados son “reemplazados” por content servers
de la CDN.
Figura 6.9: Gráfico de eficiencia BitCDN y BitTorrent.
71
Esto demuestra una eficiencia que corresponde al 32 % en cuanto a
la disminuición de Sistemas Autónomos en la implementación realizada lo
cual puede parecer una gran diferencia con el caso del filtro ASFB , sin
embargo los dos casos no son comparables directamente, ya que la descarga
efectuada para la fusión BitCDN es experimental con los 7 peers de pruebas
activos en la creación del archivo .torrent, que según la descargas utilizadas
efectivamente se eligieron los peers más cercanos excluyendo los que están a
más Sistemas Autónomos de distancia, siendo reemplazados por los server
CDN.
En el caso de tiempo de descarga en la Figura 6.10 se puede observar
un gráfico en donde el tiempo de decarga de BitTorrent con filtro ASFB y
BitTorrent sin modificación son del mismo orden. Sin embargo la diferencia
entre BitTorrent y BitCDN es de 1.5 minutos, para una media de descargas
de 5.8 minutos para el caso normal y 4.35 minutos para BitCDN, y una
desviación típica cercana a 0.6 en los tres casos.
Figura 6.10: Tiempos de descarga para BitCDN, BitTorrent con ASFB y
BitTorrent.
72
El beneficio principal de esta fusión, es que con la CDN se puede
reemplazar peers lejanos, por peers cercanos con una buena conexión, lo que
implicaría que el tiempo de descarga sea menor o igual. Además en caso que
un protocolo esté bloqueado en la red del cliente, este podrá descargar de
todas formas, lo que implica una mejora de cara al cliente, mejorando asi la
experiencia del usuario.
73
Capítulo 7
Conclusiones.
A través de la solución del filtro ASFB se logró disminuir la cantidad
de sistemas autónomos por descarga en una red BitTorrent, cuyo beneficio
es dirigido a las ISP ya que se vería disminuida la saturación de los enlaces
internacionales, lo que le permitiría ahorrar costos. A su vez a través de la
solución de CDNVideo se logró descargar videos desde una CDN a múltiples servidores (manteniendo la cercanía de la información) disminuyendo el
tiempo de descarga beneficiando la experiencia del usuario. Aún así estas dos
soluciones que parecen ser paralelas, pero con un fin común, tiene un punto
de unión importante en el metalink, gracias a esto las soluciones en conjunto
se complementan para un sistema de descarga de archivos innovador que es
el caso de BitCDN.
En resumen, utilizando las redes P2P de BitTorrent y las CDN se
puede descargar información a través de un mismo archivo metalink. Esto
permite descargar archivos con dos protocolos distintos en un mismo cliente
dando pie a un nuevo sistema de descarga multiprotocolo.
Otro punto considerable es que mejora el ancho de banda para la
transferencia de archivos cuando hay pocos o ningún seeder mejorando asi
la experiencia del usuario. Esto es porque se aumenta la cantidad de nodos
que tienen la información debido a que se fusionan disitintos protocolos,
obteniendo así más cantidad de nodos con contenido.
75
7.1.
Trabajo Futuro.
Este trabajo ha sido ambicioso en amplitud, generando la base para
interesantes oportunidades de investigación. En algunos casos, para mejorar
los desarrollos realizados o para encontrar otros enfoques y usos para las tecnologías incorporadas. Las oportunidades de investigación son las siguientes:
Generar una herramienta que permita indexar contenido y generar
archivos metalink en base a un nombre específico o a un hash, así luego
se buscaría ese hash en los servidores del metalink y se autodescargaría
el archivo. Esto sería un mecanismo de transición a una NDN (Named
data networking) que es un enfoque alternativo a la arquitectura de
las redes informáticas. Su principio fundamental es que una red de
comunicación debería permitir al usuario centrarse en los datos que
necesita, en lugar de tener que hacer referencia a una ubicación física
de donde los datos se encuentran. En este caso particular el usuario no
tendría que preocuparse de dónde está el contenido de la información,
porque el metalink lo genera y lo entrega.
En otras palabras cuando el usuario hace una solicitud de contenido, la red se encarga de proveerlos y los routers van guardando caché
de esos contenidos transformandose así en una CDN.
Con metalink se combina el protocolo BitTorrent con descarga desde
CDN con múltiples servidores, en un trabajo futuro se podrían agregar
otros protocolos como por ejemplo HTTP (descargar un archivo desde
un sitio de descarga directa).
Disminuir el Tiempo α para el filtro ASFB .
Implemetar el filtro de selección automática para el módulo de CDNVideo en Aria2.
Expandir los formatos para la descarga de múltiples servidores CDN
para otras redes de distribución de contenido como Akamai, MaxCDN,
etc.
Desarrollar un filtro por saturación de ancho de banda, proponemos
uno basado en Kálmán o cadenas de Markov con recompensa.
76
Probar en plataformas experimentales globales como Seattle o PlanetLab para poder controlar posición y comportamiento de los clientes
involucrados.
Indagar y comparar la solución propuesta con el emprendimiento
PeerCDN, y llevar la aplicación al plano web (HTML5, Websockets,
WebRTC).
Integración y comparación del rendimiento y capacidades de los formatos soportados por otros clientes distintos de Aria2 (xml, dlc, ccf,
rsdf) como JDownloader.
Implementación de un módulo para Aria2 que soporte descargas por
BitTorrent utilizando optimizaciones a TCP basados en UDP, como
por ejemplo uTP, VDT, entre otros.
Implementar una modalidad de descarga P2P que permita descargar
por Jumbo-Packets a través de IPv6, y analizar su comportamiento.
Realizar simulaciones de todos los casos descritos anteriormente utilizando un Software de simulación como NS-2 y NS-3 para analizar el
comportamiento y poder decidir la configuración de los escenarios.
77
Referencias bibliográficas
[1] C. VNI, “Cisco visual networking index: Forecast and methodology,
2010–2015,”
[2] Sandvine, “Global internet phenomena report,” tech. rep., 2012.
[3] T. P. A. Networks, “Application usage and threat report,” tech. rep.,
2013.
[4] IETF, “Official internet protocol standards list,” tech. rep., 2013.
[5] B. Cohen, “The bittorrent protocol specification,” tech. rep.
[6] IETF, “RFC 6817: Low extra delay background transport (LEDBAT),”
tech. rep., 2012.
[7] youtube.com, “Youtube Statistics,” 2013.
[8] Z. H. E. K. J. H. R. G. Matt Calder, Xun Fan, “Mapping the expansion
of google’s serving infrastructure,” IMC 13 October 23-25, Barcelona,
Spain., 2013.
[9] Movistar, “Políticas de gestión del tráfico en internet,” tech. rep., 2012.
[10] G. d. C. Subsecretaría de Telecomunicaciones, “Reglamento que regula
las características y condiciones de la neutralidad de la red,” tech. rep.,
2011.
[11] A. Bryan, “Metalink 3.0 specification,” metalinker.org., 2007.
[12] C. Lima Pancorbo, “Gestor de almacenamiento en redes p2p,” 2009.
[13] A. K. Ao-Jan Su, David R. Choffnes and M. Fabián E. Bustamante,
“Drafting behind akamai: Inferring network conditions based on CDN
redirections,” p. 17, 2009.
[14] M. H. Cheng-Hsin Hsu, “Isp-friendly peer matching without isp collaboration,” ACM ROADS Madrid, Spain, 2008.
[15] H. Xie, Y. R. Yang, A. Krishnamurthy, Y. G. Liu, and A. Silberschatz,
“P4p: provider portal for applications,” in ACM SIGCOMM Computer
Communication Review, vol. 38, pp. 351–362, ACM, 2008.
[16] “Distributed computing industry association,” tech. rep., 2013.
79
[17] A. S. R. Y. Haiyong Xie, Arvind Krishnamurthy, “P4p: Explicit communications for cooperative control between p2p and network providers,”
ACM SIGCOMM, 2008.
[18] D. D. Shay Horovitz, “Liteload: Content unaware routing for localizing
p2p protocols,”
[19] J. P. J. A. K. T. A. Michael Piatek, Harsha V. Madhyastha, “Pitfalls
for isp-friendly p2p design,” 2009.
[20] H. Schulze and K. Mochalski, “Internet study 2008/2009,” IPOQUE
Report, vol. 37, pp. 351–362, 2009.
[21] D. Qiu and R. Srikant, “Modeling and performance analysis of
BitTorrent-like peer-to-peer networks,” ACM SIGCOMM Computer
Communication Review, vol. 34, no. 4, pp. 367–378, 2004.
[22] Torrentfrak.com, “Most popular torrent sites of 2011,” tech. rep., 2011.
[23] www.utorrent.com/help/faq/ut3, “Streaming en utorrent,” tech. rep.,
2011.
[24] G. y. M. P. y. o. Legout, Arnaud y Urvoy-Keller, “Entendimiento BitTorrent: Una perspectiva experimental,”
[25] M. Izal, G. UrvoyKeller, E. W. Biersack, P. A. Felber, A. Al Hamra,
and L. GarcesErice, “Dissecting BitTorrent: Five months in a torrents
lifetime,” in Passive and Active Network Measurement, Springer, 2004.
[26] R. Axelrod and W. D. Hamilton, “The evolution of cooperation,” Science, vol. 211, no. 4489, pp. 1390–1396, 1981.
[27] A. Legout, G. Urvoy-Keller, and P. Michiardi, “Rarest first and choke
algorithms are enough,” in Proceedings of the 6th ACM SIGCOMM
conference on Internet measurement, pp. 203–216, ACM, 2006.
[28] R. B. Al-Mukaddim Khan Pathan, “A taxonomy and survey of content
delivery networks,” Springer-Verlag Berlin Heidelberg 2008, 2008.
[29] G. Pallis and A. Vakali, “Insight and perspectives for content delivery
networks,” Commun. ACM, vol. 49, pp. 101–106, Jan. 2006.
[30] J. R. K. M. M. M. M. M. S. R. Ruben Torres, Alessandro Finamore,
“Dissecting Video Server Selection Strategies in the YouTube CDN,”
2011.
80
[31] P. Gill, M. Arlitt, Z. Li, and A. Mahanti, “Youtube traffic characterization: A view from the edge,” in Proceedings of the 7th ACM SIGCOMM
Conference on Internet Measurement, IMC ’07, (New York, NY, USA),
pp. 15–28, ACM, 2007.
[32] A. Rafetseder, F. Metzger, D. Stezenbach, and K. Tutschku, “Exploring
youtube’s content distribution network through distributed applicationlayer measurements: A first view,” in Proceedings of the 2011 International Workshop on Modeling, Analysis, and Control of Complex Networks,
Cnet ’11, pp. 31–36, International Teletraffic Congress, 2011.
[33] A. Bestavros and M. Rabinovich, Web Caching and Content Delivery.
Access Online via Elsevier, 2001.
[34] L. Plissonneau, E. Biersack, and P. Juluri, “Analyzing the impact of
youtube delivery policies on user experience,” in Teletraffic Congress
(ITC 24), 2012 24th International, pp. 1–8, 2012.
[35] J. R. K. M. M. M. M. M. a. R. Ruben Torres, Alessandro Finamore,
“Dissecting video server selection strategies in the youtube cdn,” CDCS
11, 2011.
[36] F. S. F. FSF, “The Wget Wgiki,” tech. rep., 2012.
[37] I. Black Duck Software, “ohloh.net,” tech. rep., 2013.
[38] debian.org, “A console based download accelerator for Linux,” tech. rep.,
2010.
[39] Aria2, “aria2 - CLI Metalink/BitTorrent client,” tech. rep., 2013.
[40] M. K. Y. Y. N. M. S. K. G. P. Kok-Kiong Yap, Te-Yuan Huang, “Making
use of all the networks around us: A case study in android,” CellNet
2012, 2012.
[41] N. M. P. P. A. Bryan, T. Tsujikawa, “The metalink download description
format,” rfc5854., 2010.
[42] ITU, “Broadband: State of Broadband 2012,” tech. rep., 2012.
[43] A. Rao, A. Legout, and W. Dabbous, “Bittorrent experiments on testbeds: a study of the impact of network latencies,” 2010.
81
[44] R. Mahajan, N. Spring, D. Wetherall, and T. Anderson, “Inferring link
weights using end-to-end measurements,” in Proceedings of the 2nd ACM
SIGCOMM Workshop on Internet measurment, pp. 231–236, ACM,
2002.
[45] M. Zhang, J. Lai, A. Krishnamurthy, L. L. Peterson, and R. Y. Wang,
“A transport layer approach for improving end-to-end performance and
robustness using redundant paths.,” in USENIX Annual Technical Conference, General Track, pp. 99–112, 2004.
[46] http://manpages.ubuntu.com/manpages/hardy/man8/traceroute nanog.genuine.8.html, “Ubuntu manual,” tech. rep.
[47] B. Gueye, A. Ziviani, M. Crovella, and S. Fdida, “Constraint-based
geolocation of internet hosts,” Networking, IEEE/ACM Transactions
on, vol. 14, no. 6, pp. 1219–1232, 2006.
[48] P. Juluri, L. Plissonneau, Y. Zeng, and D. Medhi, “Viewing youtube
from a metropolitan area: What do users accessing from residential isps
experience?,”
[49] T. I. A. T. A. (IATA), “Iata codes,” 2013.
[50] S. Hemminger et al., “Network emulation with netem,” in Linux Conf
Au, pp. 18–23, Citeseer, 2005.
[51] http://torrentfreak.com/the-worlds-5-largest-public-bittorrent-trackers
100614/, “The worlds 5 largest public BitTorrent trackers,” tech. rep.,
2010.
82
CDN de Youtube.
ANEXOS
Profesor guía
Nicolás Boettcher Palma.
Comité
Phd. Diego Dujovne Helman
Phd. Luciano Ahumada Fierro.
Diciembre, 2013
Anexo A
Análisis detallado del protocolo BitTorrent.
El desarrollo de esta tesis exige un análisis en profundidad de este protocolo
tanto para la implementación de la solución en si, como para las futuras
mediciones en Título II. El trabajo presentado en este capítulo tiene valor en
si mismo ya que existe poco estudio previo en las referencias de este análisis
en particular.
Se detallará el comportamiento del protocolo BitTorrent a través de
experiencias prácticas donde se realizaron capturas del tráfico con la herramienta Wireshark para validar su funcionamiento. Los escenarios que se
escogieron son escenarios minimalistas que permitirán restringir muchos de
los factores externos que influyen en el desempeño de una descarga BitTorrent.
A.1.
Experiencia 1.
El cliente BitTorrent que se ocupará para esta experiencia es Vuze 3.1.
El archivo que se utilizará es una imagen de 114 KB, llamada “pruebatesis1.jpg” que se creará como archivo .torrent, se utilizó un archivo de este
tamaño dado que se busca generar poco tráfico y obtener la menor cantidad
de paquetes redundantes. Se utilizará el tracker público PublicBitTorrent, ya
que es uno de los más usados [51].
85
Como se ve en la Figura A.1, el escenario consta del seeder inicial y
un leecher el cual descargará el archivo mientras se ejecuta la herramienta
Wireshark para capturar tráfico.
Figura A.1: Escenario Experimental 1.
A.2.
Experiencia 2.
El segundo escenario experimental se realizará con un .txt llamado
“biblia_pruebatesis.torrent”, para ver como es el intercambio de piezas en
texto plano.
Como se ve en la Figura A.2, la experiencia se realizará con un seeder
inicial y un leecher y luego de esto se le agregará otro leecher para analizar
de qué peer descarga.
86
Figura A.2: Escenario Experimental 2.
A.3.
Descripción del protocolo.
Se utilizarán los resultados de las capturas realizadas en las experien-
cias A.1 y A.2 para validar cada parte de lo analizado en esta subsección.
La Figura A.3 muestra la estructura básica del diccionario contenido
en el archivo .torrent.
Figura A.3: Estructura del fichero .torrent de metainformación
87
Los parámetros de este diccionario depende de cada cliente que genera
el archivo .torrent, ya que algunos pueden agregar más información. Los
generales son los siguientes:
announce: cadena que representa la URL del tracker
info: Un diccionario que describe los archivos del torrent.
name: (cadena) El nombre del archivo o directorio donde se almacenarán los archivos.
creation date: (entero opcional) La fecha de creación del torrent en
formato de época UNIX.
comment: (cadena opcional) Campo libre para el creador del torrent.
created by: (cadena opcional) Nombre y versión del programa usado
para crear el archivo torrent.
Pieces length (entero): Número de bytes por pieza.
length (entero): Tamaño del archivo en bytes.
pieces: Cadena que representa la concatenación de la lista de claves hash
de cada pieza del fichero compartido. Las claves hash son generadas
utilizando SHA-1 con un resumen de 160 bits y un tamaño máximo por
parte de 264 bits. Este conjunto de claves se utiliza como mecanismo
para asegurar la integridad y consistencia de una pieza, una vez ha sido
completada la descarga de dicha pieza.
private: (opcional). Es un entero que puede tener valores 0 ó 1 y que
indica si se pueden buscar peers fuera de los trackers explícitamente
descritos en la metainformación o no.
La estructura de este fichero está almacenada según un esquema de
codificación que recibe el nombre de bencoding. En la Tabla A.1 se puede ver
el formato bencoding que permite codificar cuatro tipos de datos: números
enteros, cadenas de bytes, listas y diccionarios.
88
Tipo
Codificación
Entero
i(número decimal)e
Cadena bytes
(longuitud):(secuencia de bytes)
Lista
1(elemento1)(elemento2)e
Diccionario
d(elemento1)(elemento2)e
Tabla A.1: Codificación Bencoding
A.3.1.
Comunicación con el Tracker.
A efectos de coordinación, el cliente debe comunicarse periódicamente
con el tracker, como se mencionó en Capítulo 2. Para esto se debe hacer una
consulta HTTP que tiene las siguientes características:
El URL de la consulta HTTP será la que se obtiene del campo announce
contenido en el archivo .torrent, a la cual se le añaden al final una serie
de parámetros consistentes en pares de valores de la forma: param =
valor separados por caracteres &.
Para la consulta se utiliza el método GET.
A continuación, la validación de esta información utilizando la herramienta Wireshark. Esta captura (ver Subsección A.2) se hizo con la
intervención de un solo tracker público, otro de los más usados, http:
//exodus.desync.com/announce cuya IP es 208.83.20.164.
Los parámetros que se obtuvieron de la consulta son los siguientes:
info_hash: Que contiene el identificador de 20 bytes resultante de calcular
el código hash SHA1 de la codificación bencoding del valor asociado a
la entrada info del fichero .torrent.
peer_id: Que servirá para identificar al cliente mediante una secuencia
de 20 bytes. Dicha secuencia puede ser generada siguiendo un criterio
totalmente arbitrario. Esto permite fusionar distintas capas de red y
trabajar a nivel de aplicación.
port: Un valor numérico con el puerto en el cual el cliente atenderá a las
conexiones de los demás clientes.
89
left: Indicando con un valor numérico la cantidad de bytes que le restan al
cliente para terminar la descarga. Nótese que los valores que puedan
tomar algunos de los campos anteriores contendrán ocasionalmente caracteres no válidos para un URL, siendo necesario en este caso prevenir
la aparición de dichos caracteres no permitidos con las correspondientes
modificaciones en hexadecimal.
En la figura A.4, se puede observar la estructura de la respuesta del
tracker que contendrá una lista con los peers que pueden proporcionar alguna
parte del archivo.
Figura A.4: Estructura de la respuesta del tracker
Esta respuesta está codificada en formato bencoding, y se compone
de un diccionario con una serie de entradas que van a depender de cada
tracker, las entradas más comunes según una serie de respuestas de trackers
analizadas son:
Complete: Indica cuántos seeders contienen el archivo completo.
Incomplete: Indica cuantos peers están descargando el archivo pero aún
no se completa.
Interval: Indica mediante un valor entero el número de segundos que deben
transcurrir entre dos consultas sucesivas al tracker.
Min Interval: Muestra la cantidad mínima de tiempo que el tracker requiere para anunciar una nueva consulta. Este valor está determinado
por cada tracker.
Peers: Contiene la lista de IPs que contienen el archivo (6 caracteres, 4 de
la IP y 2 bytes extras)
90
Extrayendo el mensaje en texto plano, de la Figura A.5:
d8:completei1e10:downloadedi0e10:incompletei1e8:intervali1849e12:min
intervali924e5:peers12:(Codificación en carácteres de largo 12)e
Se leerá la respuesta del tracker para comprender mejor su funcionamiento. Se puede observar que el mensaje comienza con una ‘d’ y termina
con una ‘e’, eso en el lenguaje de bencoding se refiere a un diccionario. Luego
se observa ‘8:’ esto indica que a continuación viene un string con 8 caracteres, en este caso la palabra ‘complete’, seguido a esto vemos los siguiente
caracteres ‘i1e’ la cual es la forma de escribir los enteros, i<entero>e, que en
este caso es 1.
Por lo que en el caso de este ejemplo en particular se puede desprender
el siguiente mensaje:
completos: 1
downloaded: 0
incompleto: 1
intervalo: 1849
min intervalo: 924
peers: (IP del peer)
Como se ve en la Figura A.5, en el parámetro peers la IP viaja codificada.
Figura A.5: Respuesta del Tracker: peers.
91
Los peers en este caso constan de 12 caracteres, los cuales marcados
con un rectángulo rojo (Figura A.5) se pueden observar las IPs en codificación
hexadecimal que envió el tracker donde indicaba qué peers tiene el archivo
del .torrent que se requirió en la pregunta al tracker en primera instancia.
En este caso, (experiencia 2) en la respuesta aparecen dos IPs, la del seeder
inicial (ya que el archivo lo tenia solo un seeder, el inicial) y automáticamente
aparece la IP del peer que realizó la consulta al tracker agregándolo a la lista
de peers que tiene el archivo.
El peer inicial tiene la IP 190.160.86.193 la cual se traduce a hexadecimal y queda de la forma BE A0 56 C1 (segundo cuadro rojo), el leecher
tiene la IP 190.101.17.162 y su traducción en hexadecimal es BE 65 11 A2.
Aún así el largo del parámetro de peers consta de 12 caracteres y
las IPs ocupan 4 cada una, por lo que entre medio de cada IP existen dos
caracteres adicionales que constan de dos números hexadecimales los que
tienen 1 byte cada uno. Cada vez que se agrega un peer al sistema, se le
agregan 6 carácteres o valores hexadecimales al parámetro peer.
Conocer este proceso es fundamental ya que las IPs de los peers es un
parámetro de la propuesta de optimización.
A.3.2.
Comunicación entre clientes.
Un peer se comunicará con otros peers para intercambiar con éstos
partes del archivo de interés. En la Tabla A.2 se enumeran para tales efectos
una serie de mensajes correspondientes al protocolo BitTorrent.
92
ID
Nombre
Descripción
0
choke
Indicaciones al cliente solicitante que sus peticiones serán ignoradas
1
unchoke
Derogación de lo dispuesto por el mensaje choke
2
interested
Declaración de interés por alguna pieza
3
not interested
Derogación de lo dispuesto por el mensaje interested
4
have
Información a un cliente de que una parte ha sido completada
5
bitfield
Información de partes ya obtenidas
6
request
Solicitud de una pieza
7
piece
Transmisión de una pieza
8
cancel
Petición de cancelación de transmisión de una pieza
Tabla A.2: Tipos de Mensajes BitTorrent.
De todos los tipos de mensajes detallados en el protocolo, sólo unos
pocos son estrictamente necesarios para garantizar el funcionamiento del
mismo. Los mensajes de tipo choke, unchoke, interested, not interested,
have y cancel sirven para mejorar la eficiencia, pues se utilizan como un
mecanismo de señalización para poder regular las tasas de envío y evitar las
transmisiones redundantes. Los mensajes de ’choke’, ’unchoke’, ’interested’,
y ’not interested’ no poseen payload.
A.3.3.
Análisis de mensajes.
Mensaje Handshake.
Antes de que dos peers comiencen a intercambiar mensajes, es necesario transmitir una secuencia inicial con el objeto de identificarse y verificar
que el recurso al que se quiere acceder es el correcto.
Dicha secuencia mantiene la estructura descrita a continuación:
Figura A.6: Estructura de mensaje Handshake.
Largo del Nombre (pstrlen): Longuitud de cadena de caracteres (19).
Nombre (pstr): Cadena de caracteres (BitTorrent Protocol).
93
Reservado: Reservado para futuras ampliaciones.
info_hash: Indica el código hash SHA-1 de la sección info del archivo
.torrent (20 bytes de longitud).
peer_id: Cadena de 20 bytes con el identificador de un determinado cliente.
Será el mismo identificador que el utilizado para comunicarse con el
tracker.
Figura A.7: Captura de Handshake con Wireshark.
Una vez recibida esta secuencia de iniciación, el cliente decidirá si atender la conexión o cerrarla, en función de la coincidencia del valor info_hash
indicado con el del recurso compartido. Si ambos valores no son idénticos, se
cerrará la conexión.
Mensaje bitfield.
Este mensaje se envía inmediatamente después del handshaking e
indica las piezas del archivo que posee actualmente.
Figura A.8: Estructura de mensaje bitfield
Mensaje Request.
Este mensaje es para solicitar una pieza a otro peer, index indica el
número de la sub-pieza, se indica también un offset a partir del comienzo
la sub-pieza en caso de que ya se posea una parte de este y length indica
cuantos bytes se están solicitando. El payload contiene, por lo tanto, esos
tres campos de 4 bytes cada uno. En la Figura A.9 se puede ver la estructura
del mensaje y en la Figura A.10 validar los parámetros de este.
94
Figura A.9: Estructura de mensaje Request.
Figura A.10: Captura de Request con Wireshark.
Mensaje Pieces.
Este es el mensaje de respuesta al mensaje de tipo request, y contendrá
los datos solicitados por éste último. Como se puede ver en la Figura A.11, el
payload de este mensaje contiene tres campos; dos valores enteros (de 4 bytes
cada uno) y un tercer campo de longitud variable. Los dos primeros hacen
referencia al número de sub-pieza a la que pertenece la pieza transmitida y
al offset de dicha sub-pieza, mientras que "Tamaño pieza"(Data in piece) son
los datos enviados.
Figura A.11: Estructura de mensaje Piece.
Figura A.12: Mensaje piece en Wireshark.
95
En este caso particular en la experiencia 2, se envió un archivo .txt a
través del protocolo BitTorrent, por lo que si indagamos más profundamente
en este mensaje, podemos leer lo transferido ya que se realiza en texto plano.
En la Figura A.12 se observa una parte del .txt que se transfirió. Cabe
destacar que lo que se transfiere en este paquete es una sub-pieza de 16
KB (16384 bytes de payload (texto) + 13 bytes de información del mensaje
= 16397 bytes) (Figura A.11). Las sub-piezas contienen un ID, y se pudo
comprobar que dos sub-piezas llegan de forma consecutiva con el mismo ID,
pero con distinta data (se diferencian por el "Begin offset of piece"), es decir,
una pieza se completa antes de que llegue otra sub-pieza de otra pieza.
Figura A.13: Captura de Piece con Wireshark.
Como se puede ver en la Figura A.13 las sub-piezas se componen de
frames que viajan a través de TCP de distintos bytes de tamaño. Se pueden
denominar como sub-sub-piezas y estas no tienen un tamaño fijo.
96
Anexo B
Documentación.
B.1.
Documentación del Desarrollo en Aria2.
Aria2 es un software en desarrollo que posee actualmente 11 contribuyentes
y 116 releases y un total de 55 forks liderados por uno de los autores de
la norma de Metalink Tatsuhiro Tsukijawa. Aria2 está escrito en C/C++ y
tiene un tamaño considerable (más de 500 archivos de código).
El software está correctamente documentado desde el punto de vista
del usuario, pero desde el punto de vista del desarrollo no, por lo que la
única manera de conseguir información útil para el desarrollo es contactando directamente al autor y sus colaboradores más cercanos, o con mayor
experticia.
Para la construcción del software se utiliza un patrón de diseño OOP
(orientado a objetos) llamado comúnmente Abstract Factory, al menos para
la mayoría de los módulos.
B.1.1.
Archivos y Clases importantes para el desarrollo en
Aria2
Peer: Contiene la implementacion de la clase Peer y su header, permite
entender y editar los objetos Peer usados en el módulo BitTorrent.
97
PeerListenCommand: Hace la conexión scocket tcp con el peer, y crea
el peer.
ReciverMSEHandshakeCommand : Crea y usa el DownloadEngine.
DownloadEngine: Motor de descarga genérico para todos los módulos,
calcula las estadísticas a través de las otras clases descritas en esta
sección.
Aria2Api: Api con funciones útiles a todos los módulos y RequestGroups.
TransferStat: Sobrecarga los operadores (+,-,/, * ) de estadistica de la
conexión, estos son: downloadSpeed, uploadSpeed, sessionDownloadLength, sessionUploadLength.
ConsoleStatCalc: Calcula la velocidad de descarga y subida en int dl
= netstat.calculateDownloadSpeed().
SpeedCalc: Desde esta clase se puede acceder a el ancho de banda y el
tamaño de la ventana.
PeerInitiationCommand: Conexión con el peer.
OptionParser: Clase que parsea las opciones de parametro por consola.
main: Inicio del programa levanta a Platform y Context.
SocketCore: Clase que permite crear objetos de conexión Socket.
DefaultBtAnnounce: Contiene la respuesta de los trackers estructurada
como atributo de la clase.
BtRuntime: En el header de esta clase se define la cantidad de peers
máximo y mínimo que soporta la pila de storage.
static const int DEFAULT_MAX_PEERS = 55;
static const int DEFAULT_MIN_PEERS = 40;
B.2.
Control de versiones oficial para Aria2.
Todo el código del trabajo de esta memoria utiliza el controlador de
versiones GIT, y puede ser accesado en forma libre y bajo licencia GPL V2
en github.com/oceballos/aria2/. El código de los módulos se encuentra
en 2 ramas ‘master’ y ‘NEWMASTER’.
98
Si se desea trabajar en base al release oficial, se recomienda clonar el
repositorio github.com/tatsuhiro-t/aria2.
B.2.1.
Paso a paso.
1. Instalar git con: $sudo apt-get install git o $sudo yum install.
2. Crear una cuenta en github y acceder a github.
3. Buscar el fork de oceballos de aria2, https://https://github.com/
oceballos/aria2 clonar el repositorio, con $git clone. Está en la parte
derecha de la página descrita en 1.
Comandos.
$git clone <url del repositorio se obtiene en github> : Clonar los repositorios.
$git pull : Este comando sincroniza del server la última versión disponible que esta en el server y la pone en tu repositorio.
$git commit -a -m “mensaje del commit” : Para actualizar el repositorio
local con los cambios que se han hecho.
$git push : Para subir los cambios al repositorio de github.
$git config –global alias.undo-commit ‘reset –soft HEADˆ’ : Para volver
atrás un commit y después usar $git undo-commit.
$git checkout <nombre de la rama o branch>: cambia y/o crea una
nueva rama de desarrollo.
Para revertir a una versión anterior cualquiera se usa $git log, para
listar las versiones anteriores, y luego $git checkout
$git add <nombre del archivo> : Con este comando se puede agregar
un archivo al control de versiones, si no se usa por más que un archivo
nuevo esté en la carpeta repositorio no será considerado para el control
de versiones.
99
B.3.
Compilar Aria2.
Primero instalar las dependencias: En Fedora: gcc, gcc-c++, kernel-
devel, libgcrypt-devel, libgcrypt-devel, libxml2-devel, openssl-devel, gettextdevel, autoconf, automake, cppunit, libtorrent, libtorrent-devel, autopoint,
traceroute, youtube-dl, python-cookielib.
En la carpeta de principal de Aria2 ejecutar:
1. $autoreconf -fiv
2. $.configure
3. $make
4. #make install
Si no hay errores ejecutar:
$aria2c -h
Para ver las opciones de uso, si se desea más información usar:
$man aria2c
B.4.
Cómo agregar opciones a Aria2.
Esta sección describe la forma de agregar nuevas opciones a Aria2,
(no se refiere al código de la opción si no a cómo agregar un módulo propio
al programa). Siendo una de las cosas más útiles desde el punto de vista
general, pero más crípticas de la implementación realizada, se deja en este
anexo como una ayuda para los futuros investigadores que deseen utilizar el
software de descarga como base para sus desarrollos.
Archivos a considerar: prefs.cc, prefs.h , OptionHandlerImpl.cc, OptionHandlerFactory.cc , usage_text.h, help_tags.h, help_tags.cc, configure.ac .
1. Se debe editar las prefs.cc, agregando las constantes que definen la
opción con makepref. Acordarse de definir las constantes como .extern.en
pref.h.
2. Agregar la explicación de uso a usage_text.h, es de vital importancia
preocuparse de definir bien el define.
100
3. Verficar que tipo de objeto OptionHandler es la opción que se está
realizando, esto se revisa en OptionHandlerImpl.cc, para la opción de
CDNVIDEO se usó DefaultOptionHandler, pero podría usarse otro
dependiendo de lo que se desee hacer.
4. Definir el tag del argumento del help tag del optionHandler escogido
en el paso anterior en el enum de help_tags.h y .cc.
5. Definir la opción y lo que hace en OptionHandlerFactory.cc, pasándole
como argumento todas las características definidas en los pasos anteriores y (si se necesita) definiendo la letra de llamado (la ‘-T’ para los
torrent por ejemplo).
6. OPCIONAL: Se puede encapsular la opción como módulo aislado en
OptionHandlerFactory.cc usando #ifdef y #endif, pero para poder
hacer esto hay que editar configure.ac, buscando algún segmento libre
para definir:
ENABLE_ \dblquote{Mi opción con mayúsculas} [1]
7. Después de esto hay que recompilar (ver Compilar Aria2 desde el paso
3 en este mismo anexo).
101

Investigación para reducir el tráfico internacional - source url

Transcripción

Documentos relacionados

Descargar este archivo PDF - Revista Chilena de Derecho Informático

manual de descarga masiva

E117-S - FV Ecuador

P2P File Sharing Protocols