Logo

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

La ventaja de velocidad de FileBolt proviene de una combinación de transporte, fragmentación paralela, topología global y programación de múltiples fuentes. 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 en caso de pérdida de paquetes o conmutación de red.

1.1 Objetivos de diseño (vista rápida)

  • Objetivo A: acercarse al límite del ancho de banda. En condiciones típicas, intente saturar el ancho de banda disponible.
  • Objetivo B: rendimiento estable. Mantenga el rendimiento utilizable en condiciones de pérdida, fluctuación, conmutación de red y RTT alto entre regiones, en lugar de colapsar repentinamente.
  • Meta C: Fallas recuperables. Cuando se produzcan errores, limite el coste a retransmitir sólo una pequeña cantidad de datos; evite reiniciar desde el 0%.

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

  • El cliente y el ingreso de borde DEBEN preferir HTTP/3 (QUIC). Cuando el navegador, la red o los middleboxes no lo admiten, el sistema DEBE recurrir automáticamente a HTTP/2/HTTP/1.1. para preservar la disponibilidad.
  • En caso de pérdida de paquetes, el control de congestión y transporte de QUIC a menudo puede reducir el impacto del bloqueo de cabecera de línea en el rendimiento de un extremo a otro, mejorando la estabilidad (los resultados dependen de las condiciones de la red).
  • 0-RTT/rutas de protocolo de enlace más rápidas son capacidades de reanudación de sesión en condiciones específicas: el sistema PUEDE beneficiarse cuando se cumplen las condiciones, pero NO DEBE depender de ellas como única palanca de rendimiento.

Cómo verificar

  • En las DevTools de su navegador (por ejemplo, Red/Protocolo; la interfaz de usuario varía según el navegador), puede observar si las solicitudes usan h3 (HTTP/3) o recurren a h2/h1.
  • En las mismas condiciones de red, comparar la configuración de la conexión h3 con la que no es h3 y la estabilidad del rendimiento (especialmente con un alto RTT/pérdida) puede ser notablemente diferente.

1.3 Concurrencia extrema: transmisión fragmentada (Chunked Streaming)

  • El sistema DEBE dividir lógicamente los archivos grandes en varios fragmentos; cada fragmento es la unidad mínima para carga/reintento/recuperación (consulte el Capítulo 2).
  • El cliente DEBE transferir múltiples fragmentos con simultaneidad limitada (por ejemplo, varias canalizaciones paralelas) para acercarse al techo del ancho de banda y reducir la sensibilidad a la fluctuación de una sola conexión.
  • El cliente DEBE admitir la transferencia reanudable: en la recuperación, omita los fragmentos completados y solo recupere los que faltan, evitando la retransmisión del archivo completo (consulte el Capítulo 2).
  • La concurrencia y la fragmentación reducen significativamente la espera causada por el bloqueo de una sola solicitud (incluidas las esperas de cabecera de línea y de retransmisión), pero NO DEBE pretender "eliminar por completo" ningún fenómeno de red específico; el objetivo es reducir el impacto y mejorar el rendimiento estable.

Cómo verificar

  • En el panel Red puede observar múltiples solicitudes de carga/descarga paralelas al mismo tiempo (simultaneidad de fragmentos).
  • Después de desconectar la red o actualizar la página, la reanudación de una transferencia no debería reiniciarse desde el 0% (solo se completan los fragmentos que faltan).

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

  • El sistema DEBE enrutar las solicitudes del usuario a un nodo más cercano a través de Anycast/ingreso de borde para reducir el RTT y la latencia/jitter causada por los saltos entre regiones.
  • El acceso al borde más cercano mejora la eficiencia general de la fragmentación paralela: un RTT más bajo generalmente aumenta el límite de rendimiento efectivo de cada flujo concurrente, lo que facilita la saturación del enlace.
  • La cobertura de borde y los recuentos de ubicación pueden cambiar a medida que evoluciona la infraestructura; externamente, descríbalo como “cobertura de borde/ingreso más cercano” y trate los números como orientación en lugar de garantías estrictas.

Cómo verificar

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

1.5 Concurrencia de múltiples fuentes: programación inteligente (Multi-Source)

  • El sistema DEBE tomar decisiones dinámicas basadas en señales de calidad del enlace (rendimiento, latencia, tasa de error, etc.), de modo que se puedan asignar diferentes fragmentos a múltiples nodos/ubicaciones mejores. reducir el impacto de la congestión de un solo punto en el rendimiento general.
  • Durante la descarga, el cliente PUEDE recuperar diferentes fragmentos simultáneamente de múltiples fuentes para lograr un efecto de aceleración de "extracción de múltiples fuentes"; cuando la fuente múltiple no está disponible, DEBE degradarse automáticamente a descarga de fuente única para preservar la disponibilidad (ver Capítulo 3).
  • Si comercializa esto como "IA", es mejor enmarcarlo como un sistema algorítmico para la programación y la toma de decisiones, y definir claramente las entradas/salidas y el comportamiento de degradación para evitar afirmaciones vagas.

Cómo verificar

  • Durante la descarga, es posible que observe solicitudes simultáneas de diferentes fuentes/conexiones (según la implementación y la visibilidad del navegador).
  • En situaciones de congestión o pérdida, la concurrencia de múltiples fuentes a menudo ofrece un rendimiento más estable; cuando no se cumplen las condiciones, se degradará automáticamente pero seguirá siendo utilizable.

1.6 Cómo se relaciona esto con los próximos capítulos

  • El Capítulo 2 amplía la “fragmentación, concurrencia, idempotencia y carga reanudable” en flujos y restricciones implementables (DEBE/DEBE/MAYO) y explica por qué determinan directamente la velocidad y la estabilidad de la carga.
  • El Capítulo 3 explica “descarga, recuperación y reensamblaje paralelos” y cómo evitar la pérdida de velocidad debido a descargas redundantes en redes débiles.
  • El Capítulo 4 mantiene solo el modelo de almacenamiento mínimo relevante para el rendimiento y la capacidad de recuperación (capas de objeto versus estado, TTL/semántica de eliminación).