Capítulo 2 Caminho de upload: divisão em chunks, simultaneidade e retomada (principal)
Do lado do upload, o objetivo é chegar o mais perto possível de “saturar a largura de banda” em redes instáveis, limitando ao mínimo o custo das falhas (retransmitir apenas os chunks que falharam). Juntos, esses dois objetivos explicam em grande parte por que os uploads parecem mais rápidos.
2.1 Divisão em chunks
- O cliente DEVE dividir o arquivo em vários chunks; um chunk é a unidade mínima de upload/nova tentativa.
- Os chunks DEVERIAM ter tamanho fixo (ou seguir uma política de tamanho por arquivo) para simplificar o agendamento da simultaneidade e a representação de estado.
- Benefício imediato: qualquer falha afeta apenas um chunk, não o arquivo inteiro.
2.2 Upload paralelo
O objetivo da simultaneidade não é ter “mais threads”, mas evitar três limitações práticas de uma única conexão em redes reais:
- Início lento (slow start) e crescimento da janela: uma única conexão acelera devagar, especialmente com RTT alto entre regiões.
- Jitter do link: o jitter em uma conexão pode reduzir a velocidade geral; a simultaneidade suaviza o efeito.
- Traffic shaping por fluxo: algumas redes limitam um único fluxo; vários fluxos podem chegar mais perto do teto de largura de banda (dentro das restrições de conformidade).
- O cliente DEVERIA 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: aumentá-la quando a taxa de transferência sobe e reduzi-la quando a taxa de erro sobe.
2.3 Idempotência e nova tentativa
- Uploads repetidos do mesmo chunk DEVEM ser idempotentes: envios duplicados não devem corromper um estado já concluído.
- O servidor DEVERIA garantir a unicidade com (transferId, fileId, chunkIndex) ou uma restrição equivalente.
- O cliente DEVE implementar novas tentativas com backoff exponencial; diante de falhas, DEVERIA repetir apenas os chunks que falharam.
2.4 Upload retomável
- O servidor DEVE ser capaz de responder “quais chunks já foram enviados”, para que o cliente possa pular os já concluídos.
- O conjunto de chunks enviados DEVERIA ser representado como um bitmap / conjunto de intervalos, para evitar que o tamanho do estado cresça linearmente com o número de chunks.
- Benefício de velocidade: após interrupções de rede, falhas do navegador ou troca de rede, a retomada não recomeça do 0%.
2.5 “Compartilhar durante o upload” (opcional)
- O sistema PODE gerar um identificador de transferência utilizável e um link de compartilhamento enquanto o upload ainda está em andamento, para acelerar os fluxos 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 é exibido.