Logo

Capítulo 1 Por qué es más rápido: cuatro mecanismos clave

La ventaja de velocidad de FileBolt procede de la combinación de transporte, fragmentación en paralelo, topología global y planificación multifuente. Este capítulo explica, de forma auditable, qué mecanismos mejoran el rendimiento máximo y cuáles mejoran la estabilidad y la capacidad de recuperación ante pérdida de paquetes o cambios de red.

1.1 Objetivos de diseño (desde el punto de vista de la velocidad)

  • Objetivo A: acercarse al límite de ancho de banda. En condiciones normales, intentar saturar el ancho de banda disponible.
  • Objetivo B: rendimiento estable. Mantener un rendimiento utilizable con pérdidas, jitter, cambios de red y un RTT alto entre regiones, en lugar de que se desplome de golpe.
  • Objetivo C: fallos recuperables. Cuando se produzcan errores, limitar el coste a retransmitir solo una pequeña cantidad de datos y evitar empezar de nuevo desde el 0 %.

1.2 Optimización de la capa de transporte: HTTP/3 (QUIC)

  • El cliente y el punto de entrada del borde DEBERÍAN preferir HTTP/3 (QUIC). Cuando el navegador, la red o los dispositivos intermedios no lo admitan, el sistema DEBE recurrir automáticamente a HTTP/2 o HTTP/1.1 para preservar la disponibilidad.
  • Con pérdida de paquetes, el transporte y el control de congestión de QUIC suelen poder reducir el efecto del bloqueo de cabecera de línea en el rendimiento de extremo a extremo y mejorar la estabilidad (los resultados dependen de las condiciones de red).
  • 0-RTT y las rutas de negociación más rápidas son capacidades de reanudación de sesión en condiciones concretas: el sistema PUEDE beneficiarse de ellas cuando se cumplen esas condiciones, pero NO DEBE depender de ellas como única palanca de rendimiento.

Cómo verificarlo

  • En las herramientas para desarrolladores de tu navegador (por ejemplo, Network o Protocol; la interfaz varía según el navegador) puedes observar si las solicitudes usan h3 (HTTP/3) o recurren a h2/h1.
  • En las mismas condiciones de red, comparar el establecimiento de la conexión y la estabilidad del rendimiento con h3 y sin h3 (sobre todo con RTT alto o pérdidas) puede arrojar diferencias notables.

1.3 Concurrencia extrema: transmisión por fragmentos (Chunked Streaming)

  • El sistema DEBE dividir lógicamente los archivos grandes en varios fragmentos; cada fragmento es la unidad mínima de subida, reintento y recuperación (consulta el capítulo 2).
  • El cliente DEBERÍA transferir varios fragmentos con una concurrencia limitada (por ejemplo, varias canalizaciones en paralelo) para acercarse al límite de ancho de banda y reducir la sensibilidad al jitter de una única conexión.
  • El cliente DEBE admitir la transferencia reanudable: al recuperarse, omite los fragmentos completados y solo obtiene los que faltan, evitando retransmitir el archivo completo (consulta el capítulo 2).
  • La concurrencia y la fragmentación reducen de forma significativa la espera causada por el bloqueo de una única solicitud (incluidas las esperas por bloqueo de cabecera de línea y por retransmisión), pero NO DEBERÍAS afirmar que «eliminan por completo» ningún fenómeno de red concreto; el objetivo es reducir el impacto y mejorar la estabilidad del rendimiento.

Cómo verificarlo

  • En el panel Network puedes observar varias solicitudes de subida o descarga en paralelo al mismo tiempo (concurrencia de fragmentos).
  • Tras desconectar la red o recargar la página, reanudar una transferencia no debería empezar desde el 0 % (solo se completan los fragmentos que faltan).

1.4 Ventaja de topología: acceso Anycast al borde más cercano (red de borde)

  • El sistema DEBERÍA enrutar las solicitudes de los usuarios al nodo más cercano mediante Anycast o el punto de entrada del borde para reducir el RTT y la latencia y el jitter causados por los saltos entre regiones.
  • El acceso al borde más cercano mejora la eficiencia global de la fragmentación en paralelo: un RTT menor suele elevar el límite de rendimiento efectivo de cada flujo concurrente y facilita saturar el enlace.
  • La cobertura del borde y el número de ubicaciones pueden cambiar a medida que evoluciona la infraestructura; de cara al exterior, descríbelo como «cobertura de borde / punto de entrada más cercano» y considera las cifras como orientativas, no como garantías firmes.

Cómo verificarlo

  • Con traceroute o la información de conexión del navegador, a menudo puedes observar que las conexiones terminan en un punto de entrada más cercano (los métodos varían según el entorno).
  • En comparaciones entre regiones (por ejemplo, EE. UU.↔UE o JP↔EE. UU.), la reducción del RTT suele ser lo más visible.

1.5 Concurrencia multifuente: planificación inteligente (Multi-Source)

  • El sistema DEBERÍA tomar decisiones dinámicas basadas en señales de calidad del enlace (rendimiento, latencia, tasa de errores, etc.), de modo que los distintos fragmentos puedan asignarse a varios nodos o ubicaciones mejores y se reduzca el efecto de la congestión en un único punto sobre el rendimiento global.
  • En la descarga, el cliente PUEDE obtener fragmentos distintos de forma concurrente desde varias fuentes para lograr un efecto de aceleración de «descarga multifuente»; cuando no hay multifuente disponible, DEBE degradarse automáticamente a la descarga desde una sola fuente para preservar la disponibilidad (consulta el capítulo 3).
  • Si presentas esto como «IA», lo mejor es plantearlo como un sistema algorítmico de planificación y toma de decisiones, y definir con claridad las entradas, las salidas y el comportamiento de degradación para evitar afirmaciones vagas.

Cómo verificarlo

  • Durante la descarga puedes observar solicitudes concurrentes desde distintas fuentes o conexiones (según la implementación y lo que muestre el navegador).
  • Con congestión o pérdidas, la concurrencia multifuente suele ofrecer un rendimiento más estable; cuando no se cumplen las condiciones, se degrada automáticamente pero sigue siendo utilizable.

1.6 Cómo se relaciona con los siguientes capítulos

  • El capítulo 2 desarrolla «fragmentación, concurrencia, idempotencia y subida reanudable» en flujos y restricciones implementables (DEBE/DEBERÍA/PUEDE) y explica por qué determinan directamente la velocidad y la estabilidad de la subida.
  • El capítulo 3 explica «descarga en paralelo, recuperación y reensamblado», y cómo evitar la pérdida de velocidad por descargas redundantes en redes débiles.
  • El capítulo 4 conserva solo el modelo de almacenamiento mínimo relevante para el rendimiento y la capacidad de recuperación (capas de objetos y de estado, semántica de TTL y de eliminación).