Logo

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

A vantagem de velocidade do FileBolt vem de uma combinação de transporte, chunking paralelo, topologia global e agendamento de múltiplas fontes. Este capítulo explica, de forma auditável, quais mecanismos melhoram o rendimento de pico e quais melhoram a estabilidade e a capacidade de recuperação sob perda de pacotes ou comutação de rede.

1.1 Objetivos de projeto (visualização rápida)

  • Meta A: Aproximar-se do teto da largura de banda. Sob condições típicas, tente saturar a largura de banda disponível.
  • Meta B: rendimento estável. Mantenha a taxa de transferência utilizável sob perda, instabilidade, comutação de rede e alto RTT entre regiões, em vez de entrar em colapso repentinamente.
  • Meta C: Falhas recuperáveis. Quando ocorrerem erros, limite o custo à retransmissão de apenas uma pequena quantidade de dados – evite reiniciar a partir de 0%.

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

  • A entrada do cliente e da borda DEVE preferir HTTP/3 (QUIC). Quando o navegador, rede ou middleboxes não suportam isso, o sistema DEVE voltar automaticamente para HTTP/2/HTTP/1.1 para preservar a disponibilidade.
  • Sob perda de pacotes, o controle de transporte e congestionamento do QUIC pode muitas vezes reduzir o impacto do bloqueio head-of-line na taxa de transferência ponta a ponta, melhorando a estabilidade (os resultados dependem das condições da rede).
  • Caminhos de handshake 0-RTT/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 confiar neles como a única alavanca de desempenho.

Como verificar

  • No DevTools do seu navegador (por exemplo, Rede/Protocolo; a IU varia de acordo com o navegador), você pode observar se as solicitações usam h3 (HTTP/3) ou retornam para h2/h1.
  • Sob as mesmas condições de rede, comparar a configuração da conexão h3 versus não-h3 e a estabilidade da taxa de transferência (especialmente sob alto RTT/perda) pode ser visivelmente diferente.

1.3 Simultaneidade extrema: streaming em partes (Streaming em partes)

  • O sistema DEVE dividir logicamente arquivos grandes em vários pedaços; cada pedaço é a unidade mínima para upload/nova tentativa/recuperação (consulte o Capítulo 2).
  • O cliente DEVE transferir vários pedaços com simultaneidade limitada (por exemplo, vários pipelines paralelos) para se aproximar do teto da largura de banda e reduzir a sensibilidade ao jitter de conexão única.
  • O cliente DEVE suportar transferência recuperável: na recuperação, pule os pedaços concluídos e busque apenas os que faltam, evitando a retransmissão completa do arquivo (veja o Capítulo 2).
  • A simultaneidade e a fragmentação reduzem significativamente a espera causada pelo bloqueio de solicitação única (incluindo esperas de início de linha e de retransmissão), mas você NÃO DEVE alegar que “eliminou completamente” qualquer fenômeno de rede específico; o objetivo é reduzir o impacto e melhorar o rendimento estável.

Como verificar

  • No painel Rede você pode observar múltiplas solicitações paralelas de upload/download ao mesmo tempo (simultaneidade de blocos).
  • Depois de desconectar a rede ou atualizar a página, a retomada de uma transferência não deve ser reiniciada a partir de 0% (apenas os pedaços faltantes serão concluídos).

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

  • O sistema DEVE rotear as solicitações do usuário para um 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 para chunking paralelo: um RTT mais baixo normalmente aumenta o teto de rendimento efetivo de cada fluxo simultâneo, facilitando a saturação do link.
  • A cobertura da borda e as contagens de localização podem mudar à medida que a infraestrutura evolui; externamente, descreva isso como “cobertura de borda/entrada mais próxima” e trate os números como orientação em vez de garantias concretas.

Como verificar

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

1.5 Simultaneidade multifonte: agendamento inteligente (multifonte)

  • O sistema DEVE fazer escolhas dinâmicas com base nos sinais de qualidade do link (taxa de transferência, latência, taxa de erro, etc.), para que diferentes pedaços possam ser atribuídos a vários nós/posicionamentos melhores, reduzindo o impacto do congestionamento de ponto único na taxa de transferência geral.
  • No download, o cliente PODE buscar diferentes pedaços simultaneamente de múltiplas fontes para um efeito de aceleração de “tração de múltiplas fontes”; quando a fonte múltipla não está disponível, DEVE degradar automaticamente para download de fonte única para preservar a disponibilidade (ver Capítulo 3).
  • Se você comercializar isso como “IA”, é melhor enquadrá-lo como um sistema algorítmico para agendamento e tomada de decisões, e definir claramente entradas/saídas e comportamento de degradação para evitar afirmações vagas.

Como verificar

  • Durante o download você poderá observar solicitações simultâneas de diferentes fontes/conexões (dependendo da implementação e da visibilidade do navegador).
  • Sob congestionamento ou perda, a simultaneidade de múltiplas fontes geralmente proporciona uma taxa de transferência mais estável; quando as condições não forem atendidas, ele se degradará automaticamente, mas permanecerá utilizável.

1.6 Como isso é mapeado para os próximos capítulos

  • O Capítulo 2 expande “fragmentação, simultaneidade, idempotência e upload recuperável” em fluxos e restrições implementáveis (MUST/SHOULD/MAY) 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 perda de velocidade devido a downloads redundantes em redes fracas.
  • O Capítulo 4 mantém apenas o modelo de armazenamento mínimo relevante para desempenho e capacidade de recuperação (camadas de objeto versus estado, semântica de TTL/exclusão).