Logo

Capítulo 1 Por que é mais rápido: quatro mecanismos principais

A vantagem de velocidade do FileBolt vem da combinação de transporte, divisão paralela em chunks, topologia global e agendamento multifonte. Este capítulo explica, de forma auditável, quais mecanismos melhoram a taxa de transferência de pico e quais melhoram a estabilidade e a capacidade de recuperação sob perda de pacotes ou troca de rede.

1.1 Objetivos de projeto (do ponto de vista da velocidade)

  • Meta A: aproximar-se do teto de largura de banda. Em condições típicas, procure saturar a largura de banda disponível.
  • Meta B: taxa de transferência estável. Mantenha uma taxa de transferência utilizável sob perda de pacotes, jitter, troca de rede e RTT alto entre regiões, em vez de entrar em colapso de repente.
  • Meta C: falhas recuperáveis. Quando ocorrerem erros, limite o custo à retransmissão de apenas uma pequena quantidade de dados, evitando recomeçar do 0%.

1.2 Otimização da camada de transporte: HTTP/3 (QUIC)

  • O cliente e a entrada de borda DEVERIAM preferir HTTP/3 (QUIC). Quando o navegador, a rede ou middleboxes não o suportam, o sistema DEVE recorrer automaticamente a HTTP/2 / HTTP/1.1 para preservar a disponibilidade.
  • Sob perda de pacotes, o transporte e o controle de congestionamento do QUIC costumam reduzir o impacto do bloqueio head-of-line na taxa de transferência de ponta a ponta, melhorando a estabilidade (os resultados dependem das condições da rede).
  • 0-RTT / caminhos de handshake mais rápidos são recursos de retomada de sessão sob condições específicas: o sistema PODE se beneficiar quando as condições forem atendidas, mas NÃO DEVE depender deles como única alavanca de desempenho.

Como verificar

  • Nas DevTools do navegador (por exemplo, Rede / Protocolo; a interface varia conforme o navegador), você pode observar se as requisições usam h3 (HTTP/3) ou recorrem a h2/h1.
  • Sob as mesmas condições de rede, comparar o estabelecimento de conexão e a estabilidade da taxa de transferência com h3 e sem h3 (especialmente sob RTT alto / perda de pacotes) pode mostrar diferenças notáveis.

1.3 Simultaneidade extrema: streaming em chunks (Chunked Streaming)

  • O sistema DEVE dividir logicamente os arquivos grandes em vários chunks; cada chunk é a unidade mínima de upload/nova tentativa/recuperação (veja o Capítulo 2).
  • O cliente DEVERIA transferir vários chunks com simultaneidade limitada (por exemplo, vários pipelines paralelos) para chegar mais perto do teto de largura de banda e reduzir a sensibilidade ao jitter de uma única conexão.
  • O cliente DEVE suportar transferência retomável: na recuperação, ele pula os chunks já concluídos e busca apenas os que faltam, evitando retransmitir o arquivo inteiro (veja o Capítulo 2).
  • A simultaneidade e a divisão em chunks reduzem significativamente a espera causada pelo bloqueio de uma única requisição (incluindo head-of-line e esperas por retransmissão), mas você NÃO DEVERIA afirmar que “elimina completamente” qualquer fenômeno de rede específico; o objetivo é reduzir o impacto e melhorar a estabilidade da taxa de transferência.

Como verificar

  • No painel Rede, você pode observar várias requisições paralelas de upload/download ao mesmo tempo (simultaneidade de chunks).
  • Depois de desconectar a rede ou atualizar a página, retomar uma transferência não deve recomeçar do 0% (apenas os chunks que faltam são concluídos).

1.4 Vantagem da topologia: acesso Anycast à borda mais próxima (rede de borda)

  • O sistema DEVERIA rotear as requisições do usuário para o nó mais próximo via Anycast / entrada de borda, para reduzir o RTT e a latência/jitter causados por saltos entre regiões.
  • O acesso à borda mais próxima melhora a eficiência geral da divisão paralela em chunks: um RTT menor normalmente eleva o teto efetivo de taxa de transferência de cada fluxo concorrente, facilitando a saturação do link.
  • A cobertura da borda e o número de locais podem mudar à medida que a infraestrutura evolui; externamente, descreva isso como “cobertura de borda / entrada mais próxima” e trate os números como referência, não como garantias firmes.

Como verificar

  • Com o traceroute ou as informações de conexão do navegador, muitas vezes é possível observar que as conexões terminam em uma entrada mais próxima (os métodos variam conforme o ambiente).
  • Em comparações entre regiões (por exemplo, EUA↔UE / JP↔EUA), a redução do RTT costuma ser a mais visível.

1.5 Simultaneidade multifonte: agendamento inteligente (Multi-Source)

  • O sistema DEVERIA fazer escolhas dinâmicas com base em sinais de qualidade do link (taxa de transferência, latência, taxa de erro etc.), para que chunks diferentes possam ser atribuídos a vários nós/locais melhores, reduzindo o impacto do congestionamento em um único ponto sobre a taxa de transferência geral.
  • No download, o cliente PODE buscar chunks diferentes ao mesmo tempo a partir de várias fontes, obtendo um efeito de aceleração de “download multifonte”; quando o multifonte não está disponível, DEVE degradar automaticamente para o download de fonte única para preservar a disponibilidade (veja o Capítulo 3).
  • Se você divulgar isso como “IA”, é melhor apresentá-lo como um sistema algorítmico de agendamento e tomada de decisão e definir claramente entradas/saídas e o comportamento de degradação, para evitar afirmações vagas.

Como verificar

  • Durante o download, você pode observar requisições simultâneas de diferentes fontes / conexões (dependendo da implementação e do que o navegador exibe).
  • Sob congestionamento ou perda de pacotes, a simultaneidade multifonte costuma oferecer uma taxa de transferência mais estável; quando as condições não são atendidas, ela degrada automaticamente, mas continua utilizável.

1.6 Como isso se relaciona com os próximos capítulos

  • O Capítulo 2 detalha “divisão em chunks, simultaneidade, idempotência e upload retomável” em fluxos e restrições implementáveis (DEVE/DEVERIA/PODE) e explica por que eles determinam diretamente a velocidade e a estabilidade do upload.
  • O Capítulo 3 explica “download paralelo, recuperação e remontagem” e como evitar a perda de velocidade por downloads redundantes em redes fracas.
  • O Capítulo 4 mantém apenas o modelo mínimo de armazenamento relevante para desempenho e capacidade de recuperação (camada de objetos versus camada de estado, semântica de TTL/exclusão).