Resumen
- BitTorrent trasladó buena parte del tráfico de salida de un archivo popular desde quien lo publicaba hacia quienes lo descargaban. El servidor web, el tracker y la semilla que tenía el archivo entero siguieron siendo parte del sistema.
- El choking recíproco de Cohen era una política del cliente, no una obligación del protocolo de red. Un par podía subir más de lo que recibía, aportar solo lo que mejoraba su propia descarga o dejar de compartir.
- Un estudio de 2007 mostró que un cliente estratégico podía reducir sus subidas y mejorar su rendimiento individual. Sus resultados describen las redes y mediciones estudiadas entonces, no todos los enjambres posteriores.
El servidor deja de cargar con cada copia
En una descarga HTTP tradicional, el servidor de origen entrega cada copia. Si un archivo atrae de repente a una gran audiencia, el editor debe contratar más capacidad de salida o aceptar esperas mayores. En su trabajo de 2003, Bram Cohen propuso repartir esa tarea: cuando varias personas descargan el mismo archivo, pueden intercambiar fragmentos y convertirse en puntos de distribución.
El cambio está en quién aporta capacidad. El servidor del editor inicia la distribución, pero los pares añaden ancho de banda de subida a medida que llegan y obtienen piezas útiles. Cohen sostuvo que así podría resultar asequible ofrecer archivos muy populares, especialmente cuando la subida de los usuarios no se facturaba por volumen. Esa condición importa. Que una conexión sea ilimitada en la factura no significa que la electricidad, la capacidad de red o el tiempo de mantenimiento sean gratuitos; tampoco describe todos los planes de acceso.
La función de origen no desaparece. El editor publica un archivo de metadatos .torrent en un servidor web corriente; un tracker ayuda a que los descargadores se encuentren; y una semilla con el archivo completo debe poner en marcha el proceso. Cohen consideraba que el servidor web y el tracker requerían poco ancho de banda frente a la transferencia del archivo, pero la semilla tenía que enviar al menos una copia completa. El protocolo redistribuye el flujo principal, no borra su punto de partida.
Por eso, decir que BitTorrent abarata automáticamente el alojamiento va demasiado lejos. Puede reducir los bytes que envía el editor, pero el efecto sobre su factura depende del precio del ancho de banda, de los límites de capacidad, de cuántos pares suben datos y de cuánto tiempo se mantiene una copia completa. La tarea no se elimina: se desplaza desde el proveedor hacia una combinación de participantes y operadores.
Una regla de reciprocidad con límites claros
Cohen describe clientes que deciden a quién subir datos mediante una variante del tit-for-tat. Un cliente puede hacer choking de una conexión: retener temporalmente las subidas sin cortar la posibilidad de descargar. También puede aplicar un optimistic unchoke, una prueba periódica con un par que no estaba recibiendo datos. Esa prueba permite descubrir si una conexión nueva funciona mejor que las que ya aportan.
La precisión técnica cambia la interpretación. Cohen dice expresamente que el algoritmo de choking no forma parte, en sentido estricto, del protocolo de red de BitTorrent. El protocolo permite intercambiar datos y señales; la selección de los pares a los que cada cliente sirve es una política de implementación. Por eso, afirmar que «BitTorrent garantiza la reciprocidad» exagera lo que exige la capa común. El comportamiento del cliente, los fragmentos disponibles, la rotación de conexiones y la capacidad libre determinan el resultado.
También importa la decisión del editor. Cohen señala que es el propietario del archivo quien decide usar BitTorrent, mientras que los usuarios lo adoptan porque quieren obtener ese archivo. Añade que una interfaz sencilla —hacer clic y guardar— contribuyó mucho a la adopción y quizá importó más que las mejoras de rendimiento o la redistribución de costes. Una buena regla de incentivos no compensa una experiencia de uso difícil.
La prueba de estrés de 2007
En 2007, Michael Piatek, Tomas Isdal, Thomas Anderson, Arvind Krishnamurthy y Arun Venkataramani revisaron si los incentivos hacían robusto a BitTorrent. Su estudio de USENIX, basado en modelos alimentados por trazas reales, encontró recursos que los pares aportaban sin que mejoraran directamente su propio rendimiento. El cliente BitTyrant intentaba aprovechar ese margen ajustando los pares activos y la tasa de subida destinada a cada uno.
El resumen de la conferencia informa de una mejora mediana del 70% para un cliente de 1 Mbit/s en los enjambres reales que midieron. Los autores advierten asimismo que una adopción universal de clientes estratégicos podía reducir el rendimiento medio por enjambre frente a las implementaciones comparadas. El hallazgo cuestiona que el tit-for-tat bastara para asegurar una contribución robusta. No establece qué hacen todos los clientes ni cómo funcionan los enjambres actuales; el 70% no es una promesa general.
La diferencia está entre orientar un intercambio e imponer una aportación. La reciprocidad local podía premiar subidas útiles, pero las pruebas optimistas y las capacidades desiguales dejaban aportes que no se devolvían de forma directa. Un cliente estratégico podía intentar capturar parte de ese valor. Si muchos lo hacían, el efecto sobre una red concreta dependería del comportamiento de los pares y de la capacidad que quedara disponible.
El editor conserva una palanca decisiva
El editor inicia la distribución al publicar los metadatos, mantener un tracker u otra vía de descubrimiento y arrancar una semilla completa. Después, cada cliente controla su propia aportación. En el diseño que describe Cohen no hay un asignador central que reparta a cada usuario una cuota obligatoria de subida.
Esa separación da flexibilidad y crea una exposición. El editor puede aprovechar los pares para escalar la distribución sin comprar por sí solo toda la capacidad de salida. Cada participante elige cuánto tiempo mantiene el cliente compartiendo. Sin embargo, la existencia del protocolo no demuestra que vaya a haber capacidad de subida duradera. Si la semilla se desconecta antes de que todas las piezas se hayan replicado, o desaparece el último par que conserva una pieza rara, el archivo puede quedar incompleto.
La selección «rarest first» ayuda a copiar antes los fragmentos escasos, pero no puede recuperarlos después de que desaparezca su última copia.
La pregunta operativa no es si BitTorrent «resolvió» el alojamiento. Es qué parte del tráfico sigue originando el editor, cuánto absorben de verdad los pares y qué mantiene disponible una copia íntegra cuando la demanda baja. Cohen convirtió a los descargadores en distribuidores potenciales. Los estudios posteriores explican por qué esa capacidad se debe medir, no dar por sentada.
Fuentes
- Bram Cohen, «Incentives Build Robustness in BitTorrent» (2003).
- Bram Cohen, BEP 3: especificación del protocolo BitTorrent.
- Michael Piatek et al., «Do Incentives Build Robustness in BitTorrent?» (USENIX NSDI 2007), con el artículo completo.
- Heng Lu, « Especificación inicial mínima, decisión futura localizada y adopción voluntaria para sistemas de coordinación de Internet » (Nota 64). Se cita solo como marco editorial, no como evidencia sobre Cohen o BitTorrent.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
