Técnicas de upload paralelo: maximize a largura de banda

Os uploads paralelos dividem um ficheiro em chunks (tipicamente de 5 MB a 100 MB cada) e empurram-nos por múltiplas ligações TCP simultâneas, contornando o teto de débito que um único fluxo atinge em ligações de alta latência. O multipart upload do Amazon S3, os uploads retomáveis do Google Cloud Storage e o tus.io implementam tudo isto. Numa linha de 1 Gbps com 80 ms de latência para o servidor de destino, um único HTTP PUT satura tipicamente a 150 Mbps, enquanto 8 fluxos paralelos ultrapassam os 900 Mbps. O ganho é real e previsível quando se percebe porquê.

Por que um único fluxo não é suficiente

O controlo de congestão do TCP usa uma janela deslizante para decidir quanta informação sem confirmação manter em voo. Numa ligação rápida e de alta latência, o tamanho de janela predefinido (cerca de 16 MB no Linux 5.x, menos em kernels mais antigos) enche-se antes de os ACKs regressarem, e o emissor fica à espera. Este é o problema do "bandwidth-delay product", e é a razão pela qual uma única transferência FTP para um servidor em Singapura a partir de Paris fica limitada a cerca de 30 Mbps mesmo numa linha de gigabit.

Correr múltiplas ligações paralelas contorna o problema porque cada ligação tem a sua própria janela. Oito fluxos de 30 Mbps totalizam 240 Mbps, e isso é antes de considerar a seleção de edge de CDN, que muitas vezes encaminha ligações diferentes por diferentes pontos de entrada.

Chunks: que tamanho, quantos

O ponto ideal depende da latência e da perda de pacotes. Para transferências no mesmo continente com menos de 50 ms de RTT, chunks de 10 MB com 4 workers paralelos saturam a maioria das linhas domésticas. Para ligações transcontinentais ou móveis com perdas (mais de 100 ms de RTT, mais de 0,5% de perda de pacotes), reduza para chunks de 5 MB com 8 a 16 workers.

A API multipart do S3 requer um mínimo de 5 MB por parte (exceto a última), um máximo de 5 GB por parte e até 10.000 partes por upload. O Google Cloud Storage permite 32 partes por composição e suporta URIs de sessão retomáveis que persistem até uma semana. Os blobs de bloco do Azure Blob aceitam até 50.000 blocos de 4000 MiB cada.

Para transferências baseadas em browser, chunks acima de 100 MB começam a sobrecarregar a RAM em separadores já carregados, por isso a maioria das interfaces web fica entre 5 MB e 20 MB.

Como os serviços de transferência modernos o fazem

O carregador web do WeTransfer divide ficheiros em chunks de 6 MB e corre 3 a 5 pedidos XHR paralelos. O Smash fragmenta de forma mais agressiva, com chunks de 4 MB para até 8 workers. O SwissTransfer usa chunks de 50 MB com 4 fluxos paralelos, o que favorece o débito em linhas suíças de fibra mas tem pior desempenho em ligações instáveis porque um único chunk falhado significa retransmitir 50 MB. O Dropbox Transfer apoia-se na sua API de upload em chunks com chunks de 8 MB.

As diferenças aparecem em testes reais: um ficheiro de 5 GB numa ligação de upload de 500 Mbps para o WeTransfer termina em cerca de 95 segundos; o SwissTransfer com débito semelhante leva cerca de 105 segundos por causa da sobrecarga ocasional de retry de chunks.

Uploads retomáveis: o superpoder silencioso

Os uploads em chunks permitem retomar. Se o Wi-Fi cair no chunk 47 de 120, não recomeça do zero — retoma a partir do chunk 48. O protocolo tus.io (um padrão aberto agora na versão 2.0) formaliza isto com pedidos HEAD para consultar o offset do upload e pedidos PATCH para adicionar, usando os cabeçalhos Upload-Offset e Upload-Length.

A API de upload retomável do Google Drive usa URIs de sessão que persistem 7 dias. Pode fechar o portátil, reiniciar, reabrir o separador e retomar exatamente onde ficou. Esta é a diferença entre uma transferência de 10 GB utilizável e uma lotaria.

A encriptação no cliente muda os cálculos

Os serviços de transferência com encriptação ponta a ponta têm de encriptar cada chunk no cliente antes de o enviar. O AES-256-GCM a 500 MB/s num CPU moderno de portátil não é o gargalo, mas a ordem importa: encriptar chunk, enviar chunk, encriptar o próximo chunk. O pipeline com um pool de workers é fundamental aqui. Implementações ingénuas serializam encriptação e upload, cortando o débito efetivo a metade. Implementações corretas mantêm 2 a 4 workers de encriptação a alimentar 4 a 8 workers de upload através de uma fila limitada.

É por isso que o HexaTransfer corre a encriptação AES-256-GCM em Web Workers em paralelo com um pool de XHR, para que o teto de 10 GB seja realmente atingível no browser sem travar na criptografia.

Contrapressão e limites do lado do servidor

Mais paralelismo nem sempre é mais rápido. Se o serviço recetor limitar o débito por IP (comum com o CloudFront a 25.000 pedidos por segundo por distribuição), empurrar 32 chunks simultâneos pode desencadear respostas 503 Slow Down. O HTTP/2 ajuda porque multiplexa sobre uma única ligação TCP, mas muitos CDN ainda terminam o HTTP/2 na edge e expandem para HTTP/1.1 na origem, por isso o paralelismo efetivo depende da configuração da edge.

Teste antes de paralelizar em excesso. 8 workers é quase sempre seguro; 16 é o limite superior do que os object stores na cloud aceitam bem; 32 começa a produzir retentativas que custam mais do que poupam.

Limites do browser que deve conhecer

O Chrome e o Firefox limitam as ligações simultâneas por origem a 6 em HTTP/1.1 e efetivamente ilimitadas em HTTP/2. Se o serviço de transferência ainda usa HTTP/1.1 (raro, mas alguns gateways FTP-sobre-HTTP legados), o teto de paralelismo é 6 independentemente do número de workers que iniciar. Verifique no DevTools: a coluna "Waterfall" no painel Network mostra pedidos em fila a acumular.

O Safari no iOS 17 e posterior lida com 6 XHR paralelos sem problemas, mas começa a retirar separadores em segundo plano a cerca de 1,5 GB de pressão de RAM, o que é relevante para buffers de upload em chunks.

Quando os uploads paralelos não ajudam

Em ligações residenciais assimétricas (típico: 1 Gbps de download, 40 Mbps de upload), o upload é o gargalo, não a ingestão do servidor. Empurrar 8 fluxos paralelos de 5 MB por uma ligação de 40 Mbps não vai mais depressa do que 1 fluxo a 40 Mbps. O paralelismo ajuda quando o teto de único fluxo está abaixo da capacidade da linha, não quando já está a saturar a ligação.

A mesma história em dados móveis: se tiver uma barra de LTE, workers extra apenas produzem retransmissões.

O que procurar num serviço

Se estiver a escolher uma ferramenta de transferência para ficheiros grandes frequentes, verifique três coisas: suporta uploads em chunks retomáveis, quantos workers paralelos a interface web corre, e usa HTTP/2 ou HTTP/3 na edge. Serviços que cumprem os três moverão um ficheiro de 10 GB em minutos numa ligação decente.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.