Ir para o conteúdo
HexaTransfer
Voltar ao blog
Transferencia de arquivos

Dicas de otimização de largura de banda para transferências

Maximize a sua largura de banda para transferências. Aprenda configurações de router e ajustes de rede que melhoram dramaticamente a velocidade de upload.

Para aproveitar ao máximo a largura de banda de upload, faça quatro coisas: ligue por Ethernet gigabit em vez de Wi-Fi, ative QoS ou SQM no router para eliminar o bufferbloat, mude para IPv6 onde o ISP o suporta, e pause sincronizações em segundo plano como o Dropbox, iCloud e Google Drive durante a transferência. Numa ligação de 500 Mbps de upload que está a entregar 180 Mbps reais, estas quatro alterações juntas recuperam tipicamente 200 a 280 Mbps de débito utilizável e reduzem uma transferência de 10 GB de 45 minutos para menos de 15.

Ligar por cabo e esquecer o Wi-Fi para ficheiros grandes

O Wi-Fi 6 (802.11ax) num bom cliente 2x2 a 1,5 metros do ponto de acesso atinge cerca de 600 Mbps de débito real. O Wi-Fi 5 (802.11ac) fica mais perto de 300 Mbps. Na divisão seguinte com uma parede pelo meio, esses números caem 40 a 60 por cento. O Ethernet gigabit entrega 940 Mbps de forma consistente com menos de 1 ms de jitter.

Um adaptador USB-C para Ethernet gigabit a 15 € vai superar o Wi-Fi integrado da maioria dos portáteis em uploads acima de 2 GB. Se não puder passar cabo, pelo menos mude para a banda de 5 GHz e fique em linha de visão com o router. A banda de 2,4 GHz limita-se a 60–80 Mbps em condições reais e não tem negócio a suportar uma transferência de ficheiros.

QoS e SQM: a cura para o bufferbloat

O bufferbloat é a razão pela qual a chamada de Zoom fica instável no momento em que alguém em casa inicia um upload. Os buffers de router tradicionais colocam pacotes em fila durante segundos em ligações saturadas, destruindo a latência. Os algoritmos de Smart Queue Management (SQM) como CAKE e fq_codel mantêm as filas curtas mesmo sob carga, por isso um upload de 500 Mbps não adiciona 300 ms de latência a tudo o resto.

O OpenWrt, pfSense e a maioria dos routers modernos (Asus com firmware Merlin, Ubiquiti UniFi, eero Pro 6E) suportam SQM. Ative-o, defina o uplink para aproximadamente 95 por cento da velocidade provisionada e veja o teste de bufferbloat do DSLReports ou Waveform cair de uma nota F para A+.

Isso não adiciona largura de banda, mas remove a perda de débito de 40 a 60 por cento que ocorre quando o bufferbloat faz com que o emissor TCP recue repetidamente.

IPv6 é geralmente mais rápido

Nos ISP que suportam dual-stack, o IPv6 encaminha muitas vezes de forma mais direta para grandes destinos na cloud. A AWS, Google Cloud, Cloudflare e Azure correm todos IPv6 nativo, e um pacote sobre IPv6 tipicamente bypassa um ou dois saltos NAT em comparação com os caminhos CGNAT IPv4 comuns em redes móveis e algumas residenciais.

Verifique com ipv6-test.com ou test-ipv6.com. Se pontuar 10/10, já está a usar IPv6 onde disponível. Se não, ative-o no router (a maioria dos ISP empurra configurações via DHCPv6 ou PPPoE automaticamente). A diferença num upload transcontinental pode ser de 20 a 40 por cento.

Desligar tudo o que sincroniza em segundo plano

O Dropbox, Google Drive, OneDrive, iCloud Photos, Time Machine em rede e ferramentas de backup como o Backblaze consomem largura de banda de upload silenciosamente. O Monitor de Atividade do macOS (separador Rede, ordenar por "Bytes Enviados") e o Monitor de Recursos do Windows revelam os culpados.

Pause-os antes de uma grande transferência. O iCloud Photos em particular pode enviar gigabytes silenciosamente após importar uma sessão fotográfica. O limite predefinido do Backblaze é "automático", o que significa "tudo o que estiver disponível" numa ligação inactiva.

Uma chamada de vídeo Zoom em 1080p usa cerca de 3 Mbps upstream. Uma chamada Google Meet HD fica perto de 2,5 Mbps. Se alguém em casa estiver em videochamada, agende a transferência em torno disso ou aceite uma penalidade de 2 a 3 Mbps.

DNS e o tempo do primeiro byte

Um DNS mal configurado pode adicionar 50 a 200 ms de latência antes de uma ligação TCP sequer começar. Se ainda estiver a usar o resolver padrão do ISP, experimente o 1.1.1.1 da Cloudflare ou o 8.8.8.8 da Google. Use dig +stats servico-de-transferencia.com para comparar tempos de resposta. Para uploads em chunks que abrem muitas ligações, um resolver rápido acumula num débito total visivelmente mais rápido.

No macOS, mude o DNS em Definições do Sistema > Rede > Detalhes > DNS. No Windows 11, Definições > Rede e Internet > (o seu adaptador) > Editar atribuição de servidor DNS.

Ajuste de MTU em redes problemáticas

Se estiver numa VPN, numa ligação DSL PPPoE ou num uplink celular, o MTU pode ser menor do que os 1500 bytes predefinidos. Um MTU mal dimensionado causa fragmentação TCP, retransmissões e colapso do débito. Teste com ping -s 1472 -D google.com no macOS/Linux ou ping -f -l 1472 google.com no Windows. Se os pacotes não regressarem, reduza o MTU em incrementos de 10 bytes até regressarem, depois defina esse valor (mais 28 para sobrecarga ICMP) como MTU da interface.

Valores comuns que funcionam: 1500 na maioria das ligações de banda larga, 1492 em DSL PPPoE, 1428 em algumas VPNs WireGuard, 1400 na maioria dos operadores 5G.

Controlo de congestão: BBR versus Cubic

Em sistemas Linux que fazem upload para a cloud, mudar o controlo de congestão TCP de Cubic para BBR (Bottleneck Bandwidth and RTT) pode duplicar o débito em ligações de alta latência com ligeiras perdas. Ative com sysctl -w net.ipv4.tcp_congestion_control=bbr. O macOS e o Windows usam variantes de Cubic por predefinição e não expõem facilmente este parâmetro, mas os endpoints de transferência na cloud correm cada vez mais BBR do seu lado, o que ajuda mesmo que o seu lado não o faça.

Escolha do browser

Os browsers baseados em Chromium (Chrome, Edge, Brave, Arc) suportam HTTP/3 e QUIC por predefinição, o que supera o HTTP/2 sobre HTTPS em ligações com perdas em 15 a 25 por cento. O Firefox também suporta QUIC. O Safari 17+ suporta HTTP/3 mas usa HTTP/2 por predefinição para alguns serviços. Verifique pelo painel DevTools > Rede, coluna "Protocolo".

Se o endpoint de upload de um serviço servir sobre HTTP/3, deixar o browser escolhê-lo significa menos rondas de handshake por chunk, o que é relevante para uploads paralelos que abrem 4 a 8 fluxos simultâneos.

Escolher um serviço que respeita a ligação

Alguns serviços de transferência limitam os uploads independentemente da largura de banda que tem. Uma linha de 500 Mbps pode ainda arrastar através de uma ferramenta que limita o débito por transferência a 30 Mbps. O HexaTransfer transmite chunks em paralelo sobre HTTP/2 com encriptação AES-256-GCM em Web Workers, para que o upload sature o que a ligação consegue realmente entregar até ao teto de 10 GB por transferência.

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

Envie arquivos grandes com segurança e criptografia de ponta a ponta

Transfira arquivos de até 10 GB gratuitamente com criptografia de ponta a ponta. Sem necessidade de conta. Seus arquivos são criptografados no navegador antes do envio — ninguém mais pode lê-los.

Enviar um arquivo