Retomar transferências interrompidas: nunca recomeçar do zero

As transferências retomáveis dividem um ficheiro em partes e registam quais foram recebidas com sucesso; quando a ligação cai, o cliente retoma a partir da próxima parte por enviar em vez de recomeçar do byte zero. O padrão web para isto é o tus.io (protocolo aberto de upload retomável), implementado pelo SwissTransfer, HexaTransfer, Vimeo, Cloudinary e muitos serviços modernos de transferência. Para transferências, os pedidos HTTP Range (RFC 7233) permitem que browsers e ferramentas como curl ou aria2 retomem transferências interrompidas. Sem retomada, um upload de 9,8 GB que falha a 9,5 GB significa recomeçar tudo — com retomada, perde-se no máximo 50 MB.

O problema dos uploads não retomáveis

Um upload simples envia o ficheiro inteiro numa única requisição HTTP POST. Se algo interrompe a ligação — queda de Wi-Fi, timeout da VPN, suspensão do portátil, falha do operador de internet — a ligação TCP fecha e o servidor descarta os dados parciais recebidos. O cliente recomeça do byte zero.

Para um upload de 5 GB a 50 Mbps, são 13 minutos de trabalho desperdiçados. Para 50 GB, mais de duas horas. A taxa de falha de uploads não retomáveis em ligações móveis é brutal — um upload de 30 minutos numa ligação 4G raramente consegue concluir à primeira tentativa.

Como funcionam os protocolos retomáveis

Os uploads retomáveis modernos funcionam de forma aproximadamente assim:

1. Criar: O cliente envia um POST ao servidor com o tamanho total e metadados do ficheiro. O servidor devolve um URL único para este upload específico e reserva espaço de armazenamento.
2. Dividir: O cliente divide o ficheiro em partes (tipicamente entre 5 MB e 64 MB cada).
3. Enviar: O cliente envia cada parte como um pedido PATCH com um cabeçalho Content-Range ou Upload-Offset a indicar a posição da parte.
4. Confirmar: O servidor grava a parte no armazenamento e confirma o novo offset.
5. Retomar: Se a ligação cair, o cliente envia um pedido HEAD ao URL do upload. O servidor responde com o offset atual (quantos bytes tem). O cliente retoma a partir desse offset.
6. Concluir: Quando a última parte é confirmada, o upload está completo.

Este modelo está definido pela especificação tus.io (versão 1.0.0 em uso generalizado). Outras variantes incluem o S3 Multipart Upload (para uploads diretos ao S3) e os Uploads Retomáveis do Google Cloud Storage.

Tus.io: o padrão aberto

O Tus ("transloadit upload server") é um protocolo livre e aberto mantido pela Transloadit. A especificação está em tus.io e é implementada por:

• Bibliotecas cliente: tus-js-client (browser + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
• Implementações servidor: tusd (servidor de referência em Go), tus-node-server e muitas integrações de frameworks
• Serviços comerciais: SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, servidores companion do Uppy

O protocolo é deliberadamente minimalista: quatro verbos HTTP (POST, HEAD, PATCH, OPTIONS) e um conjunto de cabeçalhos (Upload-Offset, Upload-Length, Tus-Resumable). Isto mantém as implementações simples e interoperáveis.

Decisões sobre o tamanho das partes

O tamanho das partes equilibra a granularidade de retoma com o overhead HTTP.

Tamanho da parte	Custo de recuperação em caso de falha	Overhead
1 MB	Perda ≤ 1 MB	Elevado (muitos pedidos)
5 MB	Perda ≤ 5 MB	Moderado
16 MB	Perda ≤ 16 MB	Baixo
64 MB	Perda ≤ 64 MB	Mínimo
256 MB	Perda ≤ 256 MB	Overhead negligível, doloroso em caso de falha

Em ligações estáveis, partes de 32-64 MB maximizam o débito. Em redes móveis ou Wi-Fi instável, partes de 2-5 MB recuperam mais rapidamente de cada falha. Os serviços geralmente escolhem um valor padrão entre 5-10 MB como compromisso.

O que realmente interrompe as transferências

Compreender os modos de falha ajuda a avaliar se a implementação de retoma de um serviço é robusta:

• Quedas de Wi-Fi: mudança de rede, perda de sinal, reinício do router. Muito comum.
• Suspensão do portátil: fechar o ecrã no macOS/Windows. O sistema operativo suspende a rede; ao acordar, as ligações frequentemente precisam ser restabelecidas.
• Suspensão de separadores: os browsers modernos suspendem separadores em segundo plano para poupar memória. Uploads num separador suspenso podem parar.
• Problemas do operador/backhaul: mudanças momentâneas de encaminhamento, novo handshake TLS necessário.
• Reconexão da VPN: os clientes VPN renegociam periodicamente; a ligação TCP morre.
• Reinícios do servidor: o serviço de transferência implementa uma nova versão; pedidos em curso falham.
• Alterações de política de origem cruzada: firewalls corporativos que inspecionam tráfego por vezes terminam ligações de longa duração.

Uma implementação retomável robusta trata todos estes casos com o mesmo mecanismo: reconectar, HEAD para verificar o offset, retomar a partir daí.

Retoma em transferências

Os pedidos HTTP Range (RFC 7233) suportam transferências retomáveis. Um servidor que anuncia Accept-Ranges: bytes nos cabeçalhos de resposta suporta pedidos de intervalo. Os clientes podem então enviar Range: bytes=1000000- para obter apenas os bytes a partir do offset 1.000.000.

Os browsers usam isto automaticamente quando se clica em "Retomar" no gestor de transferências. Chrome, Firefox e Safari suportam retoma de transferências a partir de servidores compatíveis. A maioria das CDN (Cloudflare, Fastly, CloudFront) suporta intervalos.

As ferramentas de linha de comando expõem mais controlo:

• curl -C - -O url retoma uma transferência de onde parou.
• wget -c url faz o mesmo.
• aria2c -c -s 16 url transfere com 16 fluxos paralelos de pedidos de intervalo para maior velocidade.

Serviços que suportam retoma

Os serviços de transferência modernos tratam maioritariamente da retoma de uploads:

Serviço	Retoma de upload	Retoma de transferência
SwissTransfer	Sim (baseado em tus)	Sim (intervalos HTTP)
HexaTransfer	Sim (partes + compatível com tus)	Sim
WeTransfer	Sim (uploads em partes)	Sim
Dropbox Transfer	Sim	Sim
Google Drive	Sim (API de upload retomável)	Sim
OneDrive	Sim	Sim
Box	Sim	Sim

Os planos gratuitos por vezes desativam a retoma para incentivar actualizações pagas, mas isto é raro em 2026. Os serviços mais antigos sem suporte de retoma estão a desaparecer das listas de recomendações porque os utilizadores se cansam das falhas.

O que não retoma automaticamente

Os uploads HTTP POST simples em aplicações rudimentares não retomam. As transferências FTP variam historicamente — alguns clientes e servidores suportam comandos REST (reinício), outros não. Os anexos de correio electrónico não podem ser retomados — se um envio do Gmail falhar a 90%, é recomeçar do início.

As transferências por torrent retomam inerentemente porque o protocolo torrent controla quais partes foram verificadas. Esta é parte da razão pela qual o BitTorrent continuou útil para distribuições muito grandes, mesmo quando a web avançou noutras métricas.

Retoma com encriptação ponta a ponta

Os uploads retomáveis combinados com encriptação no lado do cliente requerem divisão em partes cuidadosa. O ficheiro é dividido em partes, cada parte é encriptada com AES-256-GCM usando um IV (vetor de inicialização) único, e depois enviada. Na retoma, o cliente deve saber quais partes foram concluídas e continuar a partir da seguinte.

Como cada parte é encriptada e autenticada de forma independente (modo AEAD do GCM), os uploads parciais não podem ser adulterados. Um servidor malicioso que insira dados inválidos no offset 5 GB falharia na autenticação quando o destinatário desencriptar — a discordância da tag GCM seria detetada.

Implementações como o HexaTransfer usam IVs por parte derivados deterministicamente de uma chave mestra e do índice da parte, pelo que a retoma não requer armazenar IVs separadamente. O lado da desencriptação reconstrói-os a partir da mesma derivação.

Boas práticas do lado do cliente

Para maximizar o sucesso da retoma:

• Manter o separador activo durante o upload. A suspensão de separadores do browser termina uploads em curso. Um aviso "não feche este separador" é padrão nas interfaces dos serviços de transferência.
• Ligar à rede por cabo quando possível. As quedas de Wi-Fi causam a maioria das falhas.
• Desativar a suspensão por poupança de energia durante uploads longos. macOS: caffeinate -i. Windows: utilitário Awake do Powertoys ou alterações no plano de energia.
• Não mudar de rede Wi-Fi a meio de um upload. A ligação TCP muda de IP e morre.
• Deixar o upload terminar antes de fechar o portátil. O macOS moderno por vezes preserva uploads através de breves suspensões, mas não é fiável.

Verificar no lado do servidor

Alguns serviços mostram barras de progresso que não refletem efetivamente o estado do servidor. Após um upload que sobreviveu a uma ou duas interrupções, atualize a página e verifique se a ligação funciona — abra-a em modo de navegação privada e transfira uma pequena parte. Se a retoma funcionou, o ficheiro completo será transferido corretamente.

Para cenários que exigem máxima certeza, calcule um hash SHA-256 no cliente, faça o upload e verifique se o hash do ficheiro transferido corresponde. Uma verificação de integridade criptográfica demora 10 segundos de CPU por gigabyte e garante certeza absoluta.

Conclusão

A transferência retomável é uma funcionalidade essencial em 2026 — qualquer serviço sem ela é um motivo imediato para exclusão em ficheiros com mais de algumas centenas de megabytes. Procure conformidade com tus.io ou comportamento equivalente de upload em partes. Certifique-se de que o serviço escolhido trata interrupções graciosamente; teste com uma queda de rede deliberada num ficheiro pequeno antes de comprometer-se com uma transferência grande.

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