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

En la subida, el objetivo es acercarse lo máximo posible a «saturar el ancho de banda» en redes fluctuantes, y limitar al mínimo el coste de los fallos (retransmitir solo los fragmentos fallidos). Juntos, estos dos objetivos explican en gran medida por qué las subidas 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 de subida y reintento.
  • Los fragmentos DEBERÍAN tener un tamaño fijo (o un tamaño según una política por archivo) para simplificar la planificación de la concurrencia y la representación del estado.
  • Ventaja inmediata: cualquier fallo afecta solo a un fragmento, no al archivo completo.

2.2 Subida en paralelo

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

  • Arranque lento y crecimiento de la ventana: una única conexión tarda en alcanzar su velocidad, sobre todo con un RTT alto entre regiones.
  • Jitter del enlace: el jitter de una conexión puede reducir la velocidad global; la concurrencia suaviza el efecto.
  • Limitación por flujo: algunas redes limitan un único flujo; varios flujos pueden acercarse más al límite de ancho de banda (dentro de las restricciones de cumplimiento).
  • El cliente DEBERÍA usar una concurrencia limitada (por ejemplo, de 4 a 12) y reducirla en dispositivos más débiles para evitar picos de memoria.
  • El cliente PUEDE adaptar la concurrencia: aumentarla cuando sube el rendimiento y reducirla cuando sube la tasa de errores.

2.3 Idempotencia y reintentos

  • Las subidas repetidas del mismo fragmento DEBEN ser idempotentes: los envíos duplicados no deben corromper un estado ya completado.
  • El servidor DEBERÍA garantizar la unicidad con (transferId, fileId, chunkIndex) o una restricción equivalente.
  • El cliente DEBE implementar reintentos con espera exponencial (exponential backoff); ante fallos, DEBERÍA reintentar solo los fragmentos fallidos.

2.4 Subida reanudable

  • El servidor DEBE poder responder «qué fragmentos ya están subidos», para que el cliente pueda omitir los completados.
  • El conjunto de fragmentos subidos DEBERÍA representarse como un mapa de bits o un conjunto de rangos para evitar que el tamaño del estado crezca linealmente con el número de fragmentos.
  • Ventaja de velocidad: tras interrupciones de la red, cierres inesperados del navegador o cambios de red, la reanudación no empieza desde el 0 %.

2.5 «Compartir mientras se sube» (opcional)

  • El sistema PUEDE generar un identificador de transferencia y un enlace para compartir utilizables mientras la subida sigue en curso, para acelerar los flujos de entrega.
  • Si se permite compartir antes de que termine la subida, DEBE quedar explícito qué ven los destinatarios: el contenido incompleto aún no se puede descargar, o solo se muestra el progreso.