Capítulo 2 Caminho de upload: fragmentação, simultaneidade e currículo (chave)
Do lado do upload, o objetivo é chegar o mais próximo possível da “saturação da largura de banda” em redes flutuantes, ao mesmo tempo em que limita o custo das falhas ao mínimo (retransmitir apenas os pedaços com falha). Juntos, esses dois objetivos explicam em grande parte por que os uploads parecem mais rápidos.
2.1 Segmentação
- O cliente DEVE dividir o arquivo em vários pedaços; um pedaço é a unidade mínima para upload/nova tentativa.
- Os pedaços DEVEM usar um tamanho fixo (ou uma política de tamanho por arquivo) para simplificar o agendamento de simultaneidade e a representação de estado.
- Benefício imediato: qualquer falha afeta apenas uma parte, não o arquivo inteiro.
2.2 Carregamento paralelo
O objetivo da simultaneidade não é “mais threads”, mas sim evitar três limitações práticas de uma única conexão em redes reais:
- Início lento e crescimento da janela: uma única conexão aumenta lentamente, especialmente com alto RTT entre regiões.
- Tremor de links: a instabilidade em uma conexão pode diminuir a velocidade geral; a simultaneidade suaviza o efeito.
- Modelagem por fluxo: algumas redes limitam um único fluxo; múltiplos fluxos podem aproximar-se do teto da largura de banda (dentro das restrições de conformidade).
- O cliente DEVE usar simultaneidade limitada (por exemplo, 4–12) e reduzi-la em dispositivos mais fracos para evitar picos de memória.
- O cliente PODE adaptar a simultaneidade: aumentar quando a taxa de transferência aumentar; diminuir quando a taxa de erro aumentar.
2.3 Idempotência e nova tentativa
- Uploads repetidos do mesmo pedaço DEVEM ser idempotentes: envios duplicados não devem corromper um estado já concluído.
- O servidor DEVE impor exclusividade com (transferId, fileId, chunkIndex) ou uma restrição equivalente.
- O cliente DEVE implementar novas tentativas de espera exponencial; as falhas DEVEM tentar novamente apenas os pedaços com falha.
2.4 Upload recuperável
- O servidor DEVE ser capaz de responder “quais pedaços já foram carregados”, para que o cliente possa pular os concluídos.
- O conjunto carregado DEVE ser representado como um bitmap/conjunto de intervalo para evitar que o tamanho do estado cresça linearmente com a contagem de blocos.
- Benefício de velocidade: após interrupções de rede, travamentos do navegador ou troca de rede, a retomada não reinicia a partir de 0%.
2.5 “Compartilhar durante o upload” (opcional)
- O sistema PODE gerar um identificador de transferência utilizável e compartilhar um link enquanto o upload ainda está em andamento para acelerar os fluxos de trabalho de entrega.
- Se o compartilhamento for permitido antes da conclusão do upload, DEVE ficar explícito o que os destinatários veem: o conteúdo incompleto ainda não pode ser baixado ou apenas o progresso é mostrado.