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:

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.
Dividir: O cliente divide o ficheiro em partes (tipicamente entre 5 MB e 64 MB cada).
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.
Confirmar: O servidor grava a parte no armazenamento e confirma o novo offset.
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.
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.