Consigli per ottimizzare la banda per trasferimenti più veloci
Massimizza la banda disponibile per i trasferimenti. Impara impostazioni router e modifiche di rete che migliorano drasticamente la velocità.
Per sfruttare al meglio la tua banda di upload, fai quattro cose: collega via Ethernet gigabit invece del Wi-Fi, attiva QoS o SQM sul router per eliminare il bufferbloat, passa a IPv6 dove il tuo ISP lo supporta, e metti in pausa le sincronizzazioni in background come Dropbox, iCloud e Google Drive durante il trasferimento. Su un upload da 500 Mbps che in realtà consegna 180 Mbps durante i trasferimenti reali, questi quattro cambiamenti insieme recuperano tipicamente 200-280 Mbps di throughput utilizzabile e riducono un trasferimento da 10 GB da 45 minuti a meno di 15.
Cablato e dimentica il Wi-Fi per i file grandi
Il Wi-Fi 6 (802.11ax) su un buon client 2x2 a 1,5 metri dal punto di accesso tocca circa 600 Mbps di throughput reale. Il Wi-Fi 5 (802.11ac) si attesta più vicino ai 300 Mbps. Nella stanza accanto con un muro in mezzo, quei numeri calano del 40-60%. L'Ethernet gigabit fornisce 940 Mbps in modo consistente con meno di 1 ms di jitter.
Un adattatore USB-C a Gigabit Ethernet da 15 euro supera il Wi-Fi integrato della maggior parte dei laptop per upload oltre i 2 GB. Se non riesci a far passare un cavo, almeno passa alla banda 5 GHz e mettiti in linea di vista con il router. Il 2,4 GHz si ferma a 60-80 Mbps in condizioni reali e non ha nulla a che fare con un trasferimento di file.
QoS e SQM: la cura per il bufferbloat
Il bufferbloat è il motivo per cui la tua chiamata Zoom va male nel momento in cui qualcuno in casa avvia un upload. I buffer tradizionali dei router mettono in coda i pacchetti per secondi su link saturi, distruggendo la latenza. Gli algoritmi Smart Queue Management (SQM) come CAKE e fq_codel mantengono le code brevi anche sotto carico, così un upload da 500 Mbps non aggiunge 300 ms di latenza a tutto il resto.
OpenWrt, pfSense e la maggior parte dei router moderni (Asus con firmware Merlin, Ubiquiti UniFi, eero Pro 6E) supportano SQM. Abilitalo, imposta il tuo uplink a circa il 95% della tua velocità provisionata, e guarda il test bufferbloat di DSLReports o Waveform passare da un voto F a A+.
Questo non aggiunge banda, ma rimuove la perdita di throughput del 40-60% che si attiva quando il bufferbloat fa arretrare ripetutamente il tuo mittente TCP.
IPv6 è di solito più veloce
Sugli ISP che supportano dual-stack, IPv6 spesso instrada in modo più diretto verso le principali destinazioni cloud. AWS, Google Cloud, Cloudflare e Azure girano tutti su IPv6 nativo, e un pacchetto via IPv6 tipicamente bypassa uno o due hop NAT rispetto ai percorsi IPv4 CGNAT comuni su mobile e alcune reti residenziali.
Controlla con ipv6-test.com o test-ipv6.com. Se otieni 10/10, stai già usando IPv6 dove disponibile. In caso contrario, abilitalo nel router (la maggior parte degli ISP invia le configurazioni automaticamente via DHCPv6 o PPPoE). La differenza su un upload transcontinentale può essere del 20-40%.
Spegni tutto ciò che si sincronizza in background
Dropbox, Google Drive, OneDrive, iCloud Photos, Time Machine su rete e strumenti di backup come Backblaze consumano tutti banda di upload in silenzio. Activity Monitor di macOS (tab Rete, ordinato per "Byte inviati") e Resource Monitor di Windows rivelano i colpevoli.
Mettili in pausa prima di un trasferimento grande. iCloud Photos in particolare può inviare gigabyte silenziosamente dopo l'importazione di una sessione fotografica. La limitazione predefinita di Backblaze è "automatica", il che significa "prendi tutto ciò che è disponibile" su una connessione inattiva.
Una chiamata Zoom in 1080p usa circa 3 Mbps upstream. Una chiamata Google Meet HD si aggira sui 2,5 Mbps. Se qualcuno in casa è su una videochiamata, pianifica il trasferimento intorno a essa o accetta una perdita di 2-3 Mbps.
DNS e il tempo al primo byte
Un DNS mal configurato può aggiungere 50-200 ms di latenza prima che una connessione TCP inizi persino. Se stai ancora usando il resolver predefinito del tuo ISP, prova il 1.1.1.1 di Cloudflare o il 8.8.8.8 di Google. Usa dig +stats servizio-trasferimento.com per confrontare i tempi di risposta. Per gli upload a chunk che aprono molte connessioni, un resolver veloce si cumula in un throughput complessivo notevolmente più veloce.
Su macOS, cambia DNS in Impostazioni di Sistema > Rete > Dettagli > DNS. Su Windows 11, Impostazioni > Rete e Internet > (il tuo adattatore) > Modifica assegnazione server DNS.
Regolazione MTU su reti particolari
Se sei su una VPN, una connessione DSL PPPoE, o un uplink cellulare, il tuo MTU potrebbe essere inferiore ai 1500 byte predefiniti. Un MTU mal dimensionato causa frammentazione TCP, ritrasmissioni e collasso del throughput. Testa con ping -s 1472 -D google.com su macOS/Linux o ping -f -l 1472 google.com su Windows. Se i pacchetti non tornano, abbassa l'MTU di 10 byte alla volta finché non tornano, poi imposta quel valore (più 28 per l'overhead ICMP) come MTU della tua interfaccia.
Valori funzionali comuni: 1500 sulla maggior parte della banda larga, 1492 su PPPoE DSL, 1428 su alcuni VPN WireGuard, 1400 sulla maggior parte dei carrier 5G.
Controllo della congestione: BBR vs Cubic
Sui sistemi Linux che caricano verso il cloud, passare il controllo della congestione TCP da Cubic a BBR (Bottleneck Bandwidth and RTT) può raddoppiare il throughput su link ad alta latenza e leggermente con perdite. Abilitalo con sysctl -w net.ipv4.tcp_congestion_control=bbr. macOS e Windows usano varianti di Cubic di default e non espongono facilmente questa impostazione, ma gli endpoint di trasferimento cloud sempre più spesso girano BBR dalla loro parte, il che aiuta anche se il tuo lato non lo fa.
Questo è uno dei motivi per cui i servizi che girano su Google Cloud spesso sembrano più veloci rispetto a servizi identici su host legacy.
La scelta del browser conta
I browser basati su Chromium (Chrome, Edge, Brave, Arc) supportano HTTP/3 e QUIC di default, che supera HTTP/2 su HTTPS su link con perdite del 15-25%. Firefox include anche QUIC. Safari 17+ supporta HTTP/3 ma usa HTTP/2 come default per alcuni servizi. Controlla tramite il pannello DevTools, colonna "Protocol".
Se l'endpoint di upload di un servizio di trasferimento serve su HTTP/3, lasciare che il browser lo selezioni significa meno round-trip di handshake per chunk, il che conta per gli upload paralleli che aprono 4-8 stream simultanei.
Scegli un servizio che rispetti il pipe
Alcuni servizi di trasferimento limitano gli upload indipendentemente da quanta banda hai. Una linea da 500 Mbps può comunque strisciare attraverso uno strumento che limita il throughput per trasferimento a 30 Mbps. HexaTransfer trasmette i chunk in parallelo su HTTP/2 con cifratura AES-256-GCM in Web Worker, così il tuo upload satura tutto ciò che la tua connessione può effettivamente consegnare fino al tetto di 10 GB per trasferimento.
Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.
Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end
Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.
Invia un file