Estudio de BIT TORRENT

Estudio de BITTORRENT Autores Oscar Barrios Jonathan Hernández Que es BITTORRENT?  Protocolo de distribución de ficheros P2P  Autor: Bram Cohen   Programa cliente oficial  Open Source  Escrito en Python Estudio realizado por: Jonathan Hernández y Oscar Barrios 2 Que lo diferencia?  Optimizado para la replicación y distribución de  contenidos  Mayor velocidad de descarga  No implementa búsqueda de contenidos  Resulta difícil encontrar material que no sea  novedoso  Estudio realizado por: Jonathan Hernández y Oscar Barrios 3 Incentivos para compartir  Sigue una estrategia “Tit for Tat”  Negociación entre peers  Si un peer no comparte su información, los peer con  los que mantiene comunicación actuaran del mismo  modo  Utiliza una variante que perdona al peer egoísta cada  N segundos, si este ha comenzado a compartir Estudio realizado por: Jonathan Hernández y Oscar Barrios 4 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 5 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker Cliente que aún no  tiene el fichero  completo Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 6 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker Cliente que  comparte todas las  partes de un fichero Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 7 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker Único punto de  coordinación entre  peers que comparten  un mismo fichero Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 8 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent .torre nt Tracker Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 9 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent T)  E P G T (HT   ulta s on C Tracker Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 10 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker rs ee  p de a  t Lis Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 11 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker rs ee  p de a  t Lis Subconjunto  aleatorio Peer [Seed] Peer [Leech] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 12 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker Negociación Ne go c ia Peer [Leech] c ió n Peer [Seed] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 13 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker les Info: Partes disponib Inf o dis : Pa r po nib tes  Peer [Leech] les Peer [Seed] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 14 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker cheros ndo partes de los fi Compartie Peer [Leech] Pa rte s Peer [Seed] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 15 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker Partes Peer [Leech] P art Pa rte s es Peer [Seed] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 16 Arquitectura Web Server ina web  Página web   ficheros con ficheros  .torrent Tracker Swarm Partes Peer [Leech] P art Pa rte s es Peer [Seed] Peer [Leech] Estudio realizado por: Jonathan Hernández y Oscar Barrios 17 Comunicación  Peer – Peer mensajes  TCP Sockets  Peer – Tracker mensajes   HTTP Petición/Respuesta  B­encoding:   Codificación propia para estructurar  metainformación, soporta :   Cadena de bytes, enteros, listas y diccionarios Estudio realizado por: Jonathan Hernández y Oscar Barrios 18 Swarming  Todos los peers comparten aquellas partes del  fichero que poseen, de forma inmediata a la  descarga  Comparten partes simultáneamente entre  varios peers  Técnica utilizada por otras redes como  eDonkey Estudio realizado por: Jonathan Hernández y Oscar Barrios 19 Ficheros .torrent  URL del tracker  Lista de claves hash por cada parte del  contenido   Tamaño de una parte  Nombre  Tamaño del contenido  Fichero/s que contiene  Nombre (puede incluir un path)  Tamaño en bytes Estudio realizado por: Jonathan Hernández y Oscar Barrios 20 Ficheros .torrent  Las claves hash son generadas utilizando  SHA­1 :  Resumen de : 160 bits  Tamaño máximo de cada parte : 264 bits  Utiliza las claves como mecanismo para  asegurar la consistencia de datos en la  descarga de cada parte Estudio realizado por: Jonathan Hernández y Oscar Barrios 21 Tipos de Mensaje  En la comunicación entre peers, se  establece un conjunto de  identificadores de mensaje  Permiten compartir las partes de un  fichero  Además, ofrecen soporte para seguir  una estrategia Tit for Tat Estudio realizado por: Jonathan Hernández y Oscar Barrios 22 Tipos de Mensaje  Keep­alive:   Mensaje de longitud cero, enviado para mantener la  comunicación  Choke / Unchocke:   Mensaje que comunica al receptor de un bloqueo  temporal en la transferencia de información  Interested / Not Interested:   Mensaje que comunica de un interés por parte del  emisor en los ficheros que el receptor ofrece  Estudio realizado por: Jonathan Hernández y Oscar Barrios 23 Tipos de Mensaje  Have:   Mensaje enviado cuando una parte esta descargada y  verificada, y por tanto puede compartirse  Bitfield:   Solamente puede enviarse inmediatamente después de  establecer la conexión. Envía la lista de partes que puede  compartir, en caso de tener alguna  Request:   Mensaje de petición de un bloque de datos, se especifica el  tamaño del bloque, el número de parte y un offset Estudio realizado por: Jonathan Hernández y Oscar Barrios 24 Tipos de Mensaje  Piece:   Mensaje que envía un bloque de datos de una parte, se  especifica el número de pieza, un offset y la medida del  bloque  Cancel:   Mensaje para cancelar las peticiones de bloques  Port:   Mensaje que informa del puerto de escucha si este peer se  encuentra como parte de un DHT tracker (soportado por las  últimas versiones) Estudio realizado por: Jonathan Hernández y Oscar Barrios 25 DHT y BITTORRENT  Problema del cuello de botella  ¡¡Todos contra el tracker!!  Concepto de DHT Tracker:   Distribuir la carga del tracker entre los peers. Capa  independiente del protocolo Bittorrent.  Antes sólo había caché individual de peers desde el  cliente para responder ante fallo del tracker. Estudio realizado por: Jonathan Hernández y Oscar Barrios 26 DHT y BITTORRENT  Características  Utiliza un puerto UDP para la comunicación entre  nodos.  El ID del nodo es el algoritmo de SHA­1 aplicado a  la IP y el puerto utilizado de cada nodo.  Implementaciones:  Azureus, Bittorrent 4.1.2 beta+, Bitcomet ...etc.  Como base Kademlia, pero extendido.  Incompatibles... why?? Estudio realizado por: Jonathan Hernández y Oscar Barrios 27 DHT y BITTORRENT  ¿Modelo descentralizado?  Tracker y .torrent necesarios para entrar  Magnet links en Azureus  Problemas con los trackers privados  Control del contenido entre usuarios/IP registradas.  Private flag  Otras utilidades  Ratings y Comments Estudio realizado por: Jonathan Hernández y Oscar Barrios 28 Comportamiento  Escalabilidad  Con millones de peers, el tracker utiliza 1/1000 de  ancho de banda. No es poco.  Miles de peers desde el principio sigue una  distribución de este tipo: kb/s t  La escalabilidad depende mayoritariamente del  ancho de banda del Tracker. DHT ayuda.  Estudio realizado por: Jonathan Hernández y Oscar Barrios 29 Comportamiento  Robustez y tolerancia a fallidas  Si el tracker cae:  Nuevos nodos no pueden conectarse  Nodos conectados no descubren nuevos nodos  Pequeñas islas de nodos Estudio realizado por: Jonathan Hernández y Oscar Barrios 30 Comportamiento  Ataques sobre Bittorrent  Modelo P2P económico – Es inocente  Soluciones a nivel de cliente  Malicious upload attack  Envio constante de archivos corruptos.  Vigiliar a nivel de cliente y bloquear la IP.  Sybil attack  ID Bittorent = Hash de IP+Time  Múltiples identidades desde un cliente ­ DoS Estudio realizado por: Jonathan Hernández y Oscar Barrios 31 Comportamiento  Ataques sobre Bittorrent  Seed only attack  Se intenta conectar sólo a seeds. Bittfield a 1's  indica que es un seed. Fáciles de identificar.  Sin necesidad de subir nada.  Minimal upload attack  Mismo incentivo si subes a 1kb/s que a 10kb/s  Objetivo, mínimo para entrar en la lista de  preferred peers de los otros nodos.  Combinado con el Sybil attack. Estudio realizado por: Jonathan Hernández y Oscar Barrios 32 Limitaciones  Confía en la gente  Incentivos sólo para los peers  No hay motivación para los seeds, altruísmo.  20%­40% usuarios Napster comparten poco o  nada. 70% en el caso de Gnutella.  Desconocimiento.  Nettiquette  Esta mal visto dejar de compartir un recurso  cuando has acabado de descargarlo si el índice  de compartición < 1.0 Estudio realizado por: Jonathan Hernández y Oscar Barrios 33 Limitaciones  ¿Afecta al rendimiento?  Oh God, yes. kb/s t  Private trackers  Restrictivos respecto al índice de compartición Estudio realizado por: Jonathan Hernández y Oscar Barrios 34 Limitaciones  Descarga partes al azar  Por defecto sigue un algoritmo en que tienen  prioridad los “trozos más raros” (los que tienen  menos peers).  También el modo SuperCompartición, donde se  priorizan las partes que no han sido todavía  descargadas (al principio).  Buenos para distribuir rápidamente el recurso  Imposibilita el progressive download o el streaming  playback. Solución: priorizar primeras partes. Estudio realizado por: Jonathan Hernández y Oscar Barrios 35 Limitaciones  Boot­strapping  Sigue algoritmo TIT for TAT, so...  Pag 4. “Si un peer no comparte su información, los  peer con los que mantiene comunicación actuaran  del mismo modo”  Nuevos nodos no tienen aún información... Una solución quiero Estudio realizado por: Jonathan Hernández y Oscar Barrios 36 Limitaciones  Optimistic unchoking (i)  Los peers tienen su lista de N nodos más rápidos  de los que descarga/sube información: Preferred  peer list.  Pero también son curiosos, periódicamente intentan  descubrir nodos más rápidos. % Upload destinado. Estudio realizado por: Jonathan Hernández y Oscar Barrios 37 Limitaciones  Optimistic unchoking (ii)  Un nuevo nodo tiene que esperar a que los demás  por “optimistic unchoke” le complete almenos una  parte para poder empezar a compartir y formar  parte del TIT for TAT.  Suele tardar entre 5­10 minutos en estabilizarse la  lista de preferred peers. Estudio realizado por: Jonathan Hernández y Oscar Barrios 38 The End   ¿Preguntas? Estudio realizado por: Jonathan Hernández y Oscar Barrios 39