Investigación para reducir el tráfico internacional - source url
Transcripción
Investigación para reducir el tráfico internacional - source url
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 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 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... http://r2---sn-nja7sn7r.c... http://r3---sn-nja7sn7r.c... http://r4---sn-nja7sn7r.c... ... http://r20---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 <? xml version ="1.0" encoding =" UTF -8" ? > 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 <? xml version ="1.0" encoding =" UTF -8" ? > 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 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. 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
Documentos relacionados
P2P File Sharing Protocols
Redes Centralizadas Corresponde a la Primera Generación de P2P File Sharing. Las transacciones se hacen a través de un único servidor que sirve de punto de enlace entre dos nodos. Los clientes se i...
Más detalles