Arquitetura de Upload em Chunks: Guia de Design

Uma arquitectura de upload em chunks divide um ficheiro em peças de tamanho fixo ou variável e envia-as independentemente — de modo a que uma falha de rede não force um reinício de 10 GB desde o início. Os dois padrões abertos dominantes são o AWS S3 Multipart Upload (mínimo de 5 MB por parte, máximo de 10.000 partes) e o protocolo retomável tus.io (draft RFC, amplamente implementado). Feito correctamente, os uploads em chunks entregam débito 5 a 10x superior em ligações de alta latência, toleram desconexões breves, e permitem desencriptação paralela no lado receptor. O RGPD e as directrizes da CNCS sobre continuidade de negócio reforçam igualmente a importância de uploads retomáveis: um upload interrompido que não consegue retomar representa uma falha de disponibilidade de dados.

Por Que os Uploads Monolíticos Falham à Escala

Um único HTTP PUT de um ficheiro de 5 GB tem meia dúzia de formas de falhar. As janelas de congestão TCP demoram muito tempo a aumentar, limitando o débito muito abaixo da capacidade do link em caminhos de alta latência. Os browsers limitam as ligações concorrentes por origem a 6, deixando a maior parte da largura de banda inactiva. Os timeouts de pedido do lado do servidor (predefinição nginx 60 segundos, CloudFront 30 segundos para não-streaming) encerram uploads longos. As redes móveis a alternar entre torres interrompem a ligação a cada poucos minutos. E um único flip de bit força toda a transferência a reiniciar. Os uploads em chunks resolvem tudo isto tornando a unidade de trabalho pequena, independentemente retomável e amigável a paralelo.

Escolher um Tamanho de Chunk

O tamanho do chunk é uma troca. Chunks mais pequenos recuperam mais depressa de falhas e fornecem granularidade de progresso mais fina mas acrescentam mais overhead HTTP. Chunks maiores amortizam custos de handshake e TLS mas desperdiçam largura de banda quando um chunk falha e tem de ser retransmitido. Intervalos típicos: 1 MB a 5 MB para uploads móveis com redes com perdas, 5 MB a 16 MB para uploads web desktop, 16 MB a 64 MB para transferências servidor-a-servidor em links fiáveis, e 100 MB ou mais para S3 Multipart onde o tecto de 10.000 partes força chunks maiores em ficheiros de 1 TB. Alguns sistemas adaptam dinamicamente, começando pequeno e escalando à medida que a ligação prova ser fiável.

Chunking de Tamanho Fixo vs. Definido por Conteúdo

O chunking de tamanho fixo (por exemplo, 8 MB cada) é trivial de implementar, amigável a paralelo e suporta offsets de retoma exactos. O chunking definido por conteúdo, usado no rsync e restic, escolhe limites com base num hash de janela deslizante como a impressão digital Rabin para que inserções no meio de um ficheiro não desloquem todos os limites de chunk seguintes. O CDC é fantástico para deduplicação em ferramentas de backup mas acrescenta complexidade e custo de CPU não recompensado para transferência pura de ficheiros. Para arquitecturas de upload, o tamanho fixo vence em simplicidade e mapeia de forma limpa para partes S3 multipart ou offsets tus.io.

Protocolos de Upload Retomável

O protocolo tus.io, implementado em tusd (Go), tus-js-client, Uppy e muitos frameworks de servidor, usa HTTP PATCH com um cabeçalho Upload-Offset para acrescentar chunks. Um pedido HEAD devolve o offset actual no servidor, para que o cliente saiba onde retomar após uma interrupção de rede. O S3 Multipart Upload usa um modelo diferente: iniciar o upload para obter um UploadId, carregar cada parte (indexada a partir de 1), depois enviar um pedido CompleteMultipartUpload com a lista de ETags. Os clientes podem consultar ListParts para ver o que foi carregado. Ambos os protocolos preservam o estado entre reinícios do cliente e toleram quedas de ligação graciosamente.

Concorrência de Upload Paralelo

Carregar chunks em paralelo aumenta drasticamente o débito em links de alta latência. HTTP/1.1 limita-se a 6 ligações concorrentes por origem em browsers; HTTP/2 multiplexa muitas streams sobre uma única ligação mas ainda sujeito a janelas de controlo de fluxo. Um scheduler de upload típico enfileira chunks e despacha 4 a 8 em paralelo, com backpressure quando o servidor sinaliza 429 ou 503. Demasiado paralelismo desencadeia shaping do ISP e limites de ligação de middlebox; demasiado pouco deixa largura de banda por usar. Empiricamente, 4 streams paralelas em banda larga doméstica e 8 a 16 em fibra gigabit atingem o ponto óptimo para a maioria das cargas de trabalho.

Estado do Cliente e Metadados de Retoma

Os uploads retomáveis exigem que o cliente se lembre de estado suficiente para retomar após um crash do browser ou o fecho do portátil. O IndexedDB, parte da norma Web Storage, armazena manifestos de upload com o hash do ficheiro, o número de chunks, e quais os chunks que tiveram sucesso. Use o hash SHA-256 do ficheiro como chave do manifesto para que re-adicionar o mesmo ficheiro retome donde parou. Limpe manifestos antigos com mais de 7 dias para evitar inchaço. No móvel, o WKWebView (iOS) e o Chrome Custom Tabs (Android) podem despejar o IndexedDB sob pressão de memória, por isso persista o estado crítico para armazenamento nativo se possível.

Tratamento de Chunks no Lado do Servidor

O servidor precisa de reassemblar chunks num ficheiro completo ou, com S3 Multipart, delegar a reassemblagem ao S3. Uma arquitectura mínima: aceitar cada PATCH de chunk, escrever para um blob temporário indexado por ID de upload e índice de chunk, registar o offset num armazenamento de metadados como Redis ou PostgreSQL, e na CompletePart assemblar ou marcar como completo. Use armazenamento de objectos (S3, Cloudflare R2, Backblaze B2) para os blobs de chunk em vez de disco local, uma vez que os backends com balanceamento de carga não conseguem facilmente partilhar estado local. Recolha uploads abandonados após 24 a 72 horas para recuperar armazenamento.

Verificação de Integridade por Chunk e Ponta-a-Ponta

Verifique cada chunk com um hash no upload. O ETag do S3 Multipart é um hash MD5 por parte (ou um hash composto para o objecto completo). Para integridade mais forte, calcule SHA-256 por chunk do lado do cliente e envie-o num cabeçalho; o servidor guarda-o ao lado do chunk e pode verificar na releitura. Depois de todos os chunks carregarem, calcule uma raiz de árvore Merkle ou um hash de streaming do ficheiro reassemblado e devolva-o ao cliente. O cliente compara com o seu próprio hash do ficheiro original. Qualquer discrepância desencadeia um re-carregamento dos chunks afectados.

Interacção da Encriptação com o Chunking

A encriptação ponta-a-ponto complica ligeiramente o chunking. Cada chunk precisa do seu próprio nonce para evitar reutilização de IV em AES-GCM, e os limites de chunk têm de fazer parte do esquema de autenticação. Uma abordagem típica: derivar uma chave por chunk via HKDF-SHA256 a partir de uma chave de encriptação de ficheiro raiz, usando o índice do chunk como informação de contexto, depois encriptar cada chunk com AES-256-GCM e um nonce zero ou incrementado. Inclua o índice do chunk e o número total de chunks no AAD para que atacantes não consigam emparelhar ou reordenar chunks. Na desencriptação, verifique que todos os chunks estão presentes e em ordem antes de libertar o texto simples.

Observabilidade para Sistemas Baseados em Chunks

Instrumente cada chunk. Métricas a acompanhar: chunks carregados por segundo, latência de upload de chunk p50/p95/p99, taxa de retry por chunk, e taxa de upload abandonado. Dashboards no Grafana ou Datadog revelam regressões rapidamente. Traces distribuídas via OpenTelemetry ligam uma sessão de cliente ao tratamento do chunk no lado do servidor. Registe eventos estruturados em JSON para que sejam pesquisáveis no Loki, Elasticsearch ou Splunk. O HexaTransfer usa encriptação em chunks do lado do cliente com AES-256-GCM e uploads retomáveis para gerir ficheiros de 10 GB de forma fiável sobre ligações instáveis.

Experimente em https://hexatransfer.com — gratuito, sem conta, máximo de 10 GB.