Un misterioso problema de velocidad de carga con el nuevo ISP (que afecta a Win10 1607 y posteriores)


4

Hace unos días cambié mi ISP (a T-mobile, porque actualmente es la única posibilidad). Las velocidades estables son: 150Mb / s de descarga, ~ 34Mb / s de carga.

Traté de cargar un solo archivo de 2GB a mi VPS (usando SFTP) y noté un extraño problema con la velocidad de carga cae después de unos segundos. Significa: por alrededor de 20 MB se está cargando a toda velocidad, y después de eso solo ~ 5Mb / s.

Al principio, pensé que era un problema con el VPS actual, pero luego probé la carga a otros servidores con el mismo efecto. Sin embargo, la carga a servicios como: YouTube, GoogleDrive, OneDrive, etc. siempre se realiza a toda velocidad (34Mb / s) sin ningún problema.

Estaba probando este problema más, usando scripts de carga php (en lugar de SFTP), VPN y siempre resultó en caídas de velocidad de carga (después de un tiempo muy corto). Pensé que este ISP limita la velocidad de carga a direcciones "desconocidas", pero luego ordené un servidor Arubacloud y la velocidad de carga por SFTP estuvo bien.

Después de eso configuré OpenVPN en ese VPS y me conecté desde mi computadora portátil. Las velocidades de carga a este servidor de Aruba todavía estaban bien, pero no a otras. Cada vez que intentaba subir un archivo a mi otro VPS, la velocidad de carga era máxima. 5Mb / s. Estaba muy confundido y verifiqué dos veces si realmente se usa la VPN.

No encontré ninguna explicación lógica de por qué sucede, y comencé a probarlo en máquinas virtuales con el "Adaptador de red NAT" configurado (por lo que se compartió mi dirección IP de host). Me sorprendió ver que la carga de archivos a todos los VPS que probé antes funciona a toda velocidad, sin caídas de velocidad, sin usar ninguna VPN ...

Pensé que es un problema con algún software / servicio que se ejecuta en mi computadora portátil. Arranqué Windows 10 en modo seguro con la red. Los mismos problemas. Instalé una copia limpia de Windows 10 en otro HDD: los mismos problemas de velocidad de carga ... Por supuesto, el mismo problema está presente cuando uso una conexión por cable (Ethernet). También probé la conexión a 2 enrutadores diferentes (mi enrutador principal y el enrutador LTE de Huawei).

Cuando cambié una máquina virtual de Windows XP para usar una conexión "puenteada" (en lugar de NAT), ocurrían los mismos problemas, por lo que lo más probable es que no sea un problema de Windows 10.

Estoy muy confundido y no sé cómo detectar qué causa esos problemas. Estaría muy agradecido por cualquier consejo y recomendación de prueba.

Actualización 27.05.2018 17:10

Solo para dar más detalles. Hice más pruebas: utilicé la tarjeta SIM del enrutador LTE en mi teléfono inteligente y compartí la conexión a Internet mediante el "punto de acceso móvil". El mismo problema ocurre.

También probé en la computadora portátil de mi madre. El mismo problema persiste.

No solo afecta las transferencias de Filezilla (SFTP), sino las cargas de archivos normales por HTTP / HTTPS, el envío de archivos por Riot Messenger (cliente Matrix), etc. También probé con una VPN configurada para usar el puerto 443.

Entonces, este es realmente el problema del ISP, pero algo debe desencadenarlo. Solo para recordar: cuando uso una máquina virtual con un adaptador de red "NAT", puedo cargar archivos a toda velocidad, sin disminuir.

Por supuesto, probé la conexión por cable (Ethernet) más de 1 vez. En realidad, no debería importar, porque obtengo ~ 600Mb / s de velocidad de carga de mi NAS por Wi-Fi AC.

Actualización 28.05.2018 00:15

Detecté algo interesante:

netsh int tcp show global:
Receive Window Auto-Tuning Level    : normal

Cuando desactivo el autoajuste de ventanas mediante " netsh int tcp set global autotuninglevel = disabled ": las velocidades de carga son bajas todo el tiempo (sin aumento de velocidad total al inicio). Establecerlo en " experimental " tiene los mismos efectos que " normal " por defecto , esto es: alrededor de 10-40MiB se cargan a toda velocidad, y luego disminuye drásticamente a 2-5Mb / s.

¿Alguien sabe lo que podría significar?

Actualización 28.05.2018 23:55

Ayer instalé Windows 8.1 en otro HDD. Parece que la velocidad de carga no está disminuyendo. El autoajuste funciona bien.

Probé todas las versiones posibles de Windows 10 (instaladas en la misma computadora portátil) y obtuve los siguientes resultados de prueba:

  • La última versión donde el autoajuste funciona bien es: 1511 (10586).

  • La versión donde comenzaron los problemas es: 1607 (Actualización de aniversario).

En 1511 funciona bien con los controladores predeterminados de Wi-Fi / Ethernet, y también con los controladores más nuevos posibles.

Traté de establecer la misma configuración de TCP en la última versión de Win10 usando un software llamado "TCP Optimizer". Lamentablemente no ayuda.

Estas son las configuraciones de TCP Optimizer para versiones específicas de Windows:

Win 8.1 (funciona bien): https://i.imgur.com/A8mLlrO.png y https://i.imgur.com/8KyNPam.png

Win 10 (funciona bien): https://i.imgur.com/XbMSxTF.png y https://i.imgur.com/9la5Ydy.png

Win 10 1511 (funciona bien): https://i.imgur.com/ta8sFlc.png y https://i.imgur.com/WuDm937.png

Win 10 1607 (problemas): https://i.imgur.com/kVyaNfG.png y https://i.imgur.com/F4YLLEU.png

Win 10 1703 (problemas): https://i.imgur.com/hO2iQF6.png y https://i.imgur.com/FNo0oyk.png

Gana 10 1709 (problemas) https://i.imgur.com/LAPcuAa.png y https://i.imgur.com/smy5v5R.png

Desafortunadamente, configurar las mismas opciones (manualmente, no mediante la función "importar") no ayuda. ¿Quizás alguien sabe qué cambió en la Actualización de aniversario que podría causar esos problemas?

Actualización 31.05.2018 16:05

La única solución para este problema que encontré es usar una máquina virtual Linux que usa el adaptador de red "NAT" (comparte IP de host) + Kitty en Windows. Estas son mis notas, espero que sea lo suficientemente comprensible:

Virtual Machine Local IP: 192.168.32.132
apt-get install sshpass autossh screen
nano /etc/ssh/sshd_config:
Port 777
service ssh restart

Kitty settings:
Name - > LinuxVM-Tunnel-SpeedFix (port 777 if 22 doesn't work)
Connection -> keepalives -> 30
Connection -> Data -> Autologin username/password
SSH -> Tunnels:
- Source port: 7771 Destination: localhost:8881 | Server1
- Source port: 7772 Destination: localhost:8882 | Server2
- Source port: 7773 Destination: localhost:8883 | Unused
- Source port: 7774 Destination: localhost:8884 | Unused

Connection -> Data login/pass
Connection -> Data -> Command:
screen -X -S VMTunnel1 quit; screen -X -S VMTunnel2 quit; screen -X -S VMTunnel3 quit; screen -X -S VMTunnel4 quit; screen -S VMTunnel1 -dm sshpass -p 'MyPassword' autossh -oStrictHostKeyChecking=no -L 8881:127.0.0.1:22 root@server1.example.com; screen -S VMTunnel2 -dm sshpass -p 'MyPassword' autossh -oStrictHostKeyChecking=no -L 8882:127.0.0.1:22 root@server2.example.com;

Filezilla:
Profile: LinuxVM-server1.example.com | 127.0.0.1 | 7771
Profile: LinuxVM-server2.example.com | 127.0.0.1 | 7772

Básicamente, cuando una máquina virtual que se ejecuta en mi computadora portátil canaliza el tráfico entre mi computadora portátil y los servidores seleccionados, obtengo velocidades de carga completas (34Mb / s). Deja de funcionar cuando cambio el adaptador de red de la máquina virtual a "Bridge", por lo que debe estar en "NAT".

Respuestas:


0

Recuerde que la velocidad del ISP se acelera en Mb / s [Megabit por segundo], mientras que la mayoría de las aplicaciones [FTP incluido] se acelera en términos de MiB / s [Mebibyte por segundo], y como 1 MiB = 8Mb su '5MiB / s' es en realidad ' 40Mb / s '.
El pico inicial puede ser interpereteado a medida que se llenan los buffers locales.

En términos de 'tiempo', debería poder cargar 2 GiB en aproximadamente 7 minutos, si el tiempo es comparable, su conexión está bien.


Gracias por su respuesta. Cuando ocurre el problema, puedo ver cómo la velocidad disminuye de 34Mbs a 5 o menos en el administrador de tareas de Windows. Luego toma alrededor de 40 minutos para el archivo 1.5GiB. Al mismo tiempo, cuando subo el mismo archivo desde una máquina virtual que utiliza un adaptador de red NAT, funciona a toda velocidad y solo tarda unos 5 minutos en cargarlo.
Mona

En este caso, diré que puede depender de la configuración de su cliente (puede haber un parámetro como 'limitar la velocidad de carga'), muy útil en conexiones antiguas (como ADSL) donde el enlace ascendente era realmente limitado
DDS

No encontré ningún parámetro de "límite de velocidad de carga" habilitado en Windows ni enrutadores que utilizo. Además, si fuera el caso, no podría obtener la velocidad de carga completa en servicios como YouTube, OneDrive. Como mencioné en mi pregunta, instalé un Windows 10 "nuevo" en otro HDD, y tengo el mismo problema.
Mona

No está en Windows, está en el software que usa (supongo que Filezilla o similar). ¿Estás probando siempre en ethernet o estás en wifi? Si realiza una prueba en wifi, es posible que no tenga mucha suerte y esté ocupado '' (según lo que escribió, parece que lo probó por cable solo una vez)
DDS

Actualicé mi pregunta con información adicional y nuevas pruebas que hice. Básicamente, la velocidad de carga local (al NAS u otros dispositivos) es siempre de alrededor de 600Mb / s (Wi-Fi AC). El problema también ocurre cuando uso mi teléfono como enrutador y también afecta la computadora portátil de mi madre. Además, encontré un servidor VPS que me brinda una velocidad de carga completa usando la misma configuración / entorno de software. Por lo tanto, es como T-mobile limita las velocidades solo para direcciones específicas, y no lo hace cuando uso una VirtualMachine -> NAT -> Host.
Mona

0

Me las arreglé para solucionar este problema en el lado del servidor.

Parece que actualizar Ubuntu Server 16.04 a 18.04 solucionó este problema para todos mis VPS.

Básicamente, Windows 10 1607+ tiene problemas con Ubuntu 16.04 / Debian 8 (y tal vez con versiones anteriores). Después de la actualización del sistema operativo del servidor, el problema desaparece. Explica por qué incluso las VPN no ayudaron a resolver este problema. Lástima que lo noté tan tarde, habría ahorrado mucho tiempo.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.