Logo

Capítulo 3 Caminho de download: download paralelo, recuperação e remontagem (chave)

Para os destinatários, “mais rápido” aparece principalmente de duas maneiras: buscando vários pedaços em paralelo para melhorar o rendimento e sendo capaz de se recuperar em redes fracas ou comutação de rede sem reiniciar. Do ponto de vista da engenharia, o caminho de download é simétrico ao caminho de upload.

3.1 Baixe objetos e manifesto

  • Antes de fazer o download, o cliente DEVE buscar o manifesto para saber a contagem total de blocos, a ordem e como localizar cada objeto.
  • O manifesto DEVE localizar cada pedaço de maneira exclusiva (por meio de regras de chave de objeto ou um índice equivalente).

3.2 Download paralelo

  • O cliente DEVE baixar vários pedaços simultaneamente para se aproximar do teto da largura de banda.
  • O cliente DEVE usar simultaneidade limitada e reduzi-la quando as taxas de erro aumentarem.
  • O benefício da simultaneidade costuma ser maior com RTT alto entre regiões, porque uma única conexão é mais facilmente limitada por RTT e jitter.

3.3 Download retomável

  • O cliente DEVE ser capaz de registrar o conjunto de pedaços concluídos (por exemplo, conjunto de bitmap/índice).
  • Após uma interrupção, o cliente DEVE buscar apenas os pedaços que faltam, e não baixar novamente o arquivo inteiro.
  • Se o servidor impor limites de contagem de downloads, o cliente DEVE minimizar downloads redundantes durante a recuperação para evitar desperdício de contagens.

3.4 Remontagem

  • O cliente DEVE remontar o arquivo de saída na ordem chunkIndex.
  • O cliente DEVE usar gravações de streaming/remontagem progressiva para reduzir picos de memória (especialmente para arquivos muito grandes).
  • Se vários arquivos forem empacotados, o cliente PODE gerar saída por arquivo ou usar um formato de contêiner (dependendo do design do produto).

3.5 Verificações de integridade (breve)

  • Após o download, o cliente DEVE verificar os pedaços (por exemplo, consistência de hash/comprimento).
  • Se a verificação falhar, DEVE falhar ao fechar e tentar novamente o bloco correspondente.
  • Para conhecer os limites das falhas de criptografia/autenticação, consulte as seções relevantes no whitepaper de segurança e privacidade.