Consejos de optimización de ancho de banda para transferencias

Para aprovechar al máximo tu ancho de banda de subida, haz cuatro cosas: conecta por Ethernet gigabit en lugar de Wi-Fi, activa QoS o SQM en tu router para eliminar el bufferbloat, cambia tu conexión a IPv6 donde tu ISP lo soporte, y pausa las sincronizaciones en segundo plano como Dropbox, iCloud y Google Drive durante la transferencia. En una subida de 500 Mbps que está entregando realmente 180 Mbps durante las transferencias, estos cuatro cambios juntos suelen recuperar 200-280 Mbps de rendimiento útil y reducen una transferencia de 10 GB de 45 minutos a menos de 15.

Conecta por cable y olvida el Wi-Fi para archivos grandes

El Wi-Fi 6 (802.11ax) en un buen cliente 2x2 a 1,5 metros del punto de acceso alcanza un rendimiento máximo real de unos 600 Mbps. Wi-Fi 5 (802.11ac) se acerca más a 300 Mbps. En la habitación contigua con una pared de por medio, esos números caen entre un 40 y un 60%. Ethernet gigabit entrega 940 Mbps de forma consistente con menos de 1 ms de jitter.

Un adaptador USB-C a Ethernet gigabit de unos 15 € supera la Wi-Fi integrada de la mayoría de los portátiles en subidas de más de 2 GB. Si no puedes tender un cable, al menos cambia a la banda de 5 GHz y colócate en línea de visión directa con el router. 2.4 GHz alcanza como máximo 60-80 Mbps en condiciones reales y no tiene ningún sentido para transferir archivos.

QoS y SQM: cura para el bufferbloat

El bufferbloat es la razón por la que tu llamada de Zoom se corta en el momento en que alguien en casa empieza una subida. Los buffers de router tradicionales ponen en cola los paquetes durante segundos en enlaces saturados, destruyendo la latencia. Los algoritmos de Smart Queue Management (SQM) como CAKE y fq_codel mantienen las colas cortas incluso bajo carga, de modo que una subida de 500 Mbps no añade 300 ms de latencia a todo lo demás.

OpenWrt, pfSense y la mayoría de los routers modernos (Asus con firmware Merlin, Ubiquiti UniFi, eero Pro 6E) admiten SQM. Actívalo, ajusta el enlace de subida al 95% aproximadamente de tu velocidad aprovisionada y observa cómo la prueba de bufferbloat de DSLReports o Waveform pasa de una nota F a A+.

Esto no añade ancho de banda, pero elimina la pérdida de rendimiento del 40-60% que se produce cuando el bufferbloat hace que tu emisor TCP retroceda repetidamente.

IPv6 es habitualmente más rápido

En ISPs que admiten dual-stack, IPv6 a menudo enruta de forma más directa a los principales destinos en la nube. AWS, Google Cloud, Cloudflare y Azure funcionan todos con IPv6 nativo, y un paquete sobre IPv6 típicamente se salta uno o dos saltos NAT en comparación con las rutas IPv4 CGNAT habituales en móvil y algunas redes residenciales.

Comprueba con ipv6-test.com o test-ipv6.com. Si obtienes 10/10, ya estás usando IPv6 donde está disponible. Si no, actívalo en tu router (la mayoría de los ISPs envían configuraciones vía DHCPv6 o PPPoE automáticamente). La diferencia en una subida transcontinental puede ser del 20-40%.

Apaga todo lo que se sincroniza en segundo plano

Dropbox, Google Drive, OneDrive, Fotos de iCloud, Time Machine en red y herramientas de copia de seguridad como Backblaze consumen ancho de banda de subida silenciosamente. El Monitor de Actividad de macOS (pestaña Red, ordenar por "Bytes enviados") y el Monitor de recursos de Windows revelan los culpables.

Pausalos antes de una transferencia grande. Fotos de iCloud en particular puede enviar gigabytes silenciosamente después de importar una sesión. El throttle por defecto de Backblaze es "automático", lo que significa "tomar todo lo disponible" en una conexión inactiva.

Una llamada de Zoom en 1080p usa unos 3 Mbps de subida. Una llamada de Google Meet HD ronda los 2,5 Mbps. Si alguien en casa está en una videollamada, programa la transferencia alrededor de ella o acepta un impacto de 2-3 Mbps.

DNS y el tiempo hasta el primer byte

Un DNS mal configurado puede añadir entre 50 y 200 ms de latencia antes de que una conexión TCP siquiera empiece. Si todavía usas el resolver por defecto de tu ISP, prueba el 1.1.1.1 de Cloudflare o el 8.8.8.8 de Google. Usa dig +stats servicio-transferencia.com para comparar los tiempos de respuesta. Para subidas fragmentadas que abren muchas conexiones, un resolver rápido se acumula en un rendimiento general notablemente más rápido.

En macOS, cambia el DNS en Ajustes del sistema > Red > Detalles > DNS. En Windows 11, Configuración > Red e Internet > (tu adaptador) > Editar asignación de servidor DNS.

Ajuste de MTU en redes especiales

Si estás en una VPN, una conexión DSL PPPoE o un enlace celular, tu MTU puede ser inferior al valor por defecto de 1.500 bytes. Un MTU mal ajustado provoca fragmentación TCP, retransmisiones y colapso del rendimiento. Prueba con ping -s 1472 -D google.com en macOS/Linux o ping -f -l 1472 google.com en Windows. Si los paquetes no vuelven, reduce el MTU en incrementos de 10 bytes hasta que lo hagan, y luego establece ese valor (más 28 para la sobrecarga ICMP) como MTU de tu interfaz.

Valores habituales que funcionan: 1.500 en la mayoría de las líneas de banda ancha, 1.492 en DSL PPPoE, 1.428 en algunas VPNs WireGuard, 1.400 en la mayoría de los operadores 5G.

Control de congestión: BBR frente a Cubic

En sistemas Linux que suben a la nube, cambiar el control de congestión TCP de Cubic a BBR (Bottleneck Bandwidth and RTT) puede doblar el rendimiento en enlaces de alta latencia con ligeras pérdidas. Actívalo con sysctl -w net.ipv4.tcp_congestion_control=bbr. macOS y Windows usan variantes de Cubic por defecto y no exponen fácilmente este ajuste, pero los endpoints de transferencia en la nube ejecutan BBR cada vez más en su lado, lo que ayuda aunque tu lado no lo haga.

Esta es una razón por la que los servicios que corren en Google Cloud (Smash, parte del tráfico de SwissTransfer) a menudo se sienten más rápidos que servicios idénticos en hosts heredados.

La elección del navegador importa

Los navegadores basados en Chromium (Chrome, Edge, Brave, Arc) admiten HTTP/3 y QUIC por defecto, lo que supera a HTTP/2 sobre HTTPS en enlaces con pérdidas entre un 15 y un 25%. Firefox también incluye QUIC. Safari 17+ admite HTTP/3 pero usa HTTP/2 por defecto en algunos servicios. Comprueba en el panel Network de DevTools, columna "Protocol".

Si el endpoint de subida de un servicio de transferencia sirve sobre HTTP/3, dejarlo al navegador significa menos rondas de handshake por fragmento, lo que importa para subidas paralelas que abren de 4 a 8 flujos simultáneos.

Elige un servicio que respete el ancho de banda

Algunos servicios de transferencia limitan las subidas independientemente del ancho de banda que tengas. Una línea de 50 GB puede seguir arrastrándose a través de una herramienta que limita el rendimiento por transferencia a 30 Mbps. HexaTransfer envía fragmentos en paralelo sobre HTTP/2 con encriptación AES-256-GCM en Web Workers, de modo que tu subida satura lo que tu conexión pueda realmente entregar hasta el techo de 10 GB por transferencia.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.