Logo

Capítulo 2 Ruta de carga: fragmentación, simultaneidad y reanudación (clave)

En el lado de la carga, el objetivo es acercarse lo más posible a “saturar el ancho de banda” en redes fluctuantes, limitando al mismo tiempo el costo de las fallas al mínimo (retransmitir solo fragmentos fallidos). Juntos, estos dos objetivos explican en gran medida por qué las cargas se sienten más rápidas.

2.1 fragmentación

  • El cliente DEBE dividir el archivo en varios fragmentos; un fragmento es la unidad mínima para cargar/reintentar.
  • Los fragmentos DEBEN usar un tamaño fijo (o una política de tamaño por archivo) para simplificar la programación concurrente y la representación del estado.
  • Beneficio inmediato: cualquier error afecta sólo a un fragmento, no a todo el archivo.

2.2 Carga paralela

El propósito de la concurrencia no es “más subprocesos”, sino evitar tres limitaciones prácticas de una única conexión en redes reales:

  • Inicio lento y crecimiento de ventana: una única conexión aumenta lentamente, especialmente con un RTT alto entre regiones.
  • Vibración del enlace: la fluctuación en una conexión puede reducir la velocidad general; la concurrencia suaviza el efecto.
  • Conformación por flujo: algunas redes limitan un único flujo; múltiples flujos pueden acercarse al límite del ancho de banda (dentro de las limitaciones de cumplimiento).
  • El cliente DEBE usar concurrencia limitada (por ejemplo, 4 a 12) y reducirla en dispositivos más débiles para evitar picos de memoria.
  • El cliente PUEDE adaptar la concurrencia: aumentar cuando aumenta el rendimiento; disminuye cuando la tasa de error aumenta.

2.3 Idempotencia y reintento

  • Las cargas repetidas del mismo fragmento DEBEN ser idempotentes: los envíos duplicados no deben corromper un estado ya completado.
  • El servidor DEBE imponer la unicidad con (transferId, fileId, chunkIndex) o una restricción equivalente.
  • El cliente DEBE implementar reintentos de retroceso exponencial; Los fallos DEBEN reintentar sólo los fragmentos fallidos.

2.4 Carga reanudable

  • El servidor DEBE poder responder "qué fragmentos ya están cargados", para que el cliente pueda omitir los completados.
  • El conjunto cargado DEBE representarse como un mapa de bits/conjunto de rangos para evitar que el tamaño del estado crezca linealmente con el recuento de fragmentos.
  • Beneficio de velocidad: después de interrupciones de la red, fallas del navegador o cambios de red, la reanudación no se reinicia desde el 0%.

2.5 “Compartir mientras cargas” (opcional)

  • El sistema PUEDE generar un identificador de transferencia utilizable y un enlace compartido mientras la carga aún está en progreso para acelerar los flujos de trabajo de entrega.
  • Si se permite compartir antes de completar la carga, DEBE ser explícito lo que ven los destinatarios: el contenido incompleto aún no se puede descargar o solo se muestra el progreso.